OBJ file export bug (or OBJ limitation ?)

test2.3dm (64.8 KB) test2.mtl.txt (429 Bytes) test2.obj.txt (7.2 KB)

Using the included test2.3dm file Rhino creates an obj and an mtl file.
If you import the generated obj file back into Rhino the grouping is off (the two cubes are grouped together)

The behavior can be fixed by adding the left cube in a group alone with itself … but is the export behavior itself correct ? Or is it an OBJ spec limitation ?

Hi Thomas- this happens if the obj is imported back into the original, is that what you mean? If you just open the obj, the groups, as far as I can see, are the same as in the 3dm.


If you import the obj file into an empty Rhino and select the far left cube, you get both cubes being selected.
In the original the two cubes were independent.

Hmm- not here… let me try again…(I tested a file exported by me, not your obj)


You need to test my file (both the 3dm and obj).
The order of the objects matters as well as the method they were made. It is important that the exploded grouped cube appears first in the obj and the non-exploded cube is second. Reading back the obj, Rhino has no way of telling the second object is independent, because the group specifier applies to both.

Hi Thomas- How can I reproduce yours? If I export, I get the expected results (same settings as far as I can see.)


Are you opening my 3dm file and exporting ? or did you make your own to look like mine ?

could you send me the 3dm you use and the obj output you get ?

Hi Thomas- I am exporting from your 3dm to obj-
Does this one behave when you open it?
test2a.zip (1.3 KB)


Your obj was generated differently and it behaves fine.

hmmm- it is an in house build of SR12, but I don’t know if there have been any tune-ups lately that might account for this- @tim , any idea?


Try these steps:

  1. New empty Rhino file

  2. Create a left cube and then a right cube.

  3. Select the left cube, explode and immediately group it.

  4. Select the left (group) cube and the right cube and export selected as obj

  5. import the obj back into Rhino

  6. Both cubes are now selected simultaneously

Got it- that I can reproduce- thanks! No explode needed- just make a one-object group from the cube.



1 Like

Phew ! :slight_smile:

Ok, if we read that obj file, notice how the grouped cube appears first in the file with the “group” specifier and the normal cube appears immediately after as merely an object. Essentially as OBJ is concerned a group state is started at the beginning but never closes to the end of the file.

The problem can become exaggerated if you were to create 100 cubes, then explode and group the first one. (all 100 would be grouped together in the obj)

P.S. Yes, I know that the behavior can be patched by creating a single object group out of the unexploded cube.

On a similar note:

Rhino never saves texture info in the OBJ files?
So far I am assigning textures but nothing registers in the generated mtl file.

Hi Thomas- I see this in a test I just made:

# Rhino
newmtl ping
Ka 0.0000 0.0000 0.0000
Kd 0.5020 0.5020 0.5020
Ks 1.0000 1.0000 1.0000
Tf 0.0000 0.0000 0.0000
d 1.0000
Ns 0
map_Kd AtoZ.png

That is the correct texture there on the last line- and it displays correctly. Do you not see something like this in the mtl file?


How did you do that ?
The last line never shows up for me.

So, Tim tells me the problem is that obj has a way of designating groups but no way to say when the group ends- it only knows by starting a new group. So if a grouped object is written before ungrouped ones and you are using Gs as groups, the objects after the last group will be in the last group. Meanwhile, if you put everything in some group, it will not happen, and we’ll make sure ungrouped objects are written first in the future…


I figured it would go like that. Thanks !