Softimage is all too guilty of this problem far too often. Not just with
.obj, but with dotXSI and most other supported formats as well. I'm writing
a frickin' SI3D exporter now for this very reason as the ones supplied by
Softimage don't work.
I can understand and accept cases where an importer doesn't do a perfect
job, but under no circumstances should it ever crash or corrupt the host
application. Data should be ingested and validated before attempts made to
use it. This is a perennial weak spot of Softimage as far as I can
remember.
.Obj can be binary or ASCII, and the group option was to support CAD (DXF)
data back in the day. later was used for shading groups, but as you said,
repurposed by many people for things like defining clusters or materials.
Another area to check is the vertex normal data section. The official
format spec only supports 3 numbers per line as X, Y, and Z. Some
importers/exporters secretly stash an additional RGB triplet in there for 3D
printing purposes as userdata to print textures as vertex colors. If
importers do their due diligence the extra data should be ignored and not
cause any problems, but as you've clearly seen, most importers don't do
their due diligence. They make many false assumptions about the data
leading to problems.
Is there any strong reason why people still use .obj? Isn't collada or
another format more capable? .Obj is a horrible format. It should be
retired.
Matt
Date: Fri, 20 Feb 2015 16:38:21 +0000
From: "Ponthieux, Joseph G. (LARC-E1A)[LITES]" <[email protected]>
Subject: RE: OBJ import problems
To: "[email protected]"
Look deeper in the files. Compare the ?group? command with those files that
don?t work. To do this search for the ?g? command. Does the information
following them differ greatly? Are there any ?g? commands at all? Some
exporters format the obj in such a way that it can import what it exports
just fine, but other exporters may adhere to a more strict interpretation
(or less strict) of the OBJ spec. Are there any commands other than v, f, or
g?
If you know what you are doing it can be as simple as adding or removing
those commands as needed, or not needed, by the target importer. If there
are no g commands in the offending file try adding one to the file. They are
usually inserted after the vertices and before the face declarations (but it
is not restricted to that organization).
Everything will depend on the ?nature? of the importer. The only way to know
the true ?nature? of your importer is to find one file that works and hack
the other files to match it. Omit anything superfluous (smoothing groups,
materials, etc) from the offending file until it starts to adhere to the
same structure as the file you know works. Things like smoothing groups etc
you may want Soft to rebuild anyway as approximation.
I seriously doubt that the decimal point values will have any adverse
effect. You are looking for things that the importer was simply not written
to recognize. Or add things it requires. Either commands or command
structure. Obj can support curves, surfaces and host of other things but
you rarely see that anymore, its mostly facet data.
The issue with groups is kind of weird. I think the ?g? group was originally
intended as a way of managing shading groups. You will typically see ?g?
followed by a usemtl statement for example. But a lot of developers
repurpose it as a group in the traditional sense to form hierarchies or
facet groups. I think TAV users used it that way as well adding to the
confusion. Soft gives you the option to import these groups as shading
clusters or objects for example.
Ultimately all you probably want from the file is the vertices and faces.
Theoretically you could delete just about everything except the v, f, and g
commands and clean up the file post import.
The problem is not restrictive to Soft. Maya had multiple obj importers even
when it first arrived. One came standard and another came as part of the cad
connect package I think. If one failed you would try the other. And to my
knowledge no one has ever created a reliable material library converter for
obj into Maya that can support the entire mtl spec.
If an obj is significantly clean and compact, there is no reason for it to
fail unless the data was written in a nonstandard way that only that
exporter understands or an otherwise valid command is present that the other
importer is simply ignorant of.
--
Joey Ponthieux
LaRC Information Technology Enhanced Services (LITES)
MYMIC Technical Services
NASA Langley Research Center
__________________________________________________
Opinions stated here-in are strictly those of the author and do not
represent the opinions of NASA or any other party.
