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.
Pascal,
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.
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.
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.
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…