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

[Vilem Novak]

That's actually not true, since Jiri Hnidek (maintainer) converted metaballs to 2.5.
last commit from him I found:
http://lists.blender.org/pipermail/bf-blender-cvs/2009-August/021372.html
VN
> ------------ Původní zpráva ------------
> Od: joe <joeedh at gmail.com>
> Předmět: Re: [Bf-committers] Particle surface reconstruction issues (Farsthary)
> Datum: 09.11.2009 20:36:38
> ----------------------------------------
> 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
> 
> 
>