Thank you for the elaborate answer Joey. It helps to understand what these flags mean. The problem with reviewing the file in text format is the sheer size - it takes ages to inspect.
Morten Den 20. februar 2015 kl. 17:38 skrev "Ponthieux, Joseph G. (LARC-E1A)[LITES]" <[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. > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Morten > Bartholdy > Sent: Friday, February 20, 2015 7:13 AM > To: [email protected] > Subject: Re: OBJ import problems > > > > Thanks for pointing that out Rob - I had forgotten about that tool :) > > I have seen my fair share of bad models from Turbosquid too, but her ewe > are talking about 4 different models from different modelers - the common > denominator is I can see in the obj file (in Wordpad) that it was created > with DeepExloration, and when I compare a file from Turbosquid with the > same imported to and from Maya as obj, the Maya one has 6 decimals while > the Turbosquid one has 5. I don't know if this can throw off the Soft > importer, but stranger things have occured. > > Morten > > > > > > > Den 20. februar 2015 kl. 11:08 skrev Rob Wuijster < [email protected] > <mailto:[email protected]> >: > > > > > What about the AD FBX converter? It can open fbx, obj and 3ds afaik, and > > convert into fbx. > > Might be the simplest way to go? > > > > And it doesn't have to be the obj importer, I've seen my share of crappy > > models from Turbosquid ;-) > > > > > > > > Rob > > > > \/-------------\/----------------\/ > > > > > > > > On 20-2-2015 10:44, Morten Bartholdy wrote: > > > > > I have purchased a number of models at Turbosquid and was relying on > > > importing obj versions into XSI. The problem is these obj's hang Soft > > > (2013 > > > SP1) - trying to use Mudbox as intermediate converter reveals that Mudbox > > > can't open them either - what's up with this? Maya however opens them > > > fine, > > > so I can export them as fbx from there. > > > > > > So I have a workaround, but after exporting an obj from Maya which I can > > > open in Softimage I am thinking if there is a way to fix the Turbosquid > > > versions so Soft will like them? I just installed the guruware obj > > > importer > > > which does the job, so obviously there is a problem with the native obj IO > > > module in Soft :/ > > > > > > Morten > > > > > > > > > > > > > > > > > > > > > > > > No virus found in this message. > > > Checked by AVG - www.avg.com <http://www.avg.com> > > > Version: 2015.0.5646 / Virus Database: 4284/9143 - Release Date: 02/19/15 > > > > > >
