Bad imports with STEP, FBX and OBJ

Hi RMA team,

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.




Same here. Can be annoying and sometimes problematic.

I deal with all STEP imports as follows (command sequence credit to someone else - think it was Holo?)

Open STEP as new file and type these commands in rapid fire:


If all looks good copy/paste into master file.

Works well for me…

Suggestion - some type of check box to not create blocks at import/open might be nice.

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 :wink: 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’).


What kind of presets are you thinking of?

@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.


Right, I flagged the wrong guy. Sorry @tim :slight_smile: I keep forgetting that @chuck is the STEP guy


Now you are just trolling me right? :expressionless:

not trolling, I didn’t realize you meant materials and environments :slight_smile: I thought you meant tvings like film and camera presets, color correction, etc…

@nathanletwory, here’s a simple example. this one is triple bad, since it imports into rhino as:

  1. unnamed materials
  2. transparent material default that if you don’t have mesh wires on you think your display pipeline is broken
  3. no layers (this worked before, maybe is because there are no locators, only mesh items?

created in Modo:

after FBX import in Rhino V6

file here: (28.6 KB)

also good proof that FBX and OBJ files have not been getting much attention :joy:

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.

Hi Gustavo,

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 :slight_smile:

Layerazing and ignoring STep layers is fine with us, not sure about all your customers.

I like sushi. Thanks!

@chuck regarding STEP

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???

Sure it is possible, but the integration of Cycles we have doesn’t use Blender-based data at all, so that isn’t a good argument.

But being avle to read .blend natively would be fun.

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?