I submitted this as a bug weeks ago and it got accepted with no feedback but I can't seem to track it down so forgive me for posting here.

There's something seriously wrong with material assignments and packed prims right now.

I've got a basic setup of a couple million scattered trees, nothing crazy. Tree has three materials assigned to it via material nodes and groups before being packed, all good. Declare materials is set to ‘save all materials’. The packed prims are being scattered using a copy to points node, no extra attribs being passed. Here are my mem usage scenarios.

1. As per above scenario, 2million instanced packed prims is 34GB, that is pretty high.

2. take away all material assignments, about 8GB, that feels much better.

3. Add one material node back in, 19GB. Add two back in, 28GB. Add three, 34 GB. Zoiks.

This is killing me because I can't assign shaders without destroying memory usage. Also, as I stated in the bug, assigning a material after the packing doesn't have the same problem, I just can't do that with group assignments for obvious reasons.

So is this a bug? A limitation? am I getting the workflow wrong? Is it just how things are?

Cheers.

From my understanding of packed primitives this makes sense. You are packing your geo with more attributes. If your source object has 100 primitives and you assign a material you have assigned a string named shop_materialpath to each primitive/face. Memory usage will go up based upon the length of the path to the material. So nested materials paths will take more memory than say root based pathing (i.e. mat/my_mat).

What does not make sense is adding more materials should not increase memory usage as you experience. Continuing with my example, you only have 100 faces and if you assign multiple shop_materialpaths you still only have a 100 faces to populate a string attribute upon.

What seems like is happening is that when you add a new material somehow your geometry is getting duplicated as well. It is hard to tell without seeing an example scene. Are you branching and then merging things back together? Perhaps you have duplicate faces in the same exact location?

Enivob
From my understanding of packed primitives this makes sense. You are packing your geo with more attributes. If your source object has 100 primitives and you assign a material you have assigned a string named shop_materialpath to each primitive/face. Memory usage will go up based upon the length of the path to the material. So nested materials paths will take more memory than say root based pathing (i.e. mat/my_mat).

What does not make sense is adding more materials should not increase memory usage as you experience. Continuing with my example, you only have 100 faces and if you assign multiple shop_materialpaths you still only have a 100 faces to populate a string attribute upon.

What seems like is happening is that when you add a new material somehow your geometry is getting duplicated as well. It is hard to tell without seeing an example scene. Are you branching and then merging things back together? Perhaps you have duplicate faces in the same exact location?

I can understand additional attributes adding extra data to packed prims being copied and referenced, they do, but adding a simple material should not take up this much extra memory? Doubling the geo on the object wouldn't even increase mem usage as much as adding a single string with a material path which makes no sense considering the additional data that goes with each additional primitive.

The geo is clean, I've experienced this across a few totally different scenes so far, it's a consistent behavior. It's just a single mesh loaded in with some materials applied.

In my bug submission I made it simple, one material added before and after the pack on some reasonably simple geo, the difference was huge. So regardless of whether this is just how it is I'd at least like to know what's going on.

Okay I managed to track down the bug report. It's actually labelled as a feature request now. The issue isn't occurring in 15.