Slow Random Value node

[spurv]

It's possible that a random calculation like Random Value node, slows down my scene?

I think I'm doing something wrong.

Here is my scene.

http://www.pato.tv/USERS/Posts/crowd003.rar

[Matic]

The problem isn't the randomize compound, it's the use of animation offsets with ICE instances - a known issue. The set instance geometry nodes involve metalray assemblies which are written to disk, the usual (undesirable) behavior you see is preprocessing time going up and up the further you get on the timeline. Not much in the way of workarounds that I know of, I've heard caching can help (but I have doubts) and I seem to remember on the XSI list people were trying to compress their instance animation and then stretch it out again in ICE to minimize the slowdowns.

On a recent job where I had to flock up to thousands of animated characters I used non-animated proxies ubtil render time and then took the hit.

[spurv]

ohh! ok! Thank you very much. Hope they'll fix it in 2010.

[origin]

You can change visibility to bounding box, so framerate with uberhigh.
Of course you won't see anything, but pointcloud will calculate and render fine.

It seems that assemblies are written even for display in viewport ? hmm..

[Mathaeus]

It's possible that a random calculation like Random Value node, slows down my scene?

No, it's 'cheap' node. Turbulence is more expensive, but generally, whatever you can find under math>basic, it's fast.

[CiaranM]

The problem isn't the randomize compound, it's the use of animation offsets with ICE instances - a known issue. The set instance geometry nodes involve metalray assemblies which are written to disk, the usual (undesirable) behavior you see is preprocessing time going up and up the further you get on the timeline. Not much in the way of workarounds that I know of, I've heard caching can help (but I have doubts) and I seem to remember on the XSI list people were trying to compress their instance animation and then stretch it out again in ICE to minimize the slowdowns.

If you're talking about the growing render time with instances (regular instances too, btw.) then the best solution is to render in smaller sequences.
I know, easier said than done if you don't have a batch license...but there's always a way.

[spurv]

The problem isn't the randomize compound, it's the use of animation offsets with ICE instances - a known issue. The set instance geometry nodes involve metalray assemblies which are written to disk, the usual (undesirable) behavior you see is preprocessing time going up and up the further you get on the timeline. Not much in the way of workarounds that I know of, I've heard caching can help (but I have doubts) and I seem to remember on the XSI list people were trying to compress their instance animation and then stretch it out again in ICE to minimize the slowdowns.

If you're talking about the growing render time with instances (regular instances too, btw.) then the best solution is to render in smaller sequences.
I know, easier said than done if you don't have a batch license...but there's always a way.

No, the problem is the viewport playback.