V6 OBJ export bug?

Hi all,

I try the V6 OBJ export. It is very slow compare to V5 and the result file is wrong.
See this snapshot :

I made the same operations in V5 with the same model, it works normally.
I cant upload the rhino 6 WIP file if needed. The mesh was created with heightfield command directly in R6WIP.

Yeah send the file. http://www.rhino3d.com/upload OBJ export and, in the next WIP, import got a work over for V6. It’s now written in C# and uses our own .net SDK. I tried testing it as thoroughly as I could with the models I’ve used in the past for OBJ before releasing it on users but you know how it goes. It would be good to see snapshots of the OBJ settings you used and also the mesh settings.



I know @tim has been rewriting the obj import/export functionality. A sample file always helps if you can post it here. Thanks

For the moment, here is simply the Rhino 6 file : _test_R6WIP.3dm (532.5 KB)

OK. Thanks for the model. It did seem to take a long time to open your model in the WIP on my computer, debug was way faster and that’s rarely the case. I’m not, however, seeing a slowdown compared to V5 for the actual export or the results you’re seeing. With regard to the chunky output check the significant digits in the formatting tab. There was a bug in earlier versions that had that set to 1 and it got saved as a setting if you ever loaded the OBJ export plugin. If that’s set to 1 or something low(ish) you’ll get results like you’re seeing. Set it to 17 and see if it makes a difference.


  1. About the export speed : I tried to export a big mesh (4.000.000 faces) generate internally by heightfield in V5. With the V5 OBJ export, it takes ~40s to export. In V6WIP, with same parameters, it takes more than 2min.
  2. RH5 export OBJ coordinates with points ‘.’ while RH6WIP export with comma ‘,’. Is it due to national windows parameters ? I’m in france. Anyway, it 's the reason why the mesh was so bad when import it after in Rhino (see the snapshot in my first post). It is not due to the “significant digits” parameter.
  3. The “export texture coordinates” parameter of the OBJ export module in V6WIP is not take into account. It is also not memorized in the option box. The texture coordinates are always exported actually.
    Hope it’s help,

Hi Julien,

Ok. Thanks that does help.

  1. is a bug I missed because the C# number writing does pay attention to the culture. There is a way to write numbers and not pay attention to that though.

  2. must be a bug in my code. I’ll get both 2) and 3) fixed asap.

I’ll look into 1) and see if there’s anything I can speed up, it may just be a difference in C#/.net vs. C++ file writing. The code as a whole was only modified as needed to port it, no algorithms were significantly changed.


YouTrack issue for 2) is http://mcneel.myjetbrains.com/youtrack/issue/RH-31521

YouTrack issue for 3) is http://mcneel.myjetbrains.com/youtrack/issue/RH-31529

I don’t seem to be able to export to obj on the latest wip (nor on the previous ones either), do you know what’s causing this?

Does OBJ show up in the save as drop down? Does it show up in the list of plugins when you run PluginManager?

If yes, do you get the OBJ options dialog?

If yes, is it particular geometry or is everything failing?

If it is particular geometry it would be helpful to get an example.

Are you saving as meshes or curves and surfaces?

Just an FYI, in V6, OBJ I/O functionality was ported to RhinoCommon/dotnet. All of the functionality is actually in the SDK now and the plugins are for the most part only interface. I mention that in case there’s some dotnet aspect that’s preventing it from working. However, there are other dotnet plugins now that you’d definitely notice if that wasn’t working. The circle command, for instance, is now in a dotnet plugin.

After seeing your answers we can dig deeper. I haven’t heard of widespread issues with OBJ not working so I suspect this is an isolated case. It seems to work ok on my own computer using the in-house build from Monday exporting simple objects. I’ll get the latest public build in the meantime and give it a whirl.


Hm, so that exlains it, I used a folder that was under my user “Jørgen” and python never knew what to do with the “ø”. (In case you didn’t know it’s the Norwegian vowel you use in “f-ø-ck”) :wink: So that was probably passed on to the dotnet:

If I export to somewhere else that to a path containg odd characters, then it’s ok… but…:

I noticed that if I open the exported obj file then it doesn’t contain any layers, should it not add a default layer? The odd thing is that when I then draw something else then there are still no layers, but the new object is assigned to “default” even though that layer is not there.

Yeah that’s an issue that we’re aware of but haven’t gotten fixed yet. OBJ is not the only file flavor impacted.

You can follow the progress here.


OK, good you’r on it, but that link only covers the layer part.
Have you filed the ÆØÅ and other odd characters as something to fix too?

Well, I’ve looked through the code and I think what you’re seeing is a remnant of the layer index problem. What’s happening is Rhino tries to use a bogus layer index (there was no checking in the code, there is now). That throws an exception that wasn’t handled by the plugin. So the file writing bails. But what’s worse is there’s a file stream for the mtl file that doesn’t get closed. So even if you created a new object in Rhino and exported that, if you used the same file name it would bail because it couldn’t get write access to the mtl file. Closing Rhino would close the stream and you’d be able to write to that file subsequently as long as you didn’t do the layer thing again. I tested this myself after determining what was happening and could write to a file path that had Japanese characters in it.


1 Like

Good stuff! Thanks Tim!


I have an OBJ that loads correctly in V5 and not in WIP.
“Errors occurred reading this file, may be incomplete.”

MeshRepair in v5 says this is a good mesh ;-).

Are you interrested to have this OBJ file ?

Model freshly exported in OBJ from V5, same import error in WIP

Yeah send me the model. While the V6 port wasn’t a complete rewrite I did have to change the way a few things were written. With a model I can probably get it fixed pretty quick. Thanks.


LaRade120_final.zip (8.1 MB)

Are you using the latest WIP? I’m only asking because it opens for me in the WIP with no issues. Some sort of terrain model. When you open the file do you get anything, despite the error message? I also watched my memory usage on open thinking maybe it would peg for some unknown reason I wasn’t aware of but it hardly used any. Can anyone else on this forum open, or not open, this file?