This is NOT a replacement for the current particle system;

This is NOT an alternative to Krakatoa.

It is NOT free. It is NOT for sale.

NO, it does not display 1 billion particles on the screen.

What this is a conceptual piece of work to see if a theory was possible and correct.

That theory being can you use ice (with emrpc if you have it), as a pre-vis to generate a ‘low res’ version of a particle system then mathematically enhance it.

Good now those questions are clearly answered…..lots move on.

The best way to think of the system is as a ‘hardware renderer’ for particles, that can enhance what you already have, but without having to actually a) display all the particles b) wait for the simulation time.

With huge numbers of particles the display has to draw all of them, in my opinion and tests this is really a huge waste of time and processing power. Just like low poly modeling if you have the basis correct you should know that the sub-d will work out correctly. The math handles the rest, and yes if you get the basis wrong the math blows up too for us as well as for sub-d.

When simulating huge numbers of particles most machines will not be able to cope due to the inherent way they have to save information about that particle. That takes time and just as importantly uses vast amounts of ram. Even if its small abouts of ram per particle when dealing with this scale, its should be obvious that the ram usage explodes.

So we decided to see if the theory was correct and it would generate reasonable results, in a short amount of time. On a just an ordinary workstation. I think it does. For this part of the theory it was imperative that we use mathematical systems to calculate positions etc rather than use ram and save the information. The saving of particle positions would just have given us a technically a gpu version of what exists, which was and is not the goal.

The simplest analogy I can think of is if current particle systems are like polygons where each and every vertex is saved and the more detail equals more polygons and thus more ram is used. Then think of this system as a nurbs particle render that uses equations to calculate the surfaces, with one important addendum that it can use if so desired the initial cage of the polygon object as its basis.

The system itself comprises of three sub systems one an interpolation system that computes where ‘extra’ particles should go. Second is the renderer part. That render part is just a pure performance driven system, which again is why we don’t display anything. There is no point in asking the gpu to do two things. The third part is a system of independently generating particles on a per equation basis. I suppose there is a fourth too, the writing of the files which one should not overlook :) Thinking about it I suppose there is 1a/2a as well, but its beyond the scope of this brief IS/ IS NOT explaination.

An analogy of the system is when you were at school and drew a ‘y=mx+c’ curve. You see that as a straight line, but if you took an electron microscope you’d probably see particles of ink, rather than a constant line. You just need lots of particles to get to that visual representation of a solid line, and that’s what the system does. If you think about it also inherently allows a ‘zoom’ as by its very definition it has to. Importantly, it also assumes you know or have other tools to visualize what ‘y=mx+c’ looks like before you call the system to render it. This can be with the built in particle render or with a commercial plugin.

A futher enhancement could be the pre-calculation of DOF as technically that information would be available. Similiarly for MB, but there one would expect more time to be used in the calculations and it probably would be easier to implement on the non-interpolation side. That said, i just thought as i write this if one had access to the motion vectors at the time of calling the system, it might just be possible to integrate it.

For you to try, in Softimage create a simulation, then disable the camera in the viewport or make a new camera that is not pointing at the particles before doing actually doing simulation/render. Now since it does not have to display the particles, theoretically it should do it faster.

The Numbers:
All rendered in Letterbox'ed HD. Web version scaled by 50%. Created entirely in Softimage 2010 x64. 8 scenes files. 156 fxtree components. Final count 35,128 Files, 114 Folders taking 81gb.

External plugins:
One excellent free plugin: Sibl [from www.hdrlabs.com]
One excellent free plugin for fxtree: gblend.
One excellent commercial plugin: emPRC [www.mootzoid.de]