POV-Ray : Newsgroups : povray.advanced-users : Poser, OBJ, and Mesh 2 : Re: Poser, OBJ, and Mesh 2 Server Time
28 Jul 2024 20:33:41 EDT (-0400)
  Re: Poser, OBJ, and Mesh 2  
From: Josh English
Date: 8 Mar 2004 11:45:32
Message: <404ca32c@news.povray.org>
Mike Williams wrote:
> Wasn't it Josh English who wrote:
> 
>>Some of you may remember me from way back, well at lest three years ago 
>>when I was a regular here. I've got a problem and I just can't seem to 
>>get it solved.
>>
>>I am using MacOS 9.1 and I have Poser 2.0, Python 2.2, and POV-Ray 3.5. 
>>I've created a Python script that converts an OBJ file created in Poser 
>>into a POV-Ray include file with a mesh2 object. I add the code to use 
>>one of the default Poser textures in the POV-Ray scene file with UV 
>>mapping turned on, and I get something that is just not right. I've 
>>posted an image in p.b.i that shows the problem.
>>
>>Does POV-Ray use a different origin that Poser 2 for the UV mapping? I'm 
>>taking the same coordinates from the OBJ file and writing them into the 
>>mesh2 object one a one for one basis.
>>
>>Any clues would be appreciated.
> 
> 
> The "v" values from an OBJ file translate directly to mesh2
> vertex_vectors, and the "vt" values translate directly to mesh2
> uv_vectors.
> 
> The "f" values need to be shifted own by one, since POV starts counting
> at zero but OBJ files start counting at one. E.g. the face "f 1 2 3"
> becomes <0,1,2> but if you'd missed that shift I would have expected the
> output to appear wrong in other ways than just the uv mapping.
> 
> If you think that you might have made some sort of silly mistake in your
> Python code, I'd be happy to take a look at it. 
> 
> Despite appearances, my reply address is valid.
> 


I found a few silly mistakes and it looks better. I've posted my Python 
Code at http://www.spiritone.com/~english/code/objconverter.html with an 
updated picture. As far as I can see I am still successfully moving the 
indexes down by one for the face index, normal index, and uv index. The 
only thing I can think of is that I've confused the order of the triples 
in a line like:
f 1/221/1 2/219/2 3/216/3
I'm treating this as:
postion/uv/normal position/uv/normal position/uv/normal

I imagine that if the mesh2 format found a uv vector with three 
components it would break down, similiarly if it got a normal vector 
with only 2 components.

My Python script is very brute force.

Thanks,
Josh English
eng### [at] spiritonecom


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.