Good to know some more of the in's and out's of this. I agree Turbosquid should throw away obj and deliver a more uniform package option of collada/fbx and additional platform specific formats dependant on content and original creation platform.
MB Den 21. februar 2015 kl. 00:29 skrev Matt Lind <[email protected]>: > 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. >
