1 trillion particles?

[pbowmar]

On Elektra I was easily able to render 6 million+ in Mantra with lots of attributes etc. Mantra isn't the problem, getting them out of Houdini is the problem In my case, I did 3 sims of 2 million each, which Houdini barely could handle, then used Render Points from File to load them into Mantra (rather than create a ludicrously large IFD file) and Mantra happily rendered them very quickly. This had the bonus advantage that I could run the three simulations on three seperate farm machines. I didn't try higher than that because that's all I needed at the time

So, if you want to try rendering a lot of stuff in Mantra, churn out a lot of .bgeo files then "combine" them using Render from File. Your IFD will be tiny

While we're talking IFD, it's important to note that adding "echo" commands to the IFD can help debug a crash or memory usage. If you put an Echo after each command you can see how long something took, or how much free memory before and after the command, etc.

Cheers,

Peter B

The problem lies in when you add a few attributes to the mix.... kablam! No more houdini.

In the sims we're doing right now, we can max out at around 1.5m particles with all the necessary attributes or else we run out of RAM.

We can render a ton more, but generating them is another issue altogether

[MADjestic]

A few months ago I ran some particle test on different platforms. With AMD4600+ X2, 4Gb of RAM I got about 16mln of particles under Windows XP 64bit and it took about a second to cook 1 mln particles per frame (including numbers above 10mlns). Under Suse x86_64 I was able to render about 11.5mln of particles until Linux started to cache them to disk, the performance was worse than under Windows XP64, on the other hand it didn't crash after the memory was run out (it did crash under Windows XP64).

[aschwo]

I'm currently working on rendering lots of points. The general workflow I have in mind is this:

houdini particles ( or mesh, really) define a volume, kind of like guide hairs

PRMan takes this 'proxy' version of the volume, and through a Procedural RunProgram, interpolates the position of the points contained within the proxy and generates Points based on the number of particles and density you want.

As a way for mimicking Krakatoa's functionality, is this totally boneheaded? The *feels* like it might be the right path to go down, but I have a suspicion that PRMan will choke on that many (1 billion) particles, no matter how many optimizations are done. Also, there are problems with the Python (or C, or whatever) "RunProgram" choking on a ton of data being fed into it.

Is there another way?

- alex

Edited March 29, 2007 by aschwo

[edward]

My unfounded impression of SPORE was that it was more similar to flame fractals. In flame fractals, it doesn't actually generate a trillion particles at the same time, it can take like a million particles, and run them through like a million iterations with a final rendered result of a trillion.

[Andz]

My unfounded impression of SPORE was that it was more similar to flame fractals. In flame fractals, it doesn't actually generate a trillion particles at the same time, it can take like a million particles, and run them through like a million iterations with a final rendered result of a trillion.

Hi Edward, didn't you do something like that on your 42nodes contest entry?

I remember the fern, but I dont know how it was made.

[edward]

Yeah, but a lot more primitive of course.

[Andz]

Yeah, but a lot more primitive of course.

Nahhhh.. just shake those points around and we are done....

[kodiak]

houdini particles ( or mesh, really) define a volume, kind of like guide hairs

PRMan takes this 'proxy' version of the volume, and through a Procedural RunProgram, interpolates the position of the points contained within the proxy and generates Points based on the number of particles and density you want.

The overall approach is kinda ok. We used to do this from Maya to Prman, and it worked great for simulating water spray and stuff like that. I would probably suggest to go with the DSO route instead of a Runprogram as with Runprogram all the communications happen through stdout and stdin, so that is the bottleneck really (and python might be as well). I dont think it will scale up to a billion (especially if transparent as well), but couple of ten millions is fairly easy to achieve that way. Try to look for genietail mental ray shader as well, that works in a similar way (it's a mental ray geometry shader).

[aschwo]

Thanks, kodiak. I found I can render about 10-100million with a RunProgram without running out of memory (2gb) , anything more than that is incredibly slow, or fills the memory. You're right about Python, I read that its memory management is a little funky, and treats floats differently, and isn't as efficient as it could be.

Here's a quote from an article about Superman Returns:

"To make it possible to art direct the clouds, the crew started with Maya models - simple geometry - that, once approved, moved into Houdini where the geometry turned into point clouds with thousands of particles. Once in Houdini, the effects artists groomed the clouds and assigned shading properties that changed the density of particular areas.

[pbowmar]

Here are a couple of pics from Mantra. One is 30 million and one is 40 million points. They have VEX Layered Surface with an Alpha of .5 and rendered as Points Only.

I generated 40 different .bgeo's each with 1 million points then had 40 objects each set to Render Points from File. The IFD was quite small.

There are three lights, each with a Deep Shadow, one red one green one blue. The Green one you can't really see much of as I attempted (and failed) to make it a back light.

I'm rendering on an Athlon 4400+ X2 (dual core) but only using a single core. 2 gigs of RAM, using SuSE 10.1 and Houdini 8.2.13. Render resolution is 640x480

The 30 million one took 8 minutes to render, basically 2 minutes each for the DSMs and 2 minutes for the colour pass. RAM peaked at 1.8 gigs, no swap used.

The 40 million one took just under 8 hours to render, roughly divided the same as the previous one between the DSMs and the colour pass. This one took 2.3 gigs, and swapped a lot.

Moral of the story: Mantra itself has no trouble with the rendering of many many points, the issue is memory. If my machine had 4 gigs and I was using a 64 bit OS, I could probably do 80-100 million without too much trouble. More memory = more points rendered.

Now, if I could render using TBF format (tiled block, used point clouds) I bet I could render craploads more. You can't render TBF directly as points, sadly, though I can think of ways to do that actually, but I've now spent all the time I can afford on this experiment

Cheers,

Peter B

megaparts.zip

[kodiak]

I generated 40 different .bgeo's each with 1 million points then had 40 objects each set to Render Points from File. The IFD was quite small.

Thanks Peter,

My only problem with this is that if you consider a moving sequence, you end up writing out quite large chunks of data (similar prob to crowd generation). Also, you need to move that data across the network or generate it per frame on the render slave calling houdini batch..but then you need loads of batch licenses.

Ashwo:

We wrote a crowd system that was first implemented as a runprogram in C (subset of C++ when it came to the Ri API) and found that you have a choice on passing data from the runprogram to the main renderer: you either do lot of small calls (and you deal with the bigger communication overhead) or you build more in the runprogram executable and pass bigger chunks, but then you end up the runprograms themselves (one per render thread) being the memory limitation, not the main renderer. Also, on Unix you get lot less overhead with stdio (for example older versions of mental ray reportedly been slown down by excessive stderr logging on NT, which is not even as bad as runprogram communication). I think runprogram is ok if you already have the data on disk, you just pass around references (like that renderman siggraph paper from ILM), but not really for building full geometry. Once we moved it over to be a DSO, that communication overhead was gone.

Sorry for the random rant

Now got questions as well:

1, In Renderman, the behaviour dealing with on demand geometry loading usually looks like:

- if you dont have raytracing on, you can pretty much free up memory if the bucket is gone

- if you have raytracing in the scene, then it usually keeps everything in memory (just in case)

I'm not sure how mantra deals with this, but for me it seems to be a bit more smart as the limits seem to be sligtly more flexible. Anyone has an exact description of this behaviour in mantra?

2, TBF: am I wrong saying that only shaders can access TBF archives? Is there a way to directly render them (similarly to Prman13's brickmaps)..no biggie, just out of curiosity.

Thanks,

Andras

Edited April 1, 2007 by kodiak