Well not really as referencing aka linking won’t be able to solve material picking as original 3dm would have to change and then we end with embeding with bloating user file - eventualy could do hashset of existing and revert back to original state after imports but then i dont have option what to do for eg on duplicate (mat overwrite, use both or use existing) - it would be perfect if it would but rhino doesn’t have any material library format to keep several related in one file and from which materials could be picked on the fly and what’s more important default material format do not carry external engines data so useless in my case.
Exactly - actually lacking methods of handling various types of data on read/write in RhinoCommon via FIle3dm. One of those is the lack of URL param on writing 3dm at least one renderer use this to reference original model while the block is only a proxy. Next lack of ability to write/read RenderMaterials those are not materials and are kept as (I guess it was) plugin object in ON 3dm. Its kinda weird as Material is in general unwanted legacy thing and RenderMaterial is not accesible.
Then I tried directly to export the selected objects to 3dm file but it caused huge bloat in the exported file as I used a fairly complex model and i had more than 140 mats in file with a single model of a cube which actually didn’t had any material on it…
Other notes were just about some inconsistencies in API. Besides, there could be one method to cast InstanceDefinition to InstanceDefinitionGeometry and back especially that rhino already has this when reading 3dm on its own am i right?