ICE Instanced Geometry very slow to render with shadows

[Chris Marshall]

Hi All,

I'm using Set Instanced Geometry in ICE to duplicate 4000 sphere's on a grid, which works great. When I add a shadow casting light, the render time just goes through the roof. This is just a default sphere with default material.

Would there be any particular reason for this? Have set it up in a clean scene in 2010.

Thanks a lot,

Chris

[piotrek marczak]

hi,
reason is thst set instanced geo. uses mental ray's stand-ins.
Use instance shape to get normal rendertime.

W dniu 2009-11-12 11:52, Chris Marshall pisze:

[Chris Marshall]

That's it! Thanks!

My test scene's rendering really fast now, but I'll need to figure out why my main scene is still sluggish!

Thanks again.

Chris

2009/11/12 piotrek marczak <orig...@gmail.com>

[Chris Marshall]

Sorry about this, but I'm now getting an error when rendering.

Loading assembly ...

parsing assembly...

error 121001: failed to open C:\Doc.....icosahedron.mia.mi... the system cannot find the file specified.

Throws up hundreds of these, gets to the end of the frame, then dies.

Any thoughts? These are very simple models I'm rendering here, though there are 3000 of them, it shouldn't be a problem.

Thanks

Chris

[Chris Marshall]

OK, the problem appears to be when I have more than 1 object in my Instanced Group. With just 1 object I can render 4000 objects quite happily, if I add a duplicate of that object into the Group, my render dies.

[piotrek marczak]

Did you try recreating this group? I noticed that when you duplicate/add objects to existing group, ice is going crazy

W dniu 2009-11-12 17:07, Chris Marshall pisze:

[Chris Marshall]

Yes, remade the group lots of times, tried freezing the duplicates and
other stuff. Still the end result is the error saying it can't find
the required file. Weird!

> 2009/11/12 piotrek marczak <orig...@gmail.com <javascript:_e({}, 'cvml', 'orig...@gmail.com');>>

[Chris Marshall]

Interesting! My objects are enveloped to a 2d chain and animated. In ICE I'm offsetting this animation with the Set Particle Animation Time compound. It appears that it's this that's causing the problem. As soon as I remove this compound, my render blasts through no problems at all.

So it looks like ICE has no problem dealing with the offsetting of the animation, but Mental Ray can't cope with rendering it.

weird!

[Fabricio Chamon]

This is because whenever you offset the animation, mental ray
assemblied are used, even if you are using instance shape node.
So, the ideal in your case should be to duplicate the animated
geometries as many time as you want the variations to be, then offset
manually these on the timeline. Put all on a group and instance shape
the group.

[Chris Marshall]

Well they are trees waving in a semi-random breeze, so I'll just duplicate my base tree 3000 times and everything should be fine!

Thought it was something like that!

Thanks

Chris

[Alan Fregtman]

Yup. FYI, that and the "Set Instance Geometry" compound sets
self.ShapeInstanceTime ICEattribute. As soon as that is present,
regardless if there's an offset used or not, assemblies *are* used.

[piotrek marczak]

all hail mentalray :p

W dniu 2009-11-13 14:28, Chris Marshall pisze:

[Frantisek Hradecky]

I have experienced similar problem, with thousands of animated
instances driven by ICE. They randomly disappeared. Moving render
process to 3Delight solved it but i had to give up using raytracing.

[piotrek marczak]

Did you have motion blur on ?

W dniu 2009-11-14 10:51, Frantisek Hradecky pisze:

[Frantisek Hradecky]

No Motion blur.

[Bradley Gabe]

Hi Folks. Sorry you are having problems rendering your instances.

 

There is a known bug with the current production versions of MR that pertains to animated instances. During render preprocessing, as MR is attempting to sort through all the different timings of instance animation and build an array of standins to meet those timing offsets ("parsing assembly..."), it builds up in memory and fails to flush away enough RAM before hitting the ceiling. You can watch this happen if you keep your system resources open while you attempt to render.

 

The specific attribute in ICE that triggers this process and will lead to crashes is ShapeInstanceTime. The following factory compound nodes are currently NOT reliable for consistent rendering as they manipulate ShapeInstanceTime:

• Set Instance Geometry
• Control Displacement Instance Animation
• Control Instance Animation
• Set Particle Instance Animation Time

The following node is completely safe and will lead to very stable instance rendering:

• Instance Shape

This means, you cannot use ICE to directly manipulate the times of your instance animations. If you do, MR will go into a process that has a memory leak. You can certainly have animation on the instances you assign via Instance Shape. So it is possible to be clever and work out ways to use ICE to vary assignments of different instances, just as long as you do it through the Instance Shape node.

 

I have heard rumors that this bug has finally been repaired but cannot verify because the MR version is newer than what is in Soft, Maya, or Max. If anyone else has access to newer versions of MR than what are available in Softimage and can verify if the standin assembly memory leak has been repaired it would be appreciated.

 

-Bradley

[Chris Marshall]

Hi Brad,

That's great to know it's possibly been fixed. Unfortunately I have thousands of instances, all animation controlled by ICE, so I guess I'll have to wait for the patch or a new MR which is a shame as I'd started to get rather excited about the possibilities for controlling animation in ICE. Never Mind!

Thanks

Chris

[Dan Yargici]

Don't ask me how but we managed to do this project (all the flocking birds) using nothing but offset ShapeInstanceTime trickery.

http://www.glassworks.co.uk/index.php?link=description&job=295

I think we were rendering in one frame packets though. So perhaps we just got lucky...

DAN

On Sat, Nov 14, 2009 at 6:24 PM, Bradley Gabe <with...@gmail.com> wrote:

[Czarek Kwasny]

Hi Dan,

Exactly the same approach here. ;)

http://www.czarekkwasny.com/?id=casestudy
(I still need my friend to get the translation corrected)

The nail'n'hammer approach with rendering ten frames per sequence then
having the whole process restarted. It was fun watching stairs-like
memory graph and seeing if it hits the roof or restarts before it
happens. ;) Especially considering that preprocessing (limited to just
one core) took often more than rendering, running 2-4 instances on one
machine was like... regular.

And for disappearing ICE instances. It's quite common experience... But
I was given some really nice feedback regarding this issue on the list. :)

Dan Yargici wrote:
> Don't ask me how but we managed to do this project (all the flocking
> birds) using nothing but offset ShapeInstanceTime trickery.
>
> http://www.glassworks.co.uk/index.php?link=description&job=295

> <http://www.glassworks.co.uk/index.php?link=description&job=295>

> <http://www.glassworks.co.uk/index.php?link=description&job=295>
> I think we were rendering in one frame packets though. So perhaps we
> just got lucky...
>
> DAN
>
>
> On Sat, Nov 14, 2009 at 6:24 PM, Bradley Gabe <with...@gmail.com
> <mailto:with...@gmail.com>> wrote:
>
> Hi Folks. Sorry you are having problems rendering your instances.
>
> There is a known bug with the current production versions of MR that
> pertains to animated instances. During render preprocessing, as MR
> is attempting to sort through all the different timings of instance
> animation and build an array of standins to meet those timing
> offsets ("parsing assembly..."), it builds up in memory and fails to
> flush away enough RAM before hitting the ceiling. You can watch this
> happen if you keep your system resources open while you attempt to
> render.
>
> The specific attribute in ICE that triggers this process and will
> lead to crashes is ShapeInstanceTime. The following factory compound
> nodes are currently NOT reliable for consistent rendering as they
> manipulate ShapeInstanceTime:
>

> * Set Instance Geometry
> * Control Displacement Instance Animation
> * Control Instance Animation
> * Set Particle Instance Animation Time

>
> The following node is completely safe and will lead to very stable
> instance rendering:
>

> * Instance Shape