A lifetime ago I wrote an OBJ importer for Maya(1.5) that supported Wavefront OBJ materials. Believe it or not Maya never fully supported all aspects of OBJ when TAV crossed over to Maya. Anyway the point is that OBJ has some similarities to VRML, not in structure but in priniciple. It is a loose standard in which the same model can be written multiple ways, especially in terms of where Shading Groups are defined or begin. The problems that most people experience with OBJ import export is that custom exporters are often not bound to all of the OBJ specification because they are writing their OBJ output to their own standard. Any OBJ export read by someone else's importer, has about a 60/40 chance of working because the standard is so weak.
That not to say the OBJ format is not safe or solid, it is, if it can be read. A lot of importers ignore parts of the standard, some write things which others never supported, materials for example. Things like groups are the most common problem and can be placed almost anywhere and some importers will read and figure groupings out while others will bomb horribly. There are similarities here between OBJ, VRML, IV, and IGES, again strictly on the principle of each standards original intent that they be able to support simple and complex structures at the same time, defining almost the same thing, with little thought about what others were going to eventually try and do with these open(ASCII) standards. The even larger problem faced by exporter writers is that they largely only tested their own exports when importing, so theyre only guaranteed to work 99% of the time when written and read by the same application. Sometimes people pick up an OBJ they get off the web to test with, not knowing that the OBJ they have might be considered non-standard by the TAV OBJ spec. It was a real problem, one that Alias never solved. At one point I think there were at least two and possibly three obj converters that shipped with Maya. If one didnt work you tried the other, if those didnt work you tried Okino, or Deep Ex or Softimage, or well you get the picture. Somebody's converter was almost always bound to work, the question was, whose? Then you danced it from one app to the other till you got a more stable OBJ in the target app. What was incredibly interesting in one of those exercises was to see how different each OBJ was along the way exiting each app. Having said this, OBJ still was among one of the more stable formats, if not a bit lean in some areas of support. However, if memory serves right, I think it could support polys and curves in the same file so it wasnt a crude standard by any stretch. It did however get caught in limbo between TAV and MAYA and never really quite recovered from that. Still OBJ was a great format to work around if you needed to write your own custom models. For all its best qualities it still an archaic format though, older than some people on this list I would guess. The fact you are still using it a testament to its staying power. The thing you have to know when using OBj though is that the problem can be the file, the converter or both, and its often really hard to know what if you don't have access to the original specs or source code of the converter. I realize this response doesnt solve your problem but it may provide some inisght as to why it is a problem. Regardless the problem you are having it could be much worse. There were formats however that should have been relegated to the trash bin of CGI decades ago, OBJ is not one of them....DXf however comes to mind here. Joey ________________________________ From: [email protected] [[email protected]] On Behalf Of Matt Lind [[email protected]] Sent: Thursday, April 26, 2012 7:50 PM To: [email protected] Subject: RE: OBJ exporter To my knowledge OBJ supports one property of each type per mesh, but you should look up the OBJ specs to verify as I’m merely reciting from memory and never touch OBJ myself. I’m only familiar with the bugs that get reported to me which I must investigate. In the case of softimage, the bug is the OBJ exporter does not make the distinction between Texture UVs, User Normals, and Vertex Colors when deciding what data to export. It looks for the first sample cluster property it can find and exports that. I think the error comes about because the OBJ exporter was written before User Normals truly existed and was probably coded on a false assumption about what would be available on a mesh for export. OBJ is a pretty simple format, even a novice scripter could write an OBJ importer/exporter if they wanted to. I haven’t studied the OBJ files from Softimage vs. Max/Maya, so I don’t know why the resulting file would be larger. Since OBJ is ASCII, probably a case Softimage being more verbose with descriptions. OK, official contest: Who can write the best OBJ importer and exporter toolset. Deadline: August 1, 2012 Winner gets a piece of Softimage swag from my 20 year archive. You must come to my annual Siggraph dinner to claim the prize ;-) And……..GO! Matt From: [email protected] [mailto:[email protected]] On Behalf Of Williams, Wayne Sent: Thursday, April 26, 2012 12:01 PM To: [email protected] Subject: RE: OBJ exporter Yeah, I remember this convo from a ways back. Reordering things in the explorer view to get them to export properly was the solution you and szabolcs had mentioned. So you say obj only supports one of each type of sample cluster property per mesh. Does this mean that it supports only one property per mesh being exported…..or it supports one of each “type”…..i.e. You can export user normals and one uv set………..but you wouldn’t be able to get two uv sets out with a user normal as well? I’m guessing you mean the latter as it appears to be the case with max/maya obj export when getting smoothing groups/normals into game engines with UV’s intact. Also, what was it again that makes the .obj files so much larger when exported from Soft? The way they handle UV’s is inherently different which adds to the amount of data?? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matt Lind Sent: Thursday, April 26, 2012 2:13 PM To: [email protected]<mailto:[email protected]> Subject: RE: OBJ exporter BTW – I reported the bug long ago. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matt Lind Sent: Thursday, April 26, 2012 11:12 AM To: [email protected]<mailto:[email protected]> Subject: RE: OBJ exporter There is a limitation of OBJ only supporting 1 of each type of sample cluster property per mesh. But in the case of the Softimage OBJ exporter, I’d call it a design flaw as the user should be able to specify which of the existing sample cluster properties should go out the door. For example, an object with 2 texture projections. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Williams, Wayne Sent: Thursday, April 26, 2012 11:10 AM To: [email protected]<mailto:[email protected]> Subject: RE: OBJ exporter Is that an inherent limitation to the obj format itself? User normals and uv’s appear to come out of max/maya properly no? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matt Lind Sent: Thursday, April 26, 2012 1:33 PM To: [email protected]<mailto:[email protected]> Subject: RE: OBJ exporter The issue with the OBJ exporter is it only exports a single sample cluster property. A sample cluster property is any of type: Texture UVs, User Normal, or Vertex Color. In our experience the OBJ exporter chooses and exports only the most recently created sample cluster on the object. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Szabolcs Matefy Sent: Thursday, April 26, 2012 12:24 AM To: [email protected]<mailto:[email protected]> Subject: OBJ exporter Hey guys, Can somebody (Stephen ;) ) confirm that the OBJ exporter is still broken? My issues so far: - UVs are not optimized (not welded) - If there is a user normal cluster UV data is not exported Cheers Szabolcs ___ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Crytek GmbH - http://www.crytek.com - Grüneburgweg 16-18, 60322 Frankfurt - HRB77322 Amtsgericht Frankfurt a. Main- UST IdentNr.: DE20432461 - Geschaeftsfuehrer: Avni Yerli, Cevat Yerli, Faruk Yerli
