V6 OBJ export bug?

Yes, last WIP from march, 8

Seems the file stay open by rhino after import failed. file locked.

And nothing else than an error message, no object

If you open in V6, save the file and then try to open it again without closing Rhino you will get the error you’re seeing. Read above in the thread where I mention the bug about a bogus layer index. Quickly… There’s a bug in opening files that have no layers where Rhino does not create the default layer. This in turn leads to an exception being thrown in OBJ export when it tries to use -1 as an array index (on export) and the filestream is left hanging, locking the file. That is fixed in OBJ export and will be in the next WIP. However, the Default layer bug is not fixed yet.

Tim

2 ideas to get around this in the meantime.

  1. If you don’t care about materials, don’t export the .mtl file and the code that throws the exception won’t get executed.

  2. If you import your file into an empty document rather than open it you get a Default layer and then the exception doesn’t happen.

Tim

Experiencing obj export bugs as well… Tried different configurations, but this always happens.
(Can you see the surface between the columns?)

Works fine with V5 though.

Do attach the file for investigation, also would be useful to mention the Rhino version you are using.

Hi. Another issue with v6 (6.4.18130.19341). I’m trying to export an obj mesh for use with Radiance. For some reason the resulting .obj file has some strange null characters at the beginning of each line, which makes the conversion to Radiance files fail. Copying the mesh to v5 and exporting from there gives an .obj output with no issues. Example attached.

ExampleMesh.3dm (2.5 MB)

I’ve attached the .obj output below (extension changed as uploading objs was not allowed)
ExampleMesh.txt (8.6 MB)

I’m not seeing the null characters you’re talking about in your example .obj output. I used the binary editor from Visual Studio to examine it. Can you please elaborate on what you’re seeing?

Actually, I do see something weird when I compare your file to obj output from V6 on my computer using your 3dm file. I’m using WinMerge and I do see the double zero character. I don’t see that in my own output from V6. Can anyone else reading this thread try opening his 3dm file and export to obj? Every app I’ve read his obj file, except WinMerge, does not show that character. This is what it looks like in WinMerge (left is my output, right is his)

The obj writer in V6 uses dotnet whereas it was C++ in V5. Could it be that something is wonky with your installed dotnet. I don’t know how you would tell.

OK. I figured this out. You must have your line endings set to LF because those characters are 0A in the file. It is peculiar though the way they show up on the left of the text in WinMerge though. If you look at them in a binary editor you’ll see the characters 0A 00 in between each line. I know from the code that those are added to the end of each line but output could be interpreted as the end of the preceding line or the beginning of the following line.

Regardless, try using the Windows line endings and see if that works better for you.

You are running 3 service releases behind, you may want to upgrade.