how does instancing use memory?

[Netvudu]

Hi there.

I

[crunch]

Hi there.

I

[Netvudu]

It does make sense...does your last statement mean that using mantra on raytracing mode would consume less memory?

[crunch]

It does make sense...does your last statement mean that using mantra on raytracing mode would consume less memory?

Sometimes.

Micropolygon can be far more memory efficient than pure ray-tracing since it's able to throw geometry out after its been rendered. Consider displacement mapping. Geometry gets displaced, rendered, then thrown away.

It really depends on your scene and what features of the render that you're using.

[symek]

There is kind of common misunderstanding here (at least for me and a few I know who were asking about it previously): it seems that the concept of instances doesn't involve wise-ram utilization.

I thought so, and even sent a bug report to SESI, unfortunately before checking previous versions of Mantra.

I think some kind of clarification from developers would help a lot here.

Recently I made a quite test for Houdini 8.2, 9.1 and 9.5 and in all cases a behavior is similar, namely linear RAM consumption for identical (not even shader varied) instanced geometry with no ray-traced scene. Mantra doesn't through out from memory instances. 20MB teapot x 2000 point instances and you have a crash. It doesn't have anything to do with grid cache, micropoligons etc, since the consumption is rapid and proportional to every 20MB teapots appearance on screen.

It seems to me also that different behavior has DRA technique and this is perhaps the right way to follow in such challenges. Mantra, as expected, through out from memory geometry once it doesn't need it any more (out of rendered bucket). I think there was a discussion somewhere around about ability of using DRA on point's instances, what is - if I'm not wrong - not possible at the moment.

On the over hand I'm almost sure, that instancing in other renderer does imply one time memory allocation. Can't be sure for every engine out there though.

Any clarification greatly appreciated!

Simon.

Edited June 24, 2008 by SYmek

[rdg]

I think there was a discussion somewhere around about ability of using DRA on point's instances, what is - if I'm not wrong - not possible at the moment.

It is possible to use DRA on point instances. But you cannot instance DRA's on DRA points. Not out of the box - but there are traces that it might be possible to do so:

http://www.sidefx.com/index.php?option=com...+point+instance

about the linear memory increase using instances:

I noticed this a few times, but were never able to create a reproducable setup of this error (due to content and file size restrictions).

Recreating the setup from scratch help most of the time: a non linear memory growth when using instances.

In my opinion there is some "bug/flaw/feature" that causes instancing to not work like expected under certain conditions.

Also I am very confused about crunsh's answer about raytrace:

Q: does your last statement mean that using mantra on raytracing mode would consume less memory?

A: Sometimes. Micropolygon can be far more memory efficient ...

But I guess it really depends on the setup.

[symek]

It is possible to use DRA on point instances. But you cannot instance DRA's on DRA points. Not out of the box - but there are traces that it might be possible to do so:

http://www.sidefx.com/index.php?option=com...+point+instance

about the linear memory increase using instances:

I noticed this a few times, but were never able to create a reproducable setup of this error (due to content and file size restrictions).

Recreating the setup from scratch help most of the time: a non linear memory growth when using instances.

In my opinion there is some "bug/flaw/feature" that causes instancing to not work like expected under certain conditions.

Also I am very confused about crunsh's answer about raytrace:

But I guess it really depends on the setup.

Hi, Georg,

yes, you were the first person who draw my attention on this problem. I thought this was an error, now, after seeing the same behavior in Mantra 8.2, I'm not sure of that any more - unless I'm doing something definitely stupid...

My setup is pretty simple: Utah teapot converted to polygon with LOD 5 or 6 on both U&V gives me geometry with ~20MB in memory. Grid with 50x50 points. Point instancing turned-on and pointed to teapot obj. Done.

Just checked Delayed Load, and though behavior is little different, the result is the same

[Netvudu]

Thanks for the interesting info guys.

I must say turning into raytracing as opposed to using micropolygon, seemed to help in rendering this scene. Of course, the fact of using raytraced shadows might be important to evaluate the results (this scene needs raytraced shadows. Deep shadows don

[Netvudu]

just to satisfy my curiosity...does Mantra still act this way while instancing, or has this been solved in these few months? otherwise, is it on the list of stuff to fix? anybody knows about this?

[Aearon]

i've got a related question as well. so with regular instances mantra doesn't throw them away after rendering, but it IS supposed to do this with delayed load archives right?

it doesn't seem to work this way though, since i've never see my ram usage go down during a render, it seems to load with each bucket, but it sure looks a lot like it's all kept in memory once loaded. anything i'm missing?

[Mario Marengo]

i've got a related question as well. so with regular instances mantra doesn't throw them away after rendering, but it IS supposed to do this with delayed load archives right?

it doesn't seem to work this way though, since i've never see my ram usage go down during a render, it seems to load with each bucket, but it sure looks a lot like it's all kept in memory once loaded. anything i'm missing?

I haven't read all posts in this thread, but I believe that as soon as a shader uses ray tracing, no objects can be safely discarded (delay-loaded or otherwise). Not sure if this makes a difference to the discussion, but I thought I'd mention it just in case.