Oh! Thank you very much!

mark
I've attached a working example.

The idea is that the parent procedural doesn't have to generate all the geometry at once. This allows mantra to generate geometry (and more importantly, free it), during the rendering process.

Nice Mark! I understand much more now how this works and this method will be in the next release of the clusterThis DSO (plus a lot of fixes and completed features).

Is there any other way to ask mantra to do motion blur without generating additional geometry?


Thanks,
Mark

Awesome!!! It works!

Guys, do you know what “The backbone doubles back on itself” warning is?

Wish
Awesome!!! It works!

Guys, do you know what “The backbone doubles back on itself” warning is?

I haven't seen that error message/warning. Does it happen every time?


Mark

mark
The idea is that the parent procedural doesn't have to generate all the geometry at once. This allows mantra to generate geometry (and more importantly, free it), during the rendering process.

Hi Mark,

I made all the modifications to use this method in the clusterThis DSO but now the memory consumption & rendering times are much larger & longer than generating the geometry all at once. Makes no sense. I've traced through the execution thread and it's performing as expected except for memory consumption and rendering time; the resulting images are identical.

The modifications I made were considerable, a little functional decomposition, a bit housekeeping, etc., but primarily moving the geo generation code into the child procedural. Otherwise, it's doing exactly the same thing except the rendering performance is horrible now. Some of the IFDs I was able to render previously are all but unusable, makes no sense … puzzzzzzeled! :?:


Here's an example of the differences in memory & render times:

v1.3 (new version using the addProcedural() method to delay geo creation;
VRAY_clusterThis::render() Total number of instances: 1764
Render Time: 27.015u 0.328s Memory: 57.32 MB of 111.94 MB arena size

VRAY_clusterThis::render() Total number of instances: 19236
Render Time: 115.578u 1.671s Memory: 247.62 MB of 821.05 MB arena size

VRAY_clusterThis::render() Total number of instances: 38514
Render Time: 162.593u 2.812s Memory: 435.62 MB of 1.44 GB arena size


v1.2.1 (creates the geo all at once)
VRAY_clusterThis::render() Total number of instances: 1764
Render Time: 4.515u 0.703s Memory: 40.36 MB of 46.90 MB arena size

VRAY_clusterThis::render() Total number of instances: 19236
Render Time: 7.656u 0.671s Memory: 60.51 MB of 68.16 MB arena size

VRAY_clusterThis::render() Total number of instances: 54264
Render Time: 10.906u 0.718s Memory: 100.73 MB of 108.56 MB arena size

VRAY_clusterThis::render() Total number of instances: 38514
Render Time: 11.062u 0.718s Memory: 82.12 MB of 90.05 MB arena size


Here's the latest set of docs/source code:
http://digitalcinemaarts.com/dev/clusterThis/download/ [digitalcinemaarts.com]
Any ideas? Any tips on where to start looking?

NOTE: There's a new version of the first DSO with the copy/recursion loop fixed. I'll get the motion blur and a few other things working whilst figuring out the problem with my addProcedural() implementation.


EDIT: Got all these issues resolved.


Thanks!

Mark

xionmark

mark
The idea is that the parent procedural doesn't have to generate all the geometry at once. This allows mantra to generate geometry (and more importantly, free it), during the rendering process.

Hi Mark,


Here's the latest set of docs/source code:
http://digitalcinemaarts.com/dev/clusterThis/download/mantra_clusterThis_v1.3.0.tar.gz [digitalcinemaarts.com]
http://digitalcinemaarts.com/dev/clusterThis/dev/docs/index.html [digitalcinemaarts.com]


Any ideas? Any tips on where to start looking?

Mark

Maybe. There are a lot of factors at work here…

Each “instance” has a little bit of memory overhead
- Transforms
- Settings
- etc.

If you're instancing a cube, or a sphere, or other lightweight
geometry, then it's quite possible that an instance will use up more
memory than a couple of polygons.

On the other hand, if you're instancing a more complex model then the
savings might be better – but maybe not.

If you're doing any ray-tracing, then mantra can't take advantage of
tossing out geometry after it's rendered.

I haven't had a chance to look at the code yet, but are you generating
all instances in one shot? Or do you do it by a divide and conquor
approach. If you partition the geometry into a hierarchy, you'd
proably get different behaviour.

If the geometry being instanced is simple (i.e. a cube/spheres/etc.)
you might try having a balanced approach. For example, if there are
fewer than 1,000 primitives, or if the screen area is small (LOD),
then just generate geometry. Otherwise, split the complicated
geometry into multiple instances…

Hope this makes sense.

Hi Mark,

Yep, most of it makes sense and I've done a fair amount of work and testing over the last few days. I think I'm a little more enlightened and, a little more confused, so it's perfect! 8)

So, I now have a version:
http://digitalcinemaarts.com/dev/clusterThis/download/mantra_clusterThis_v1.3.2.tar.gz [digitalcinemaarts.com]
that will use both methods, to generate the geometry all at one time, or, use the addProcedural() way of generating children objects which only gets render() called (and thus geometry created) when mantra decides it needs it (I've also culled the creation of the geometry if the LOD is below 0.1 for added optimization).

The code's a little redundant rbut I decided for speed's sake to leave it that way, at least for now until I can sort this out. So, doing comparisons actually surprised me as there are some conditions when both methods are just about the same as far as performance, and other conditions where the only way to complete the render was to generate the geometry “all at once”.

Puzzled … :shock:

For the children objects, I trimmed away any unused variables to ensure the object's constructor's memory impact was as minimal as possible (because it gets called for *each* instance you want to create, not what mantra decides to call), and then in the geo creation code, I tried to keep it as lightweight as possible too. But dog gone it made only a little difference.

As mentioned in a related thread on odforce, mantra calls the procedural more than once when ray tracing or generating deep shadow maps. I don't understand why that happens as I would think once the geometry is generated, the various maps can be created by using the related lights direction with the already generated geometry. Am I missing something there or is there a setting that tells mantra to do this?

And motion blur … I'm as equally puzzled about why you have to generate a copy of the same geo, transformed as one would like the blur to occur, end then add that to mantra's pile-of-geometry-to-render … I would have thought there was a velocity attribute calculation (for velocity based motion blur) and for transformation blur, just provide a motion matrix. For displacement blur I can understand the need for the addition geo … is displacement blur the default? Is there a setting I can control this?

But, there's also a few (hopefully) simpler questions I have. I can get the material's index from the point coming into the procedural (assigned via a Material SOP) but I can't seem to get the string (which I need to pass onto the instanced geo). Can you provide a code fragment example?

I had hoped to tackle to the volumetric instancing by now, but have been slowed down by these questions, can you shed some light on this?

THANKS AS ALWAYS!


Mark

xionmark
I can get the material's index from the point coming into the procedural (assigned via a Material SOP) but I can't seem to get the string (which I need to pass onto the instanced geo).

Here's what I've been trying (with no success …):

// Get the offset (this is working as expected)
int material_off = gdp->pointAttribs().getOffset ( “shop_materialpath”, GB_ATTRIB_INDEX );

// Get the offset (this always returns a -1)
int material_off = gdp->pointAttribs().getOffset ( “shop_materialpath”, GB_ATTRIB_STRING );

// I always get a empty string returned
UT_String myMaterial = *ppt->castAttribData<UT_String>(material_off);
// And this always returns 0
int myMaterialIndex = *ppt->castAttribData<int>(material_off);


Tips? Example?

Thanks!


Mark

xionmark

xionmark
I can get the material's index from the point coming into the procedural (assigned via a Material SOP) but I can't seem to get the string (which I need to pass onto the instanced geo).

Tips? Example?

Thanks!

Mark

The strings for an attribute are stored in a shared string table and indexed by the integer value.

See const char *GB_Attribute::getIndex(int idx) const;

It means you need to get a pointer to the attribute as well to look up the string.

xionmark

Wish
Awesome!!! It works!

Guys, do you know what “The backbone doubles back on itself” warning is?

I haven't seen that error message/warning. Does it happen every time?


Mark

Hi! Sorry for the delay. Yes. It happens every time. I'm trying to check this problem now.

This warning happens due to gdp->sweep() function. And this function crash render after 5-7 procedural sweeped geos.

Is it good to make in such way?

proc = new w_VRAYfeathergen(pos, pScale, pNormal, pUp, j, pTex);
procShaft = new w_VRAYfeathergenShaft(pos, pScale, pNormal, pUp);

openProceduralObject();
addProcedural(procShaft);
closeObject();

openProceduralObject();
addProcedural(proc);
closeObject();

Yes, that should work.

that doesn't work. Mantra crashes

Wish
that doesn't work. Mantra crashes

Are the proc & procShaft of type: *VRAYfeathergen ?

I think you need to make sure they are pointers/references, not objects being passed to addProcedural().

Yes, of course. It works well independently.

wooohooo! It's ok!