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.

Josh English
eng### [at] spiritonecom

Post a reply to this message

Josh English wrote:
> 
> Some of you may remember me from way back, well at lest three years ago
> when I was a regular here.

Was it that long ago already? Wow! Can't help with your problem but just
wanted to pop in to say hi.

-- 
Ken Tyler

Post a reply to this message

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.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Ken wrote:
> 
> Josh English wrote:
> 
>>Some of you may remember me from way back, well at lest three years ago
>>when I was a regular here.
> 
> 
> Was it that long ago already? Wow! Can't help with your problem but just
> wanted to pop in to say hi.
> 
Hello. I've been unemployed since March 2001 and and I am now two months 
away from getting my Masters of Arts in Education. I've missed this 
group, and I hope to return in some form soon.

Josh

Post a reply to this message

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

> Despite appearances, my reply address is valid.
Brilliant idea. I like it.
	Andrel

Post a reply to this message