Wouldn’t be difficult to do with the filter system.
an idea for the filter system: have a dedicated mask for each filter
How would you blend the masks so you wouldn’t see an obvious transition ?
Looks nice,
While looking at it, i noticed the filter function.
Maybe its an idea to have the mesher boundery set by an average distance from the main flow (or how many nearby particles there are).
So the mesher will tend to solve the big stream as a whole while foam like particles stil can be small. Maybe some statistics could be used to know if a particle is solitair, or if it is within the middle of the main flow.
Also have a particle property set,
so that we can make white foam on bleu water (as 2 materials), just like we can create rainbow like hair, using a color-ramp to set the color diference (maybe a custom property just like the smoke sim has the fire and smoke attributes).
Although possible, this wouldn’t be practical to code in the current system. By which I mean: that’s the kind of stuff a node system would make easy as f*ck to do. Like 3pointEdit said, how to blend between masks?
The way the mesher works is as follows: given a particle’s position create a spherical volume around it (based on user input), then union (like the boolean modifier union operation) all the individual volumes and create a mesh from its surface. If a particle is somewhat isolated from the whole and its volume isn’t intersecting with the others, it will be a separate part of the generated mesh. So you can have foam like tiny spheres hanging around in the resulting mesh.
Also bear in mind that this kind of tool is mostly used to mesh a FLIP based fluid simulation. In such simulation you usually have 8 particles per cell, so for a starting resolution of 32 (like for the smoke simulation) you’d get (32³ * 8 = ) 262 144 particles. My test above only has 10 000 particles (I believe).
Also have a particle property set,
so that we can make white foam on bleu water (as 2 materials), just like we can create rainbow like hair, using a color-ramp to set the color diference (maybe a custom property just like the smoke sim has the fire and smoke attributes).
I believe this is the kind of stuff the renderer should handle, maybe it can already be done with Cycles’ particle input node? Then I must admit that I don’t how I could do such a task within Blender’s code base. At least in a nice way. Just accessing the particles’ position and velocity is a funky task (at least for me 
).
great work, at last a proper mesher for particles
a question, Is this modifier going to support motion blur?
Great to see another promising attempt, hope this one finally makes it 
Does the working principe allow having a vertex/point cloud mesh as source?
Probably, I don’t really know how motion blur plays with the modifier system, maybe it’s automatic? I tried a quick render but it was taking too long so I aborted it, maybe it’s working? Long story short I don’t have that much knowledge about Blender’s (and Cycles’) codebase at the moment…
Not currently, only particles. But in principle it could be done, as we basically just need a list of points (with optional radius and velocity).
I couldnt resist testing it and i noticed something strange. ( i used the 64 bit version).
I created a particle (fluid) type system and let it splash over a famous monkey 
I understand that the particle mesher isnt about keeping the volume of exact volume consistency.
But its kinda weird, the particle system was made out of about 5000 particles.
The colided into the half open cube as a single layer upon it, some parts dense other less …wel how water flows.
I couldnt get the mesher to follow that density narrowly so i had to make its neigbor detection factor a bit larger.
But this resulted in a bit odd effect that after the colision with Suzanne the ‘meshed’ flow became 3 streams.
Each of those streams was as volumous as the stream that went out of the box.
Kinda weird… did i do something wrong ?
Should the particles while in the half open top box have stacked upon each, so that the first flow would have been about 3 times more volumous… or
PS
I managed to render image frames using BI, but blender crashed before saving.
So in another session i turned the image stream to an avi.
So my original file is lost.
And another comment, while doing that monkey.
I notice that gravity tends to stretch distance between particles that are in different vertical positions.
Not sure if possible, but maybe some kind of filter that progresses the particles from top to bottem and stretches particles in Z axis as based on their gravity acceleration
A speed X difference between frame x and frame x+1, if within “distance”=> stretch
Where distance can be adjusted (as gravity buildup) when compared to previous location
If buildup is less < then someting asume it hit something and thus reset distance
…well some math like that to follow a particle and have gravity scaling mesh / bounds
I also noticed in the video that the mesher currently works in a way that means you might have fluid clipping through meshes. Would it be possible to tweak the algorithm so as to add an automatic ‘tightening’ of the skinning parameters for particles colliding with meshes?
@@Razorblade? (there’s no 64-bit version of my work hanging, afaik)
@@Ace_Dragon: I already thought about that issue, this is not handled by OpenVDB internally, so it shall be done separately. I will probably need to talk with Campbell to see how it could be done.
So it wouldn’t be possible to patch OpenVDB then, I think Dreamworks would be happy to accept contributions from Blender developers (since it ultimately benefits the cause of Open Source along with the industry in general)?
@KWD
oh there are 2 now… thats why i couldnt find some options 
I wonder would it be an idea to merge those 2 ideas and take the best of each ?
How does the OpenVDB mesher handle thin sheets? I know in other meshing solutions thin sheets have special case handling, but I’ve never seen the OVDB solution.
This was already addressed. They’re two completely different approaches, with the one in this thread being the more advanced of the two.
Well, I guess DreamWorks Animations (DWA) would be happy if some Blender developer(s) started to enhance VDB, but then I feel this subject (surface collision) is too implementation/software specific. Then DWA are using Houdini, where you can simply create a node graph to do the trick. Not to mention that VDB is more concerned with volume (level set & fog volume) data handling than surface collision.
It does not really. IMO this is for the fluid solver to generate the appropriate data (similar to Mantaflow). When developing their meshing tools, DWA were concerned with giving artists as much control as possible, and based some tools around similar ideas from 2D image processing and compositing, e.g. the filter system or even the alpha masking possibilities. So a good usage of the tool-set should produce the desired results.
I figured that they’re using a modified dual-contouring scheme, similar to what is used these days in voxel renderers.
Sorry for testing the wrong one in the video, but is it already possible to download and test your version ? (is it a script?)
It isn’t a script, it’s a new modifier, meaning you would need to compile your own blender, and possibly compile OpenVDB libs as well. As far as I know he hasn’t released a patch yet.
Woooooow !!! so good ! I want try :yes: