# PVRGeoPOD and problems with UVW channels

**URL:** <https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707>\
**Category:** PowerVR Insider\
**Tags:** pvrgeopod, pvrshaman\
**Created:** [May 26, 2010, 12:28pm UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707 "2010-05-26T12:28:30Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![iaanus](https://avatars.discourse-cdn.com/v4/letter/i/76d3ee/32.png) [@iaanus](https://forums.imgtec.com/u/iaanus)\
**Post date:** [May 26, 2010, 12:28pm UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/1 "2010-05-26T12:28:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![GordonMaclachlan](https://avatars.discourse-cdn.com/v4/letter/g/c68b51/32.png) [@GordonMaclachlan](https://forums.imgtec.com/u/GordonMaclachlan)\
**Post date:** [June 1, 2010, 4:14pm UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/2 "2010-06-01T16:14:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iaanus](https://avatars.discourse-cdn.com/v4/letter/i/76d3ee/32.png) [@iaanus](https://forums.imgtec.com/u/iaanus)\
**Post date:** [June 2, 2010, 6:42am UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/3 "2010-06-02T06:42:08Z")

</div>

Done.

---

<div class="post-metadata">

**Author:** ![Scott](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/scott/32/256_2.png) [@Scott](https://forums.imgtec.com/u/Scott)\
**Post date:** [June 4, 2010, 3:18pm UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/4 "2010-06-04T15:18:48Z")

</div>

iaanus wrote:

Done.

&nbsp;
  

Hi,
  

&nbsp;
  

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?
  

&nbsp;
  

Also, you mentioned in your email when sending us your files&nbsp;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&nbsp;UVW0 so UVW1 becomes UVW0.
  

&nbsp;
  

Thanks,
  

&nbsp;
  

Scott

---

<div class="post-metadata">

**Author:** ![iaanus](https://avatars.discourse-cdn.com/v4/letter/i/76d3ee/32.png) [@iaanus](https://forums.imgtec.com/u/iaanus)\
**Post date:** [June 7, 2010, 9:42am UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/5 "2010-06-07T09:42:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iaanus](https://avatars.discourse-cdn.com/v4/letter/i/76d3ee/32.png) [@iaanus](https://forums.imgtec.com/u/iaanus)\
**Post date:** [June 8, 2010, 9:45am UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/6 "2010-06-08T09:45:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iaanus](https://avatars.discourse-cdn.com/v4/letter/i/76d3ee/32.png) [@iaanus](https://forums.imgtec.com/u/iaanus)\
**Post date:** [June 8, 2010, 11:51am UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/7 "2010-06-08T11:51:24Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Scott](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/scott/32/256_2.png) [@Scott](https://forums.imgtec.com/u/Scott)\
**Post date:** [June 11, 2010, 10:29am UTC](https://forums.imgtec.com/t/pvrgeopod-and-problems-with-uvw-channels/707/8 "2010-06-11T10:29:20Z")

</div>

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.  

&nbsp;
  

The part that I would consider a bug is that the UVs used for mapping channel 1&nbsp;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&nbsp;the&nbsp;"non-orthodox authoring process".
  

&nbsp;
  

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.   

  

&nbsp;
  

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