Awesome Particles Render(Not done by me though)

[Ratman]

Just having some fun on down time.

wispy_houdini.avi

[Raymond Chua]

Just having some fun on down time.

Hi Ratman,

How many particles did you use for this?

Is there any shader used or they are rendered as points?

regards,

Raymond

[Ratman]

Hi Ratman,

How many particles did you use for this?

Is there any shader used or they are rendered as points?

regards,

Raymond

Hey Raymond, it was about 1-2 million particles, and no fancy shader usage right now, though I'm working on a new setup right now to see if I can find a better way to use caching, ram and all that stuff.

[Raymond Chua]

Hey Raymond, it was about 1-2 million particles, and no fancy shader usage right now, though I'm working on a new setup right now to see if I can find a better way to use caching, ram and all that stuff.

Hi Ratman,

Maybe you can look into wedge ROP and mantra delay load. Wedge to cache different seeds of sim and mantra to help loading the particles.

[MENOZ]

when you have 20 simulations how do you setup your mantra delayed load? you need a mantra node that reads each simulation, so how do you do this thing procedurally?

that's my problem now

[jason_slab]

sounds like we need a "layered" delayed load procedural for this kind of work

jason

[Ratman]

sounds like we need a "layered" delayed load procedural for this kind of work

jason

This pretty much is what I was thinking.

[Andz]

Has anyone here used 2D particle engines, or 2.5D usually found in compositing programs link "particle illusion" or "trapcode particular"?

Here is a nice example of trapcode particular in After Effects.

[michael]

Has anyone here used 2D particle engines, or 2.5D usually found in compositing programs link "particle illusion" or "trapcode particular"?

Here is a nice example of trapcode particular in After Effects.

yeah..they're cheap, fast and, if used well, extremely effective.

depending on the job a 2D/2.5D particle solution is the first thing to look for.

[itriix]

This is a great topic so far. Would love to have a great step by step: HOW TO sim/render MILLIONS/ of particles efficiently. There seems to be topics scattered about here and there but definitely no solid tutorial on the subject. Wedge Rop and Delayed Load seems about the only thing i've heard so far and back when I tried to use the clusterThis, it wasn't working for H10... and for some reason could not get it to work on H9.5. However, after reading this post, I checked again and noticed there it's been compiled for H10 now... So will give it a try.

I will "save" this topic. I can't wait to hear more on this.

Cheers,

Jonathan

[borisb2]

.. but now I'm confused. I thought, part of that krakatoa workflow is the volumetric diffusion between the particles.

According to this thread, I was hoping to find out how it would be possible to simulate let's say a few 100k particles and diffuse between them during rendertime (VEX?).. kind of like M. Salek has done it in that thread with Renderman

[wigal123]

I don't know if this would work with delayed archives, but sometimes we merge multiple particle disk caches like this. Make sure they have some continuous numbering in the name. Then create a file node and copy node. Turn stamping on and create a stamp variable with $CY. Then you use thise variable to stamp into the file path/name in the file node, replacing the number. The number of copies in your copy sop determines how many files to load.

so if you have a:

/hosts/blah/user_data/particleProject/particles/cache_1.$F4.bgeo

will be

`"/hosts/blah/user_data/particleProject/particles/cache_" + stamp("../copy1","ÿourVariable",0) + ".$F4.bgeo"`

maybe that helps

Edited October 21, 2009 by wigal123

[edward]

I don't think using the Copy SOP like this is a good idea since it just combines the separate particle caches into one single humongous geometry. Definitely use delayed read archives.

[sealll]

Are those Krakatoa exporters mentioned in this thread somewhere available (cvs or prt) ?

thanks

[MENOZ]

- For shadows: convert your particles to a volume by using the particle fluid surface SOP followed by an IsoOffset, and perform the shadow map generation on the volume which is fairly efficient in Mantra. Then, render the particles while using the previously shadow map. There's actually an even more efficient way to rendering the mesh as a volume without using the IsoOffset, and I'll show this sometime in the next few weeks.

Hi, I'd like to know the efficent way to rendering the mesh as a volume without using the IsoOffset.

Could you explain me please?

[pclaes]

Hi, I'd like to know the efficent way to rendering the mesh as a volume without using the IsoOffset.

Could you explain me please?

I would do this the following way:

You create a low resolution volume that encompasses the scene. You assign it a shader, in the shader you perform a pointcloud lookup to define the density. The pointcloud coming from the particles.

No isooffset and no heavy volume required, everything at rendertime just to generate those approximated shadow maps.

[anamous]

I don't have Houdini on me right now, but the procedure is simply to use a low res volume and assign a shader that does a ray hit test against a supplied geometry (that you can read in at render time as a .bgeo) in +x,-x,+y,-y,+z,-z (usually a subset of these is enough) and determines if we're inside or outside the geo, plus a falloff to feather the volume edges as desired. The resolution of this shader is then driven by the volume step size - for shadow maps it can be very coarse (as in large steps) and they render very quickly, for beauty the step size you need depends on your scene scale. And to keep things optimized keep an eye on the opacity limit parameter and experiment with various values, it can accelerate renders a lot.

Back then, the use case I had was a mass of foam which would have needed ages to isoOffset in enough resolution, and even LOD volumes which I experimented with weren't nearly quick enough. So I took the polygon geo, saved it to a sequence of BGEO's. I then piped the geo into a Volume SOP (to make the volume cover the polygon geo bounds) and the shader I assigned to the volume was just a modified "Simple Smoke" material. The Smoke material looks up a density attribute usually stored in the volume. I replaced that lookup with a few nested ray hit tests that told me if I was inside geometry, and how far the closest ray hit is. Keep in mind that these ray hits are actually pretty fast since I'm not raytracing (as in evaluating a shader at the ray hit position and possibly branching into more ray hits from there), but just intersecting a vector with an array of polygons. So I ended up rendering the low res volume with the ray hit shader, and I handed the original polygon geometry BGEO as a file parameter to the shader.

One further optimization that I did was to create a fairly low res quick isoOffset and use it as a hint for the ray hit tests. In other words I used the resulting volume to lookup density and density gradient which gave the shader a quick hint if it should bother test for ray hits at all (if density is 1 you know you're inside a volume and so on) but I ran into some aliasing issues and gave up.

Another thing to keep in mind is that Mantra implicitly optimizes volume rendering by testing the density attribute - if it's 0, Mantra doesn't even bother evaluating the shader assigned to the volume. In the case of this little hack I just described that obviously means that the low res "empty" volume that you assign the ray hit test shader to has to have a density attribute set to anything above zero.

In my case, rendering at 720P with the volume filling 50% of the frame was a matter of 3 to 6 minutes (quadcore), shadow maps took 10 to 30 seconds.

Reference: http://www.sidefx.com/docs/houdini10.0/vex/functions/rayhittest

cheers,

Abdel

[Macha]

You create a low resolution volume that encompasses the scene. You assign it a shader, in the shader you perform a pointcloud lookup to define the density.

Hey I like that idea. I had some thought about such a technique a few days ago with an unrelated matter but didn't pursue it (the other way around actually). Couldn't there be a problem if the density wouldn't change smoothly?

[pclaes]

Hey I like that idea. I had some thought about such a technique a few days ago with an unrelated matter but didn't pursue it (the other way around actually). Couldn't there be a problem if the density wouldn't change smoothly?

errr.. so double negation means: Would there be a problem if the density changes abruptly? - most likely, yes, but that is the case with all volumes - and this is meant as an approximation (think: sprite balls). You use the distance to feather or you can use dithering techniques (very similar to how a shader will take several samples of a polygon to shade the micropolygon). You can take several samples and blend average them together. The thing Anamous mentioned about the volumes and step size applies, you need your initial volume density to be 1 (or higher than 0).

[MENOZ]

Peter, you suggest to do something similar to what happens into this thread, but at rendertime, right? sounds very interesting. I didn't thought that you could define a density value for a volume at rendertime.

anamous, could you be a little more precise please? I don't understand how do you use that ray-hit test.. and why you do a ray hit test.

"..ray hit test against a supplied geometry" hem.. what geometry? :\