I don’t have to match and rematch material indices from the old-school materials. I automatically get all the RenderMaterials for all objects even after another attached model has been made active. This handles all the intricacies of worksessions, block instances and so on for the renderer. That is why I don’t have to worry about worksessions and all that, because Raytraced and Rhino Render (both running the Cycles render engine) are implemented using the ChangeQueue mechanism. This unifies a lot of work that render engines each otherwise would have to do themselves: meshing objects, handle block instance hierarchies, worksessions, and so on.
Indices change on model updates, and I guess that is what is happening here too on activating another attached model.Īnyway, this is all very cumbersome with the old method that includes handling everything yourself, including using the Materials table.įor rendering solutions we’ve introduced the ChangeQueue mechanism in Rhino 6. A material will have as many entries in the Materials table as it is being used: objects, layers, etc. You’ll find that the Materials table now contains two entries. Assign your material also to the other box. You’ll find that the Materials table now contains one entry. Say you add after the material two boxes to the model. Entries show up only once a material is assigned. This table works in a peculiar way as that after adding a material to an otherwise empty document doesn’t show in that Materials table. That said, on the very first question in your first post: the material index a material or object (ob.Attributes.MaterialIndex) is an index into the old-school materials table. I don’t know much about the worksession part of our scripting API, I’m asking around how one is supposed to handle those. Here are before and after screenshots showing the little code I sued and how Material Index are renumbered after worksession update.
But it would be great if anyone could shine some light on this issue and hopefully help enscape to resolve this long outstanding issue… So some questions here, does anyone know what Rhino or Enscape use Material Index for? And, would it be possible to force Rhino to not-renumber them? So, could this be a case of loss of the materials on enscape? After a bit of trying and error, I’ve noticed that Material Index do get renumbered everytime worksesion gets updated. I’ve been doing some investing regarding this very well-known issue with Enscape on Rhino as outlined on the forum below.Įnscape seems to be completely clueless about this issue, so I decided to look into issues on technical levels.įirst, I suspected Object ID & Material ID, and as it turned out they are static and can’t be altered on worksession.
0 kommentar(er)
