I wanted to report that the quality of imports nurbs and meshes continues to be a huge problem for me to keep using Rhino as part of a much larger workflow. Rhino used to excel in being one of teh best programs in terms of import/export, but I think this needs a lot more attention lately.
FBX: I do not see any material names. The file structure does come in cleanly as layers but materials do not:
OBJ: no parts/objects structure, all flat in a single layer no mater what import option I try.
Also I gte to see some of my materials by name, but also some lose the name and a bunch of extra unnamed materials show up too.
Step: Step assembly structure is coming correctly, but into blocks. I can only make sense of this using Pascalās āExplodeBlocksToLayers.rvbā script. I though this wasnāt working well, but it was just because large assemblies take a while to fully expand and I thought it was failing (no feedback of in progress). But I think that most users who are not Pascal fanboiās (heās a popular guy, but I bet we are not a huge faithful following) cannot take advantage of working with imported assemblies. Iām not suggesting that layering (what his script does) is the solution, but at least itās a work around for not having a navigable assembly structure interface. The current block manager is not helpful because it doe snot show a nested structure.
I also get lots of edge errors, open surfaces, weird trimming errors, flipped normals. None of this happens in Modoās Power translator, very latest Keyshot step importer, Onshape, Fusion 360. I donāt know if they cheat, and maybe they have errors, but at least I can use the geometry fine for reference, rendering, etc. hereās a screenshot of my last import:
Summary: I always want to come to do some work in Rhino but sometimes I find it really really hard by not having a reliable/clean way to import files. Every time I think Iām going to go and use some Rhino I brace myself for the amount of extra work it will be just to open things up and getting to the point of starting to work productively.
I know these things get attention because itās becoming a growing problem, at least for us.
Yeah all kinds of manual methods work quite well when importing a file with 1-5 parts. But good when you are in the tens or even hundreds. This need improvement IMO
Do these errors exist also with smaller files? I.e. with only several objects? Small FBX and OBJ files that exhibit the errors would help in figuring out what the problem is. FBX at least I can take a look at, maybe OBJ as well. I think STEP is something more for @tim
Thanks Nathan, I can try making a few smaller files tomorrow and report back. For us FBX takas more priority. Ideally I want to be ably to bring a nested FBX assembly into Rhino, do stuff like mesh booleans, or mesh morphing (deformation tools), or IV unwrapping; then render in a Rhino plugin (it could be yours if presets are built in and also be able to export preserving teh FBX file structure intact (naming, hierarchy, material assignments and names). Heck, even animation information of Bongo ships an FBX exporter.
Iāll see what I can do. The other week I wet my toes with FBX exporter (material export going wrong), so I probably can take a look a bit at import too (:
The smaller file that exhibit the problem, the easier for me is to see what is going on (less data ānoiseā).
@gustojunk Please send me any STEP files that are giving you trouble. Iāve probably spent more time on STEP import than anything else for V6. Just since the start of the year, it looks like about 30 bugs have been marked as fixed. I still have quite a few on my list, but itās always worth having more. Almost all of them involve trying to figure out how to deal with questionable geometry in the STEP file.
Iāll try to come up with a test command to turn off the making of blocks for the next WIP. This is, of course, more involved than just adding the commands that you go through as a post-process. If it works well, we can add an option to the import dialog.
not trolling, I didnāt realize you meant materials and environments I thought you meant tvings like film and camera presets, color correction, etcā¦
Ha! ok, I think materials, environments, render quality/resolution presets are all needed. Without them a render engine is as useful as car engine. People want transportation. Some of them buy cars, no one (as scale) buys a car engine, nor does know what to do with one even if given for free.
Hi Chuck! How many is too man? because I have binders full of bad step files.[quote=āchuck, post:8, topic:41621ā]
If it works well, we can add an option to the import dialog.
[/quote] do you mean options to not have blocks? or also to layerize the assembly hierarchy? (because I want the later). A giant Step file in a single layer would not very a good thing.
What every you can give me! If there are as many as youāre hinting at, I canāt promise that Iāll be able to look at them all right away. Iāll probably sort them by size and start by looking at the smaller ones.
If I layerize the hierarchy, I would have to ignore any layers that are defined in the STEP file. Is that OK?
Ok, I know where problematic parts are. So Iāll look for those and I can make you a 3D sushi plate will all the parts in one file if youād like. I rather have you spend time fixing the stuff not looking for it
Layerazing and ignoring STep layers is fine with us, not sure about all your customers.
For STEP, the option to kill blocks might be helpfulā¦ (no more rapid fire SelBlock-ExplodeBlock-Purge on each import)
Not certain this would be OK, if I understand the intent correctly. There is usually useful intent contained in the STEP, when the STEP contains a large .asm.
We read in STEPs from major MCAD apps such as SW, Creo, (and increasingly Fusion). When those STEP files are of an assembly with lots of solids (to become polysurfaces) it is helpful if such is structured (layered) in a way which makes some assembly sense, presuming such was structured sensibly in the native application, and that Rhino can interpret that. We may change layer structure of the Rhino facsimile, but at least some semblance of intended original structure is better than a big mess to sort.
I defer to @gustojunk on FBX - only played with FBX a bit here and there, but his valid intent is perhaps deeper?
A development pipeline of Blender (or Modo) - Rhino - Fusion (or similar) is increasingly attractive. If such is deemed valid, and regarding open source Blender, has there been any thought to, and is it technically feasible, to just read in native Blender files, rather than via OBJ or FBX. Especially considering the Cycles project? Perhaps Iām a day late and dollar short on that idea???
Those structures you (and we all) want to preserve are made as assemblies, not layers. Only a handful of MCAD programs support actual layers and the are used for visibility control (like in Rhino). Chuck is saying that the Step format supports both assemblies ( that come in as blocks) and layers (that come is as layers). So if heās going to ālayerizeā the assembly structure at import, he will only be looking at the Stepās assembly structure and ignore the Steps native later structure (which in most cases there might be none). Did I get that right Dr. Jones?
and also be able to export preserving teh FBX file structure intact (naming, hierarchy, material assignments and names). Heck, even animation information of Bongo ships an FBX exporter.
I keep forgetting that 
