RealFlow Official Forum

I couldn't find anything here on the forum, but was wondering if it were possible to implement a new feature in the future.
When generating particle meshes I often have intersections with the geometry to which the emitter is interacting.
Especially when there are small details in the mesh it's near to impossible to generate a mesh that isn't intersecting with the geometry.
Which then, when using refraction while rendering gives ugly artifacts.

Would it not be possible to add a feature that looks at the simulation-geometry before creating the mesh and detects it's boundaries and with it prevents that the generated mesh will intersect with it?

I'm sure it will double/triple the mesh generation times, but it will be well worth it in some cases.
At the moment only thing I can think of is thinning the mesh but this results in some parts "floating" with too much distance which then feels unnatural

perhaps an easy solution would be to have the option to cap the mesh while using the mesh-clipping feature.
When this would be done in realflow it will result in a nicer mesh then done afterwards in 3d software

or have I missed some feature that will tackle this problem already?

(at the moment i'm trying to balance thinning the mesh with the surface proximity settings)



ps. it would be great to build in a fail-safe for stupid people like me that use the "Generate-mesh-script-button" but leave the "build" setting at "no"..
this nicely generated the mesh, but doesn't save anything... which is kinda contra-productive

While it isn't a single button solution, you can use a Fill Object emitter on the mesh that you want to cull out.
If you emit Dumb particles and remove them from all Daemons/Interactions you can generate a cache very very quickly.
If your object is animating, you can use something like this (I haven't tried it myself...but I assume this works seeing as it is on the site)
http://www.realflow.com/resources/item/show/scenes/208

Once you cache those parts for your object, just set their state to cached and add them to the particle mesh.
Then, the last step is just to enable 'subtractive field' on that emitters settings in the particle mesh and tweak the radius to taste.
You can get a very detailed approximation of your emission mesh by just upping the resolution of your Fill Object emitter.
Hopefully that helps.
And while it isn't a single button solution, it really doesn't slow down meshing much at all for the benefits.
All the best.
~Ben

Thanks for that suggestion!

Will see if that's doable.. I think the mesh I have would make it quite time consuming.
It's like a long tunnel-like environment (see attached, but then 2.5 times the visible length).

Ah, yeah, good point.
I thought that you had closed surface and particles were on the outside.
This is a situation I didn't consider...inside and tube (which you probably can't fill on the outside).
Its always something!

What package are you rendering in?
Maya? Houdini? Truespace?

Most tools have some sort of way to offset a mesh based on another mesh (Ray project kinda stuff)
With Maya you might have to use SOUP for the rayproject node...but it is a solid plugin with a nice peak deformer which is also great for polishing your fluid mesh.
Houdini could get you rolling really fast...
A long shot...but just trying to help.
~Ben

actually.. i'm just using plain old 3ds max

At the moment I think to have found a reasonable mesh setting that doesn't float too much.
But it doesn't look well in the animation I could indeed offset the mesh.
Using a volume select i'd be doable to select the out-of-bound vertexes and push them back a little with a soft selection.

Will see what did the trick in the end.
Would just be cool if it was all just included

It would definitely be cool.
Is anyone listening!

We are listening

Thanks for the suggestions, as always.
I assume that the clipping functionality in the existing meshing methods inside RF are not what you are after.
Let's see if anything can be done in those lines or we can improve the clipping existing ones.

g-)

Yeah the current clipping objects don't seal the particle surface...meaning you have an open hole where you clipped.
Fine for some setups, but when you need to do refractions and stuff you can get some weird artifacts.
Would be a sweet update!

gus wrote:We are listening

Thanks for the suggestions, as always.
I assume that the clipping functionality in the existing meshing methods inside RF are not what you are after.
Let's see if anything can be done in those lines or we can improve the clipping existing ones.

g-)

Great to hear

The current clipping doesn't do the complete trick and to explain here this beautiful image



/// edit
it would actually already be enough to have a "mesh-distance-threshold" with the meshing options.
Wouldn't necessarily be connected to the clipping. If possible it would be ideal when multiple objects could be included for this threshold


If the 'ideal clipping' method would be possible then it would easily prevent problems as in the image below.



Here most dark spots are caused by the mesh intersecting with the 'tunnel' geometry.

mmh, i've been messing around a bit with the clipping and very often run into this message:
" WARNING: The action requested can't be completed because of a memory problem."
which is a bit odd as the machine had 32gb of ram of which ~25gb is free when trying to mesh things.

I only have it with meshing with a clipping object, first I thought it was to high poly custom objects.. but now also have it with the build in cube geometry.

does this happen more often?


///edit

here a link to a mesh i've been trying to clip > http://www.m.rckmn.nl/_/Remesh.rar
The particles of frame 33 are in there (290k particles @ res 20)
This is just with the default meshing parameters to rule out extreme settings
I intended to use small poly size of 0.01, which works fine without clipping

With the hexacore machine it gives the memory error message.
If I try it on one of the quadcore slaves (16gb ram) it loses the teamviewer connection and the machine is completely frozen.