Hi cgdvs,
Unfortunately merging matIDs together into a big multi-sub material is no longer a feasible task due to the advent of modern renderers' own multi-sub texmaps. When a texmap contains multi-sub instructions for a renderer, its material will no longer work correctly if placed in a parent multi-sub mat. For example, if I assign a vray multi-sub texmap to an object and assign that texmap its own sub-texmaps, that texmap will no longer function correctly when its material is placed inside a parent multi-sub material.
Due to this limitation, I leave it up to the user to organize their material IDs. It's unfortunate, but it's the only outcome that guarantees proper render output when combining objects together. I could theoretically write my own material ID combiner (similar to what XMesh does), but it will cause problems if users unknowingly include any materials that contain a multi-sub texmap.
Unfortunately merging matIDs together into a big multi-sub material is no longer a feasible task due to the advent of modern renderers' own multi-sub texmaps. When a texmap contains multi-sub instructions for a renderer, its material will no longer work correctly if placed in a parent multi-sub mat. For example, if I assign a vray multi-sub texmap to an object and assign that texmap its own sub-texmaps, that texmap will no longer function correctly when its material is placed inside a parent multi-sub material.
Due to this limitation, I leave it up to the user to organize their material IDs. It's unfortunate, but it's the only outcome that guarantees proper render output when combining objects together. I could theoretically write my own material ID combiner (similar to what XMesh does), but it will cause problems if users unknowingly include any materials that contain a multi-sub texmap.