Hi, I ran into some OBJ export problems after installing PP2012. I contacted SM support and now we could use some help to nail this bug down.
So if you have the time, please help :)

1. Please download this file (a free piano model in 3DS format):
   http://archive3d.net/?a=download&id=30571

2. Import the 3DS file to PP2012.

3. Export the piano to OBJ (default settings).

4. Load the OBJ in Octane or C4D.
   (Octane demo here: http://refractivesoftware.com/downloads.html )

Do you get an OBJ import error, then please reply to this post with following info:

Your OS version + 32bit/64bit:
Your OS language:
Any other programs it will not load in:

What happens to me is that both of my PC's which are running Vista 64bit, gets an error when importing the OBJ to Octane. I also seen this with commercial products which is far worse.
But I only get the error when I export from PP2012. Any previous Poser versions export the OBJ correctly. Another person I know in germany also get's this error. So I fear more will have this problem, that's why I need more tests by you guys.

Octane's support tells me that the exported OBJ file from PP2012 has vertex errors and will therefor not load in Octane. He also tested it on C4D where it also failed to load. 

SM did not have any problems importing the OBJ to Octane. So it's kind of hard trying to bug hunt, if they can't reproduce the error.

My guess is a longshot, but I think PP2012 running on US and ENGLISH OS versions works fine, while other OS language would have problems. But that's a guess. For now I just need to know if anyone else gets an error when importing the OBJ to Octane or C4D or any other program where you get an error.

try changing your decimal. if I remember right, you use a , not a . ?

that would explain why SM did'nt have the error (they'd be using the . )...

If not, you can use MeshLab to do a simple Import 3DS, then just Export as OBJ, and viola'.

That's what I just did, and rendered it in the Octane demo, which killed me since I own the full version lol

MeshLab can be downloaded here, and it's free:

http://meshlab.sourceforge.net/

Changing decimal from , to . didn't work.

Yes, you need to use PP2012. That's the whole point of this test.

It might be better to post the OBJ file you're having problems with, because it looks like others aren't having the same problem, and the best way to find the problem is by inspecting the troublesome file.

Failing that I'd suggest that you try to load it into UVMapper and resave to see if that cleans it up or fails when reading.

As I mentioned, I'm not the only one with this problem.

I already know the exported OBJ has incorrect vertex normals for example in lines 18380 and 18423. The question is why PP2012 does this when PP2010 doesn't.

I have zipped both OBJ's exported from PP2012 and PP2010 as there is a difference.

The forum didn't upload the file so here is another link.

piano2.zip

Based on the differences between the two files, I suspect the problem is or related to one or more of :-

1. The PPro2012 OBJ refers to an MTL file (pianio.mtl) whose name doesn't match the OBJ file.
   This may be the root cause of the problem if it a) doesn't exist (perhaps because Poser wrote an MTL with a name matching the OBJ) or b) it does exist but the importers for Octane and C3D don't cope with the basename not matching the OBJ.

2. The material and group names contain spaces (this isn't allowed by the OBJ spec) but PPro2010 did reproduce them (spaces in group names will lead to unintended consequences in apps that use mutliple groups for their own purposes), whereas PPro2012 has truncated the material and group names at the first space, leading to some materials no longer having a unique name and thus have been collapsed on either import or export (the same might be true for groups but they're less likely to have been left with sequential default names).

3. As the vertex coordinates are quite different, there's an outside chance that something really subtle is wrong there (with an even smaller chance that the texture coordinates are responsible).
   I'm assuming therefore that the differences in vertex positions are due to the object having been moved after import, and the texture coord differences are pretty certainly only due to rounding affects.

No doubt, it is a Poser 2012 bug:

From your exported 2012 piano

line 18380
vn -1.00014 0.0117139 0
vn 0.999748 0.00409131 0
vn 0 0 0 vn 1.00024 9.31469e-005 0
vn -0.999756 1.70052e-005 0
vn 1.00017 0.00492969 0

line 18423
vn 1.00014 -0.0104035 0
vn 0 0 0 vn 0 0 0 vn 1.00024 -3.12127e-006 0
vn 0.999756 0 0

It is mising the end of line character and so you have two or three vertices normals in the same line.

There are more wrong lines like this in the normals sections

The effect of this error will depend on what does the progran that reads this file.

1- If the programa doesn't use normal information in the obj file, the model will import without any problem just because all the normal information (right or wrong) is ignored.

2- If the program doesn't use normal information, but check the sintaxis can report that the obj file is wrong

3- If the program use normals, it will read the first normal in the line and ignore the second one or report an error of extra characters in the line. In any case it will be missing normals (less normals than vertices) and the read normals will all be wrong (a vertex has the normal of another vertex)

Hi just FYI I cant run the octane Demo but I got both versions of your model to import into C4D R11 Studio OSX with no issues

using the native import and Riptide pro.

Cheers

Thanks for testing it Wolf. Do you use a US/English OS ?

The PP2010 OBJ file should load fine in any program. It's the PP2012 OBJ file that is the problem.

Sounds strange if you could load it into C4D if Refractive Software couldn't with their version of C4D. But maybe there are difference import settings?

I found 2 free programs that will not load the PP2012 OBJ file.

Sculptris and MeshLab.
Sculptris will crash while loading the file.
MeshLab gives this error message:  Vertex normal statement with less than 3 coords

Sounds like Meshlab also finds the problem that kawecki also pointed out in his post.

The problem should not have too importance because most of the 3d programs don't use the normal information from the obj file, but the error still exists and depending on how each software deals with this error many things can happen:

1- The error is ignored and the model loads without any problem.

2- The software display an error or warning message, but the mesh is loaded without problems.

3- The software display an error message and refuses to load the mesh.

4- The error makes the program crash.

It looks that PP 2012 obj exporter each time that find a normal 0,0,0 no end of line character is generater and the next normal is added to the same line producing a wrong sintaxis and data in the obj file.

MeshLab is an excellent program and source of inspiration, but is buggy and very weak. Any model that has something wrong makes MeshLab crash.

The PP2010 OBJ file should load fine in any program. It's the PP2012 OBJ file that is the problem.
Sounds strange if you could load it into C4D if Refractive Software couldn't with their version of C4D. But maybe there are difference import settings?"

Hi I use an English version of C4D
Default  .obj import settings.

The  PP2012 Version of your piano model also imports flawlessly into MODO401 and Blender 2.5
as well as the stand alone version of Maxwell Render

All  OSX versions

hope this helps

Yes, I know the OBJ we are talking about can load fine into other program incl. Vue, Daz Studio, Silo and Hexagon.

As Kawecki says, it's how the programs check the file it's about to import.

But I use Octane as my main rendering engine and Sculptris to make morphs. So I'm double forked :)

"Yes, I know the OBJ we are talking about can load fine into other program incl. Vue, Daz Studio, Silo and Hexagon."

Hi,
May I assume that you have already tried exporting a "New" copy from all of your modeling apps to see if that creates a "cleaner" copy for Octane???

Cheers

Kawecki is correct that it's not writing the EOL whenever there's a vn 0 0 0 entry. If correcting those lines fixes it then all is good. Opening the file in UVMapper should work also. It reports out of range UV coordinates on loading BTW.

Quote - Hi,
May I assume that you have already tried exporting a "New" copy from all of your modeling apps to see if that creates a "cleaner" copy for Octane???

Yes, I can fix it by ripping out the vertex normals or have another program make a cleaner file as you say. But that still doesn't fix the Poser export problem.

Open a ticket with SM, it should be an easy fix - famous last words :-)

And tell them, the python output console has the same issue sometimes. It does seem to not emit newlines sometimes.

Import in Hexagon 2.5 works fine.

Import into Vue 7i works, too, but the result is questioanable compared with the imported original 3DS (see image).

couldn't find any missing EOLs in the file, though. 

Win7 64Bit, german, pp12 64Bit, Octane 2.52 64Bit 

Thanks for testing ehliasys.

So I guess we have 2 german and 1 danish OS version, that have problems loading the OBJ into Octane, and no one with us/english OS version?

I found 2 more items that wont load as OBJ into Octane.
The Genesis car from DAZ 3D and the HeliJetPack located in propsVehicles from the PP2012 content package.

"I found 2 more items that wont load as OBJ into Octane.
The Genesis car from DAZ 3D and the HeliJetPack located in propsVehicles from the PP2012 content package."

Curious - do they also contain  'garbaged' vn 0 0 0 lines? Is SM using 64 bit Octane or 32 bit? Between 32/64, OSX/Windows, German/English, program versions/revisions... it's hard to know what might be going on. I would think maybe some king of character encoding issue between the language versions. I know that OSX uses a different EOL sequence but getting into Unicode etc. is above my pay grade :-) The multiple vn entries on one line see to be the obvious suspect, but even that may be misleading - though it needs to be fixed.

Yes, the exported OBJ's contains this VN 0 0 0. Here's one line of the many I found in the Genesis car from DAZ 3D: "vn 0 0 0 vn 0.938877 0.338507 -0.0630376".

I spent all day yesterday trying to get SM support to look at this problem, but I feel they saw me as a 13 year old who just got Poser for the first time. I was being dragged around in circles, and they never addressed the lines in the OBJ file. I think they looked for a user error only. I had of course tried everything before I submitted a ticket. So I closed the ticket today, as I could see we were getting nowhere. Not the first time I experienced this with SM support. They just wear you out until you give up :(

One of the supporters was using the Octane demo. I don't know if that is 32 or 64bit. But she couldn't load the OBJ my PP2012 made, but it worked for her, when she exported the OBJ on her Poser system.

I know this is an extremely hard bug to fix - even more when SM can't reproduce it. That's also the reason I closed the ticket, as this takes someone who knows the coding behind PP2012 to understand.

I have about 200 PZ3 scenes I use to setup new scenes with, and going bug hunting everytime I can't load it into Octane is just too time consuming. And since it works fine in PP2010 I might just end up returning PP2012 and stick with PP2010.

Quote - I know this is an extremely hard bug to fix -

It is not. Once the bug is well defined it is very easy for whom made the code to fix it. There are two cases that makes very difficult to correct bugs. 1- The bug appear to happen at random and you cannot make the bug happen at your will. You tests, test, test and all is ok, you return it to the user and the bug happens again. 2- The police of the company. Many companies refuse to acknowledge that their product or service has something wrong. The user is always guilty. They turn the user around and around until he/she desist. The bug report and its details never reach the responsible for the code and is he/she that can fix. Even he is aware of what happened he is not allowed to fixed it because it would recognize that the company had a faulty product or service and it were sold hundreds or thousands of it.

well, i don't believe that SM really thinks they have a bug-free PP12 out :D

those support tickets are a pita. no matter how detailed you are, they always want information you gave them before. i have to wonder if they really read the things? i'm fairly computer experienced, i do programming, i know what infos are needed when reporting a bug - so i had the one or other face-palm moment. after all my issue was delegated to the programmes - well, at least that's i've been told :)

but posting this issue over at the official Poser forum at RDNA might bring some better responses.  

"...this takes someone who knows the coding behind PP2012 to understand."

True. Fixing it might require them setting up a German Windows system though heh, heh. This is one case where it would be nice if Poser was still owned by was it EGISys or whoever the German company was :-)

Copy this text and save it with an obj extension, then import it in PP2012 with all options unchecked and then export it again as obj. Look at the exported obj and see if there are more than one normals in a single line.

v -0.05 0.10 -0.05
v -0.05 0.10  0.05
v  0.05 0.07 0.05
v -0.05 0.07 0.05
v  0.05 0.10 -0.05
v  0.05 0.10  0.05
v  0.05 0.07 0.05
vt 0 0.00
vt 1 0.00
vt 1 1.00
vt 0 1.00
vt 1 0.87
vt 0 0.75
vt 1 0.75
f 2/1 6/2 5/3 1/4
f 7/5 4/6 3/7

Quote - Copy this text and save it with an obj extension, then import it in PP2012 with all options unchecked and then export it again as obj. Look at the exported obj and see if there are more than one normals in a single line.

It exported fine. No double normals in a single line.

Well, it was a try. This mesh create three vertices with normals 0,0,0