BUG Exporting OBJ?

The attached file has two quads each with a different basic material. One of the materials has a really long name, the other has a name with one letter.

If you try to export the quad with the long name (turquoise) as an obj rhino lags and the generated file balloons above 300mb 500mb 2GB 5GB (still growing)! If you export the quad with the short material name (green), it exports as obj as expected.

(I force crashed Rhino when the file got above 6.75GB)

I discovered this while trying to export some old projects to another software. I was using obj for certain reasons, and when I got to this part it took forever to export (exporting to other file formats such as .fbx, .dae, and .dwg work fine). Obviously, such a file crashes most software I try to import it into. I purged, cleaned any named views, and basically just tried to isolate the issue. I cannot see any other geometry or data in the file. IF the name is changed to a simple letter or few characters, the issue goes away.

Is this a bug, or is there something else in the file that I am not seeing?

Not sure what I was doing when I created these objects and materials, but most likely I was assigning automatic material names from a script or gh def.

faces.3dm (2.1 MB)

Hmm- the file is very large for two faces and it looks like the size in in user tables- I see there is some Vray stuff in there.

user table[2]: (2131961 bytes)
  Plug-in name: V-Ray for Rhino

I’ll poke at it some more- thanks.

The file exports OK here, to OBJ… you might try _-SaveAs SavePlugInData=No and see if the resulting file exports better.

-Pascal

Yes, at some point I was rendering with V-Ray for Rhino (several months ago for this project). At the time I saved the file attached, I was set to use Rhino Render (though I was not rendering, just exporting).

Using

results in the same behavior (file balloons).

Hi Luis- does the OBJ file in this zip behave itself?

faces_NoUserData.zip (8.3 KB)

-Pascal

No. If I try to export just the green quad, all is good as before. If I try to export the turquoise quad, file balloon.

Hi Luis - I exported both faces to the OBJ file that is in the zip - it is about 2k. Are you saying that if you export both faces from the 3dm (no user data in that file, 22k instead of 2 MB) file that I included in the zip you get something different? Can you post a screen grab of the OBJ export settings?

thanks,

-Pascal

@pascal, I unzipped and opened your Rhino file. If I export ONLY the green quad, then it exports fine. If I export both quads or just the turquoise quad, the file exports infinitely. I’ve tried this on my laptop and desktop and I get the same behavior on both. Here are the options I am using:

OK, thanks - so obviously it is the ‘export material definitions’ that is doing it- got it now.

-Pascal

@pascal Unchecking ‘export material definitions’ indeed makes this issue go away. Is that a bug?

Hi Luis - that is what I am checking on- it certainly looks like a bug - I’ll run your example file by the developer for a look, but as far as I can see it is indeed the name that is doing it- I made a new material in a new file and named the material with the long crazy name- the object with this material also hangs up on export. Thanks for pointing this out.

http://mcneel.myjetbrains.com/youtrack/issue/RH-29492

-Pascal

Great. At least I know I was being suspicious for a reason!

My goodness… I just ran into a similar problem. 150MB Mesh file in Rhino ballooning to about 1.2 GB with same settings as Luis above - just Export Material Definitions is unchecked as suggested.

Unchecking Mesh Texture Coordinates shaves off 200 MB of the file to make it 1GB.
Unchecking Export Mesh Vertex Normals brings it down to 500 MB.
Welding Vertices brings it down to 400MB.
Do not export Layer/group Names is checked - No change in filesize.

Is this another bug related to the one above ?

Just for comparison… FBX export of the same file goes within a few seconds. 90MB filesize.

Hi Phil - I don’t know what other factors may come into play, but obj is a plain text format, and not at all efficient in terms of disk space. FBX is binary.

-Pascal

Hi Pascal - thx for the prompt reply, yes, that would explain it… i was not aware of that obj is plain text, should have done my homework via wiki. I was exspecting obj being roughly the same filesize as a rhino file containing identical meshes - seemed true in most other cases. I guess my assumption was not correct then. Many thanks, Philipp