PVRGeoPOD and problems with UVW channels

This topic contains 7 replies, has 3 voices, and was last updated by  Scott 7 years, 6 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #30154

    iaanus
    Member

    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.

    #33951

    Gordon
    Moderator

    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.

    #33952

    iaanus
    Member

    Done.

    #33953

    Scott
    Moderator
    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
    #33954

    iaanus
    Member
    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

    #33955

    iaanus
    Member

    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

    #33956

    iaanus
    Member
    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

    #33957

    Scott
    Moderator
    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.
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic.