There was a kinda lengthy debate on FB on this topic, and I wanted to see if a SideFX employee could chime in…

As Users started to dive into the PackedPrim Instancing support added to Redshift, what the community discovered ( as stated by Tim ), was that for high Point counts ( >= 100k ), CopyToPoints was severely slower than the Instance OBJ node when performing the same tasks ( packing geo and then varying the geo that is instanced onto points )…..we even wrapped the CopyToPoints in a Compile Block and it was still much slower.

The performance gap we're discussing here is Cook time only.

Bonus Question: How do you use a SubNet with the Instance OBJ node (specifically, using a SubNet as the Instance Source via the Instance OBJ node parameter)? I couldnt even get that to work at all.

+up for this thread.

I saw that discussion on FB and I was very curious too.

The instance object doesn't have to cook anything, so of course it is faster by that metric. Copy to Points must create a prim for each copy, set a transform on the prim, and set a pointer back to the copy, as well as copy any template attributes that might be copied. The real question is, which is faster to render in Mantra? Instance points are probably still faster, but does the difference outweigh the convenience of copy to points?

Thanks for chiming in, but, I still dont get it.

Are you saying that Instance OBJ node doesn't have to do those steps?

Here is a great treatise on this topic: http://www.toadstorm.com/blog/?p=493 [www.toadstorm.com]

Thanks so much Sean - this mystery has been solved. I was hoping I was missing something, and indeed it was that option on the ForEach EndBlock (which should be enabled by default!).