Doesn’t Blender already use OpenVDB for Cycles smoke rendering, or is it just that it’s not used anywhere outside of Cycles yet?
I can only say this, if this patch along with the fracture modifier makes it into Blender 2.74, then I can go as far to say that the version would become one of the banner releases for Blender Vfx. I guess then the devs. can ax the metaball functionality as the code is quite old and this type of thing is one of the few areas where people still even think of using them (so people would use the mesher for things like fluids and lava lamps instead).
Amazing work this one…
I just think the trails generation should rather be part of the particle system, but eh, who cares.
This is a really big help for the whole community, since rendering fluid is a must nowadays, and the solutions in blender were just not goog until now.
Are you planning to integrate OpenVDB more into blender, e.g. interfacing it to Python? I can imagine doing some wicked stuff with this
BIG THANKS.
Actually, Campbell is the module owner/maintainer of the modifier system. I haven’t contacted anyone from the BF yet, as it was the week before Christmas, holidays were approaching and stuff, I chose no to bother anyone. I got the idea of making such a modifier through the GSoC ideas page in the wiki, I was looking for a coding challenge. Also that wouldn’t be my first patch to Blender :).
Yes, as long as you feed the modifier a valid particle system, it should work. IIRC, there’s a guy who’s working on a modifier to import RealFlow particles, in that case I don’t know if it’ll work. As a matter of fact, your question made me pick up Molecular, and it’s already highlighting a couple issues:
(There are 64 000 particles in here.) From this screenshot, you can see a couple of stuff I’m working on: adaptive meshing, choosing what to mesh through an object mask, and generating an alpha mask for the filters to use to preserve details and topology. And there are more options coming :).
Well, generating trails instead of spheres is a one line of code difference (more if you count the UI), so not too much time was spent on this ;).
I also looked at the GSoC branch with the VDB integration in Cycles, see if I could give it a nice update and further work on it, but I’m getting some linking issues with OSL (linking being the last step when compiling a software, for the ones who wonder :)).
As for coding an interface between VDB and Python, I think it’d be faster and easier to build the Python module of it, and link it to Blender so that people could just import it like BPy (import pyopenvdb), though, I have yet to look into building pyopenvdb.
For the rest, I’ll try and make some videos of my progress, maybe share a build, when I have the main bugs fixed and currently, they are mainly about sending a mesh to and getting one back from VDB, e.g. if the mesh has triangles -> crash. And also from the screenshot I need to figure out this whole world vs local space nonsense. So yeah, still some work to be done. Patience is a virtue.
I was hoping to see openvdb in the 2015 list per some threads re: Implementation, but was sad to see I omitted from http://www.blender.org/press/18-anticipated-blender-development-projects-of-2015/ . This being said, I hope you are still making some progress here and look forward to your next update! Also, to be clear, the current list of 2015 investments is amazing -not trying to turn this thread into a gripe.
Well, I admit I’ve been quiet lately. There was the holidays and then I got quite sick (ah, winter!), anyway…
I’m currently rewriting the whole sending a mesh to OpenVDB and getting one back part of the code. This (hopefully) fixed some issues regarding local/world space, so now the mesh should be generated where the particles are (see the screenshot of my previous post for reference). So yeah, I’m almost back to square 1: for now, I only have vertices in the generated mesh, I’ll start working on getting faces fairly soon. The confusing part here is that VDB outputs quads and tris separately, basically you get two separate lists instead of one with all faces in “order”, so I might have to come up with some scheme to get everything mapping to the right indices, which is one of the reasons for the rewrite.
I also did manage to be able to convert a mesh with tris/n-gons to a VDB volume without Blender crashing, so that’s a good point!
Alright ladies and gentlemen, here’s a video showing the latest developments on this puppy:
~EDIT video moved to post #1
(Just like the other two vids, it’s a little sped up, and that I don’t why. I’m using Blender’s screencast capabilities and I haven’t yet fully figured out what’s wrong with the settings.)
There’s still a few issues (in the case of masking and adaptive meshing), but in all there doesn’t seem to be any crasher and it seems feature complete, so I might check on sharing some (Linux) build. And perhaps it is time to contact the BF about this (maybe ;)).
Wow!
Amazing how much you’ve achieved. Keep it up.
Hopefully there will be a Mac OSx build soon.
I was wondering if the mesh can be edited? Sculpted? Displaced? For added detail and effects.
That is quite amazing! I wonder how you would define a region of greater smoothing, for example at the flow. Then could we define a finer division at the point of spray where the particles collide with a surface? I guess thats what the masking function might be for?
@@Albertofx, just like for other generative modifier, you can add any other modifier afterwards and it will influence the mesh. But to be able to edit the mesh or scult on it, you would need to apply the modifier first.
@@3pointEdit I don’t really get what you mean :). Also a little more confusing is that there are two masking options: one that works with an extra object (that I demonstrated with a cube) and the other which is the “Generate Mask” option, which should be better called “Preserve Details”. The first basically says: “Only mesh parts of the level set that intersects with my volume”, so only the particles inside the cube will be meshed, the rest will be cut off; whilst the former will essentially create a “solidified” version of the resulting mesh whose volume will be used as an alpha mask by the filters so they don’t destroy the surface of the level set too much.
The adaptivity parameter basically defines how much geometry can be simplified by creating triangles instead of quads; and that can have an extra mask I believe. But then I’m a little reluctant to add more and more options in that modifier whose UI is already big enough ;).
Are you concerned with the interface between the generated mesh and a colliding mesh? In that case we’d need to process the mesh separately from the OpneVDB side, currently because the particles are used to generate spheres the resulting mesh might look a little cloudy, so it would be good to flatten those areas if they are supposed to be an interface between the fluid and another object, if you know what I mean.
really promising indeed, great work Kévin
I really like modifier nature of your approach, and the filter feature, which - i guess - will let to tweak the mesh in many ways, hopefully with fine details, sort of like in smoke simulation (you know those wavelets details).
Would like to see a demo though with water material applied
by the way, for the accelerated video recording issue, check your framerate and/or framestep in the render>dimension panel in properties
Yes lsscppp that’s what I was getting at. The particles are used for flow but surface tension makes them behave as a large blob, inflow, until they collide and spray apart. Perhaps it would be a function of the particles distance from other particles where they would change from one smooth meshing method to a more detailed one?
