I always use pack before copying but this is not exactly what I meant. I made a quick file to show you what I mean.
In this file you can see three different scenarios: - first one is regular copy stamping for random size and rotation - second one is the same size and rotation but this is done differently (look at huge performance increase) - the third one is I only stamped the timeoffset (look at decrease in performance again)
I don't think there's just one definitive way to control, visualize, make and render copies efficiently, there's always a particular solution for each particular situation IMHO, in the end it depends of what kind of effect you want. Thanks to Houdini you can have this kind of flexibility in a lot of situations.
Most of times I give up a viewport representation and real time feedback for a more efficient way to render and control lots of copies, Well but that's just me.
Off course you can have both but I find it difficult to find 100% of efficiency on both in 100% of all situations.
Here are some of my ideas for your kind of situation, I hope that helps anyway let me know.
It's actually not about performance in the viewport, I'm more bother about the cooking time. This is a low demanding scene, image I have 1.000.000 animated objects. Copy stamping will fail at huge values with huge geometry.
The only way for me to get this to run stable is to export some objects with different time offsets and copy them seperately in seperate copy sops.
Time offsettings would be too slow with copy stamping, I've also tried this with the instance node. First export different variations of a model, create an attribute to switch the file paths at render time. But when I reach extreme amounts mantra will eventually choke on a 24GB system.
Even when I export mantra archive with ifd material and use delayed load procedural.
I think the only fast way is to have seperate instance nodes or seperate copy nodes, I was thinking about writing a simple python script to do this.
I don't see the problem that you are describing with the instance node, with the example I've send you it starts to render almost instantly.
I've done shots with even more complex geometry, like crowds with different animations and textures, which rendered fine without bottle necks like you are saying, can you post a sample file with the problem that you are describing?
But yeah saving the geometry with animation would be a way to go, you could have a different optimized system that doesn't render just to preview your geometry.
