standins rendering in ice broken in 2013?

[Kzin]

can someone confirm this?
i tryed to render a massive amount of standin instances of the buddha model with ice, but it fills up my 32 gig memory for only 50.000 instances.
i also tryed to render ice instances of the instance of the buddha model, but same result, memory is filled up, for example 5000 instances needs up to 16 gig of ram to render.
so it looks like ice is not instancing the standin/instance, its using the orig geo and copy the geo and render them.

[Kerro Perro]

32 gigs of memory? Wow

[Hirazi Blue]

That's not the most helpful first reply to someone who awaits confirmation of a bug, I'd say... ;)

[Kerro Perro]

Sorry... At least he can feel cool about the beast he's working on while he waits... or something like that...

[Mathaeus]

MR stand-ins through ICE always been heavy, since day one. If this is still the same, MR stand-in is invoked by 'ShapeInstanceTime' attribute inside compound (all compounds under geometry instancing), generally it's used for getting an animation offset in ICE, by creating a lot of standins for each expected frame, or something like this....

Instanced instances in ICE also always been heavy (how you got them, btw...).

Solution for first, it was to simply do not invoke stand-in, by using a plain 'instance shape', probably by supplying some criteria for ID of this node, if there is more than one member in instance group (let's say, get group> get kine global > get array size > modulo "self.ID" by this value).

All that is explained many times on public forums, in all these years.

[Kzin]

ok, did tests with a one year old testscene. it rendered with 7 to 7,5 gig with alot of instanced proxys, full shading and fg.
the same scene now cant be rendered with 32 gig because it loaded data constantly in memory with every single bucket. so its a bug, the question is now is this mr or is this xsi. david will later do a test in maya with mr standalone.

[Kzin]

MR stand-ins through ICE always been heavy, since day one. If this is still the same, MR stand-in is invoked by 'ShapeInstanceTime' attribute inside compound (all compounds under geometry instancing), generally it's used for getting an animation offset in ICE, by creating a lot of standins for each expected frame, or something like this....

Instanced instances in ICE also always been heavy (how you got them, btw...).

Solution for first, it was to simply do not invoke stand-in, by using a plain 'instance shape', probably by supplying some criteria for ID of this node, if there is more than one member in instance group (let's say, get group> get kine global > get array size > modulo "self.ID" by this value).

All that is explained many times on public forums, in all these years.

make no difference, the opposite, if you use only instance shape, the ram is filled faster and rendering tooks way longer.

[Kzin]

did a small test with buddha model (over 1 mio polys for the mesh) and about 10100 instances of it.
for the first i used instances from the orig geo, took 3,3gb of ram and took 50sec.
then i replaced the orig geo with a standinversion of it, i stopped the rendering when mr reached 15 gig of ram and at this point no buddha was rendered after over 5 minutes.

[Kzin]

the geo will simply be copied:
this message appears when i am using standins as instances for rendering:
' INFO : GAPM 0.4 2581 MB info : triangle count (including retessellation) : 306322145


and this is with mesh instanced:
' INFO : GAPM 0.4 1392 MB info : triangle count (including retessellation) : 0

so you can see that xsi does not instance the standins.

[Mathaeus]

the geo will simply be copied:
this message appears when i am using standins as instances for rendering:
' INFO : GAPM 0.4 2581 MB info : triangle count (including retessellation) : 306322145


and this is with mesh instanced:
' INFO : GAPM 0.4 1392 MB info : triangle count (including retessellation) : 0

so you can see that xsi does not instance the standins.

yeah, exactly the same as in first implementation I'd believe instances are the first of second feature, someone would try in ICE... Why this "welcome message" is still here.. I don't know.

[Kzin]

the geo will simply be copied:
this message appears when i am using standins as instances for rendering:
' INFO : GAPM 0.4 2581 MB info : triangle count (including retessellation) : 306322145


and this is with mesh instanced:
' INFO : GAPM 0.4 1392 MB info : triangle count (including retessellation) : 0

so you can see that xsi does not instance the standins.

yeah, exactly the same as in first implementation I'd believe instances are the first of second feature, someone would try in ICE... Why this "welcome message" is still here.. I don't know.

tryed ice instances and there is something wrong too i think. rendering of 10k instances uses 3,8 gig ram but rendering of 50k instances took about 16gb ram.

[Hirazi Blue]

It would be interesting to hear about the results of the tests you mentioned earlier with MR standalone or any other Autodesk software to figure out if this is purely a Softimage bug or not... Strangely enough, an extensive but obviously incomplete websearch doesn't turn up any similar problem... But that could be due to the apparent heavy-duty usage needed to make the bug apparent in the first place.

[Kzin]

It would be interesting to hear about the results of the tests you mentioned earlier with MR standalone or any other Autodesk software to figure out if this is purely a Softimage bug or not... Strangely enough, an extensive but obviously incomplete websearch doesn't turn up any similar problem... But that could be due to the apparent heavy-duty usage needed to make the bug apparent in the first place.

ah sorry, its working in maya without any problem, so its a xsi bug.