We deal with importing complex SKP files quite often and find some aspects of how they are being brough to Rhino quite problematic. I could upload some sample files we import for you to test if that would help, but here are common problems:
Named views brough from the SKP scenes never match the cameras in SKP - always seem quite random and useless
A lot of groups from SKP brough as improted as nested blocks has objects with ByParent materials, so as soon as the ExplodeBlocks command is used, many of the material assignments are lost because the ByParent property is ignored. Could we have an option for always ByObject materials so there is no ByParent in the imported file?
SKP file imported materials are brough as Old-style materials (still confused what it means) but many scripring material mathods fail with them unless we run the RenderConvertOldStyleMaterials command. Could these materials be brought as most recent Rhino material types with no need for conversions ?
Let me know if you would find some sample files helpful to illustrate the above.
I have to admit that I didnât know I was creating âold-styleâ materials. Iâm confused by that term as well and I work here. Iâll have to ask around on that one.
Letâs start with the named view issue. Please send me a simple .skp model that demonstrates the issue along with images of what each view ought to look like.
Once we have that handled we can work on the ByParent material thing.
Thanks, I have uploaded 2 files for you that should illustrate the above issues.
I am importing them into âInchesâ Rhino template (in case that affects the NamedView translation).
As for the OldStyleMaterials, Andy may have some more info. All I know itâs a headache when it comes to scripting.
To my knowledge these are pre-V5 materials. Now in WIP looks like material standards changeg again, but did not test enough to know how it affects what we do. Ideally all that would be handled âunder the hoodâ with materials and scripting methods would * just work *.
@dale said he would look into adding the ByParent option to ExplodeBlock. I talked to Pascal about this and we think it would be better to leave the file import as it is and add the functionality to ExplodeBlock. https://mcneel.myjetbrains.com/youtrack/issue/RH-41400
I also asked about the old-style materials in last weeks developer meeting and a number of us weâre baffled by the old and new material thing. @andy said that you shouldnât need to run RenderConvertOldStyleMaterials. He said you were using the wrong scripting methods. Hopefully heâll chime in here with the right ones.
What is it that youâre trying to do to the materials?
The irony here is that everyone that is talking about not âunderstanding old-style materialsâ are saying this because they donât know anything about the ânew style materialsâ. Iâm pretty sure they could be helping you because the materials you are using are the ones they know and love.
Thanks for looking into the SKP import update improvements - I will test out the next WIP named views, and if ByParent Materials handling can be taken care of in ExplodeBlocks command option that would be fine and no need for SKP import update I think.
As for the OldStyleMaterials - there is no issue on the UI side of things but I very often run into issues with materials when using RhinoScript - whether it is Material-related RhinoScript methods or the ones provided by RhinoScript RDK methods. The RDK ones work better when it comes to identifying materials but in many cases, especially with imported files (OBJ. SKP) or older Rhino V4 files, the RDK methods would not work unless we run RenderConvertOldStyleMaterials command first, which comes with its own issue of changing material names. I will prepare examples for you to look at, it will be easier to explain and see where the confusion comes from.
In our work it us critical to automate processing files with tons of materials imported and so far this has been getting in the way quite often.
there is one more weird thing with WIP SKP importer - overly nested layers - see below, this comes from a file with only one layer in SKP (Layer 0) and bunch of nested Groups/Components. The result of import is the same layer nested multiple times. On more complex files, the sub-nested structures of layers with same names are insane and hard to work with. It would be great if the sub-nesting did not happen:
I will try to upload a file that resulted in this for your reference, but you should also see it in the larger files I recently uploaded.
For now we deal with it with a script that makes all layer names unique and un-parents all matching the layers, but that only can be done after exploding block, and is not what an average user would even do.
EDIT: just noticed an interesting thing: if the imported content on nested layers in WIP is Copy-Pasted into V5, the sub-nesting is gone and all lands on a single Layer0 layer⌠only tested in this one file with one layer, but maybe it can help to determine the problem in WIP.
