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 <x...@colorshopvfx.dk> 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 <speye...@hotmail.com>: > > > 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]" <j.ponthi...@nasa.gov> > > Subject: RE: OBJ import problems > > To: "softimage@listproc.autodesk.com" > > > > 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. > > >
