[Bf-committers] Particle surface reconstruction issues (Farsthary)

[Erwin Coumans]

NVidia implement some screen-space method for iso surface generation of SPH, see
http://www.cs.rug.nl/~wladimir/fluidcurvature.pdf

We recently got a contribution of real-time SPH for Bullet, without
the rendering, so if you come up with some good implementation under
the ZLib license, we could use that within the BGE.

(this SPH implementation is both for CPU and CUDA/GPU, done by Rama
Hoetzlein, see http://www.rchoetzlein.com/eng/graphics/fluids.htm )

Good luck,
Erwin



2009/11/9 joe <joeedh at gmail.com>:
> Metaballs havn't been maintained in a while; and I suspect they won't
> really do what you want.  It might just be easier to write something
> new from scratch?
>
> Joe
>
> On Mon, Nov 9, 2009 at 6:51 AM, Raul Fernandez Hernandez
> <raulf at info.upr.edu.cu> wrote:
>> Hi all :)
>>
>>  Check some new videos at http://farsthary.wordpress.com
>>
>>  The fluid is performing well so far, I have being able to push it to the
>> current particle limit (100k particle) without much stress (though at
>> those numbers is far from realtime ;) ) and Stephen is working hard in
>> the stiffness code.
>>
>>  Currently I wanted to handle the surface reconstruction code but i'm
>> facing some issues:
>>
>>  Metaballs could be used as instanced particles but only for relativelly
>> small number of particles but metaballs always return a blobby fluid.
>>  For Eulerian fluids (Grid based) is relaively straigthfoward to
>> implement a meshing algorithm using the already discretized domain, for
>> particles based simulations there's a hundred of papers explaining the
>> particle dynamics but very few actually tackle the surface
>> reconstruction and many approaches fall in the cathegory of discretizing
>> a domain with grids.
>>
>>  But that's exactly what I want to avoid: using a grid domain for meshing
>> limit the principal advantage of the particle fluid. So the remaining
>> solution is using an octree/kd tree based scene domain, that although is
>> still a discretization of the domain is transparent to the user and
>> there's no need to define a domain at all, and here is where I get
>> stuck.
>>
>>  I was reviewing the metaball's code since it performs the way I want
>> (correct me if I'm wrong), it uses an octree to store the metaelements
>> wich define a mathematical density function based on the distance to
>> each metaelement ,and for polygonalization it march trough the cubes,
>> but only the cubes defined in the metaballs.
>>  What SPH particles need is similar but with a sligthly difference: the
>> density function is not a mathematical returned value that depends only
>> on distance to the mball centre, the density function should be returned
>> from querying the ParticleSystem Kdtree.
>>
>>  Who was the developer of Metaballs?
>>  Could someone suggest another approach?
>>
>>  Also why metabalss don't support material blending?
>>
>>                                 Thanks in advance           Farsthary
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>