Thanks for the tip Alan - that is quite cool. FYI BTW Turbosquid has been quite helpful and converted all the problematic models to fbx for me now.
Morten Den 24. februar 2015 kl. 14:36 skrev Alan Fregtman <[email protected]>: > > Don't forget that Houdini has some fantastic IO and topology cleanup stuff, > too! Even in the free Apprentice version. (Look for the "clean" node.) > > > On Mon, Feb 23, 2015, 8:31 AM Morten Bartholdy < [email protected] > <mailto:[email protected]> > wrote: > > 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] > > <mailto:[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] > > <mailto:[email protected]> > > > > Subject: RE: OBJ import problems > > > To: " [email protected] > > <mailto:[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. > > > > >
