Personally, I liked polygonizer approach. But it has its limitations, too.
I hope a GSoC project could solve the problem.
You should ask to devs on chat.
http://www.blender.org/community/chat/
Maybe, someone can be interested to make this in C.
I think you should pick door number 4 … Cython.
Cython will give you all the boost of speed of C/C++ but without leaving the comfort of the syntax of python.
Its a well known, mature and established tool used by begineers programmers and big companies. And very easy to learn as it only expands the python syntax with C/C++ features and even lets you mix , python code, cython and c / c++ code with ease.
And here is a blog post I made about why I think Cython is awesome
If you have any question about it dont hesitate to ask me. With Cython speed, is never an issue ;).
Also regarding pararrel projects, you would be amazed how many great ideas are left abandonded because the developer finally decided to move to other things.
Anyone remember micropoly ? 
it might be that the slow Part of my Script is the MetaBalls System itself. It might not be optimal for calculating thousands of MetaBalls? If yes, it could be possible to make MetaBalls calculation faster? Then my script could be a “solution” (for me Solution is something that solves a Problem, and made up Problems somehow doesn’t fully count 
Though, aren’t most Problems made up? )
@kilon
This is an interesting idea. I have to read more about it. Since i have some questions:
-
Does this mean i write C code but in Python(syntax) (which would mean i would have to understand Blender underlying C structure)
if yes: is the resulting C code different from “commonly” written C? Does it need a Library? -
i doubt it: I can write it like a python addon.
"Also regarding pararrel projects, you would be amazed how many great ideas are left abandonded because the developer finally decided to move to other things. " i’m swiss, not american. i’m not that fastly “amazed”. (for (some) americans, everything is amazing
this looks like a great great script, which would finally make sph particles usable! Thanks a lot. I just hope it will get faster, because now is too slow for real usage. But is just at the beginning so keep it up!
So, i’m back working on this script. Got a speedup of about 3 times so far. Probably the maximum i can get out of this, without multithreading Metaballs… So i will fix the Animation Issue as well, just have to rewrite big parts of the script. atm it takes about 9.1 Minutes for 10’000. way less for less Particles, and way more for more (not linear)
i’m as well testing some tricks to make it faster - like low resolution Metaball - subdivide it and reproject on Point Cloud (Particles). works - not sure though if /how much it gives troubles on animation/moving Fluid. (inconsistency)
since 2000 Particles only take under 20 Sec i’m testing slicing the Particle Mesh Generation and Boolean them together - doesn’t work - Boolean Modifier don’t likes those Meshes somehow… would need to fix Boolean first…
Still looking for a dev for multithreading Metaballs… According to Bart it should be doable with some speedups.
In the long run we really need either the polygonizer or implement a good Particle Mesher.
Your script is great! I wish you goodluck with coding it!
I wish coders add not only multithreading, but OpenCL also. 
Update to Version 0.3.1:
-much faster (12’000 Particles in 3.23 min 
-animation issue fixed
Known issues: Metaball Element in Center of World (should disappear with “Shrink” function)
Shrink function may cause Artifacts.
I’ve tried to make Blenders Metaball generation Multi-threaded - so far a failure due to “not the heck of an idea what this c/c++ cryptic stuff means”
I will try more on this one, or annoy Bart some more, until he does it
test with 86’000 Particles
Hope you enjoy!
bashi
niiiiiiiice! 
great to see you’re still working on this! I will try it as soon as I can!
Awesome!!!everything is great!!!thanks ~~you made a really nice tool!!
How much time it took to convert the 86000 particles? Are you talking about frames or animation btw?
i don’t know exactly, let it run over night, so must be under 12h way to long to even think about render animations with this amount of particles. (Particle Simulation was with 1 Million Particles - deleted most of it to get only fluid surface)
what do you mean by that? sorry, don’t see what you refer to.
the question was about the mesh creation time. If that timing was for 1 frame or for a X frames anim… but I got the answer yesterday trying
Nice improvements btw!
Now the problem is that the performance of Blender is not good enough to support the result of particle mesher, if you use lots of particles.
you’re absolutely right. atm i see this Tool usefull for animation with up to 10’000 particles and for still maybe 40’000… I had a chat with Bart for multi-threading Blender’s Metaball System, it should be possible and they look into it. But even then i doubt it would be for much more Particles for ani than maybe 20’000-30’000. So in the long term it would be really great to implement a proper way to Mesh large amounts of Particles like described here. And there’s as well phonybone’s polygonizer - which does Mesh Particles as a modifier - haven’t tested it but don’t believe it’s suitable for large Particle count.
So why my script at all? I think it’s a proper way for small Particle count - and since it’s metaballs, one can tweak the results in different ways, like adding dropplets (manually).
EDIT: Blender’s current Metaball system is from 1994…
Hello, regarding metaballs, they were improved later than 1994 - more metaelements were added by Jiri Hnidek.
Actually, most particle meshers work very similar to metaballs.
Required improvements would be -
some acceleration structure for metaball lookup(like bvh for particles, which I think is allready there)
limiting metaball absolute influence distance - currently I think all metaballs influence all spots of the mesh, although their influence is 0.0 since some distance. So only surrounding metaballs would be accounted when meshing.
currently this c/c++ stuff is a bit over my head.
I’ve read 1994 somewhere in mball.c or so. Possible it has improved since.
realflow as well has/had some sort of metaballs system.
The “influence all”-issue could very well be. I’ve noticed a non-linear increase in time with more Particles…
It would be great if we could get Blender’s metaball system faster, just atm i don’t see me learning all this c/c++, while i barely can python
thanks
Ah dude, this is so awesome … and your “Short” clips video too. Really good work. I have to check out your tutorials … did you use a wind force field for affecting the leaves? And how did you create these glassy balls. Fields involved I guess.
But back to topic - say what Amazon3D are planning is genious (a 80 min production, godness) - couldn’t they use your Add-On as a basis, e.g. port it to c and integrate it natively. Because, you were talking about speed.
Or is it just the convert to mesh functionality which is still missing. I have to dig into that as quickly I get around it.
Thanks for your work.
Jon
I see the polygonizer or cython would fix the issues … unfortunately cython integration in blender will need time to investigate if I assume right. So finally let’s hope, Amazon3D’s investigation can proceed Micropoly or the polygonizer patch (http://pfs.planetblender.org/) you mentioned. With the multithreading it should add another piece of speed up. Perhaps we can expect some tremendous change on this topic. Keep it up. You guys rock blender …
thxalot. Leaves first time in video, yeah, just wind force blowing in, second with ball, force fields with positive and negative values Behind Ball.
Glass Ball just played around with a simple Fluid sim and additional modifiers. rendered with yafaray, was pretty pleased with yafs glass render.
For Amazon3D: i don’t think my script is anywhere near of being useful to them. It works kind of ok for small <10’000 particle Count, but lacks some stuff which would be necessary for a production like this. No Vector Motion, way to slow, no further information about the fluid, like foam…
To understand this: My script simply works with Blender internals Metaball System. It puts for every Particle one of such Metaball and Blender then calculates the “Skin” for them. And this Metaballs System isn’t really in any way suited for this amount of Metaballs, even with multithreading i highly doubt i would be working for more than 100’000 particles (in reasonable time)… (cython also doesn’t help in this case, since blender metaball system already in c)
As i see it, the Amazon3D guys are going to make/find a solution that will work for them, and if they really can pull it off in blender, which i think is very possible, we all end up with usable Fluid/Particle Simulation/Skinning. I see very good times for simulation freaks
bashi
PS: i don’t have any tutorials
Very nice addon. I cannot test it out right now but I will. I will probably be back with a LOT of newbish questions.