Node Instancing question

FrankTheTank

It's my understanding that if you have multiple duplicated nodes/items in a scene, trees for example, and you want to fill out a scene, that node instancing is the way to go. But I've also read that while this will cut down on memory usage, it can increase render time considerably, especially if there is overlapping geometry of the instances.

So if memory is not an issue, is it better to avoid instancing nodes altogether, and just duplicate them? My biggest concern is having the fastest render times, I've never gone over my 6GB GPU VRAM limit, I rarely go over 3GB.

Anyone have the scoop on this?

Tobor

If not detected a major speed difference, but that might be because I'm not looking, and that my machine is pathetic anyway.

I like node instancing for certain things, not for others. On the plus column, it's certainly easier to change the shaders for all of the nodes at once. Just modify the original, and the dupes change, too.

OTOH, as I do a lot of Iray canvas rendering where I pick specific nodes to render, using instancing will fail here, as Iray only recognizes the original node. Any instances are not seen as unique.

Back to speed/memory: Iray itself has an optimizing feature for this: Play with the Instancing Optimization settings under the Optimization panel. This setting does not alter how D|S handles instances, just how Iray "flattens" the instances. One has the effect of saving speed at the expense of memory, and the other is the reverse. Ye can't have both.

FrankTheTank

I did not know about that optimization feature, I"ll have to play around with that.

I was also wondering, If I happen to alter the shapes of the instanced nodes, by altering the x scaling of some of them for example, does this defeat the purpose of  instancing? I tend to do that. I'll take a rock, instance it 10 times, then morph them by scaling them in different directions, so they don't look all the same.

I was wondering if this effects the geometry in such a way, that it no longer makes sense to instance them.

Tobor

I change the scale of instanced objects all the time, and D|S (and Iray) don't seem to complain. I will say I've changes the overall scale, rather than the individual XYZ. I'm not sure what that would do, but probably nothing. As you note, the geometry itself isn't actually changing.

 

TangoAlpha

Instances can be rotated, moved, and scaled  in any/all axes without affecting the master object or other instances. Anything else - changing a texture, applying a morph etc. can only be done on the master object, and will be reflected in all its instances.

Scripts such as Instances Plus have the facility to add an amount of random scaling and rotation to the instances they create.

I haven't heard of overlapping geometrey affecting render times (and I've rendered scenes with many hundreds if not thousands of instanced plants), but there are definitely circumstances where that potentially could happen. Transmapped leaves for instance. Transmaps definitely slow things down by a large factor. For example, I once rendered a scene with 50 total instances of 5 large tree models (so approximately 10 of each tree). On my old i5 CPU only rig, a 1600x1000 render using transmapped leaves (at a guess, maybe 10000 transmaps per tree?) took a solid week. Replacing those transmaps with geometry (say, 20 polys per leaf) reduced the render time to about 10 hours, although at the cost of a fair chunk of memory. Now, was the slow down simply because of the large number of transmaps, or because many of them intersected? I can't rightly say (and I'm not doing another week long render to find out!) The poly-leaf trees also intersected and yet they rendered some 17 times faster.

My gut also tells me that render times would be similar if all the trees were separate models, but of course the amount of memory used in the scene would be massive (not to mention, the UI would grind to a halt - at least instances can be hidden from the viewport.)

mjc1016

TangoAlpha said:

I haven't heard of overlapping geometrey affecting render times (and I've rendered scenes with many hundreds if not thousands of instanced plants), but there are definitely circumstances where that potentially could happen. Transmapped leaves for instance. Transmaps definitely slow things down by a large factor. For example, I once rendered a scene with 50 total instances of 5 large tree models (so approximately 10 of each tree). On my old i5 CPU only rig, a 1600x1000 render using transmapped leaves (at a guess, maybe 10000 transmaps per tree?) took a solid week. Replacing those transmaps with geometry (say, 20 polys per leaf) reduced the render time to about 10 hours, although at the cost of a fair chunk of memory. Now, was the slow down simply because of the large number of transmaps, or because many of them intersected? I can't rightly say (and I'm not doing another week long render to find out!) The poly-leaf trees also intersected and yet they rendered some 17 times faster.

My gut also tells me that render times would be similar if all the trees were separate models, but of course the amount of memory used in the scene would be massive (not to mention, the UI would grind to a halt - at least instances can be hidden from the viewport.)

Yeah, it's pretty much a transmapping thing...

 

FrankTheTank

Thanks for the responses, I'm always looking for ways to speed up renders.

TabascoJack

One thing that I found is that Optimizing memory can actually result in a faster render, if the optimization is sufficient to keep the scene small enough to fit into your GPU's memory.  Depending on how close you are to exceeding that limit to begin with, optimizing for speed may push it over the edge and drop you into CPU render mode, which takes much, much longer.