Imagination PowerVR SDK Blog

PVRGeoPOD and problems with UVW channels

pvrgeopod
pvrshaman

#1

Hi Everybody,





I’m having a hard time with PVRGeoPOD for 3DS Max 2009. The problem occurs with both v1.14 and v1.15. I have objects with a single (diffuse) texture and therefore only one texture map. I would expect all such objects to be exported with one single UVW channel. However they are exported with more UVW channels, usually eight, sometimes less. The additional UVW channels are usually filled with rubbish, but sometimes they contain data that could reasonably be valid uv data, although they have no relationship with the object. Although annoying, that would not be a big deal, but… the “right” data are sometimes put in UVW#0 and sometimes in UVW#1 (and, who knows, there may be even objects using other channels). The choice of the channel seems totally random or at least I could not determine any correlation rule. Of course a POD file exported in this way is barely usable. If this were caused by a bug in PVRGeoPOD it would be so macroscopic that everyone would have noticed, so it must be something wrong that I’m doing. But what? Is there someone who can help me?





Thanks in advance,





iaanus





PS: I can send you a Max file showing the problem, if needed.


#2

As you mention, please could you send this Max file and an example of a broken POD file to devtech@imgtec.com and a screenshot of the settings that you used to export it.


#3

Done.


#4
iaanus wrote:
Done.
 

Hi,

 

I've taken a look at your files and as far as I can tell your scene does have 8 or more sets of UV coordinates. So even though you are only using one of the channels as the data is there it gets exported. The stange part as you have pointed out is that mapping channel 1 (the one used for your texturing) is coming out as UVW#1 instead of #0. How are you generating the UVs for your meshes?

 

Also, you mentioned in your email when sending us your files that the texture isn't displaying in PVRShaman. The reason for this is that PVRShaman only uses UVW#0 for texturing which currently contains incorrect data. One work around for this is to untick everything for UVW0 so UVW1 becomes UVW0.

 

Thanks,

 

Scott

#5
Scott wrote:

I've taken a look at your files and as far as I can tell your scene does have 8 or more sets of UV coordinates. So even though you are only using one of the channels as the data is there it gets exported. The stange part as you have pointed out is that mapping channel 1 (the one used for your texturing) is coming out as UVW#1 instead of #0. How are you generating the UVs for your meshes?



I don't know how those UVs are generated. The Max files are provided to me by outsourced artists and, being a programmer myself, I barely know how 3DSMax works.



Scott wrote:

One work around for this is to untick everything for UVW0 so UVW1 becomes UVW0.



This might fix this particular scene, which contains just one object, although I'm afraid it might break more complex scenes. I'll give it a try, though.



Thanks,



iaanus

#6

While I understand that the Max file may contain spurious data in it, possibly introduced by some non-orthodox authoring process, it’s apparent that 3DSMax knows which is the right UVW channel to use for texture mapping. This knowledge is surely available to exporter plugins, in fact the gw::OBJ exporter produces a file with just the right one UV channel. However, it seems that PVRGeoPOD is blindly exporting all channels without taking such knowledge into account. Therefore, I am convinced that this should be considered as a bug in PVRGeoPOD.





iaanus


#7
iaanus wrote:
Therefore, I am convinced that this should be considered as a bug in PVRGeoPOD.

If you disagree, please consider the following feature request: allow as an option to export only the channels actually needed for texture mapping in alternative to the current behaviour of exporting all available UVW channels by index.



Thanks,



iaanus

#8
iaanus wrote:
However, it seems that PVRGeoPOD is blindly exporting all channels without taking such knowledge into account. Therefore, I am convinced that this should be considered as a bug in PVRGeoPOD.





I don't think exporting extra mapping channels if the artist has added them a bug as it is perfectly reasonable to add extra channels and only use them in the app that you load the POD file into.
 

The part that I would consider a bug is that the UVs used for mapping channel 1 are being exported as UVW#1 instead of UVW#0. I need to investigate this further to determine if it is a bug with PVRGeoPOD or if this is caused by the "non-orthodox authoring process".

 

iaanus wrote:

If you disagree, please consider the following feature request: allow as an option to export only the channels actually needed for texture mapping in alternative to the current behaviour of exporting all available UVW channels by index.

 

Cheers for the suggestion. We'll think about adding it for a future release.