Late Night Dras Instancing

[MADjestic]

Hi there,

Here is short test of some DRAs instancing. I got hooked by an idea of prototyping a more or less painless pipeline of rendering large amounts of particles, after a short discussion with kodiak, eetu, digitallysane, Olegee and some others. Mark, from SESI forum, helped alot.

We all know of mantra being able to render DRAs, but until H9.x setting up and managing lots of DRAs had been an increasingly painful process (more DRAs -> more pain). Revising this idea from the pov of H9.x, it looks like now we've got more cool new toys to play with. However probably more questions too.

Here's a result of a quick test. Slightly more than 15M of colored particles, deep shadows. ~15 seconds to render and ~30 seconds for cooking everything up and caching DRAs. Memory usage never got more than 2.5Gb when cooking, and took all RAM for Mantra. The thing is set up in such a way that cooking will never use more than that, so in theory you could easily cache much more than pathetic 15M. I am a bit worried on the Mantra part though as it is consuming insane amount of memory when rendering it all. I think some optimization must be done in that area, maybe some clever setting to reduce memory usage, don't know... Any ideas?

[Edit:]initially tried with 10M, then 15M, result of cooking\rendering time were nearly the same, denser look of shadows on the pic. Restarted H and rendered clean with Mantra - Mem usage was around 3Gb - so there's a significant gap to use more, which is cool too.

Primary prototyping took several hours,though the current set up can be repeated in 5 minutes, maybe less. Basically 3 primary params, to change the number of particles\groups\size, 1 button click to cook things up, 1 click to fire up mantra. That's it. - no extra hassle with numerous DRAs\scripting\editing IFD's... Ain't it cool?

==========

Here's the question part:

I am having a problem adding moblur to the whole thing (not this sphere example, a different one with some action going on). I read Help, but obviously overlooking something: here's the set up of the DRA Mantra Procedural that I've got:

My initial suggestion was that since I've got, say, DRA.$F.bgeo - I put it into the File param, and the same DRA, though with a time offset (DRA.$F-1.bgeo), into the Blur File param. This way I expect to get moblur. However this doesn't work in this case. Maybe I am missing something.

Could, somebody with more experience, elaborate on that a bit, or maybe even show an example of a simple setup?

I.e. an example of DRAs moblur via this DRA procedural (File, Blur file + any other necessary setting).

Thanks in advance,

mad

[Jason]

Just some food for thought:

It would seem to me that Mantra could use a particle "populator/duplicator" procedural - a solid way to turn one particle into several [hundred] by way of a CVEX function or something. This would let users duplicate 15M particles into several hundred million, I'd hope. This is part of a typical feature fx pipeline, where particles are duplicated either as points in mantra, RiPoints in Renderman, or prerendered/voxelized/rasterized into Volumes and those rendered by Mantra. This is totally necessary to get a believable density of particles at 2k render resolutions as there is no way POPs or Houdini can handle those sheer numbers of particles, either speed-wise or memory-wise. This is technology that so far has had to be implemented by every feature fx house themselves although the base idea is identical across the board.

Also, the .pc or .tbf formats in Houdini are in the TBF structure internally - a structure which potentially allows sections of the geometry to be loaded (paged) in from disk on demand. This, theoretically, should allow for huge particle caches to be rendered if indeed Mantra actually utilizes this tiled capability.. which I'm not sure it does right now... but thats the theory anyway:)

[symek]

Well, very interesting topic, thank you MADjestic. I've asked onces about mantra point procedural because it came to my mind that such a dso driven by CVEX should give us enormous advantage yet it looks like simpler to implement then existing fur procedural. I wonder if SESI think about it? On the odforce's Houdini 10 Wish List there are requests about Krakatoo-like engine for Mantra. It seams that with current setup we are closer to this then we think. Does Point Primitive DSO for mantra with CVEX API would be so difficult to code?