PVR textures appearing Y flipped on GLES 1.1

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

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #29629

    TheDoktor
    Member

    Hi All

    I’m now engaged in the long draw out process of converting all my game textures from DDS DXT textures to PRTC textures.
    I’m using the PVRTexTool that comes with the GLES 1.1 SDK for Windows to convert DDS files to PVR files.
    I’ve
    just written a PVR file loader based on the SDK examples and when I
    load and draw the textures they appear to be flipped in the Y. I’m not
    doing any image processing in my loader, just passing the data straight
    to the glCompressedTexImage2D function. The drawing function is a
    simple 2d quad renderer which draws the DDS texture version the right way round
    on my GL version.
    When I load the PVR file back into PVRTexTool, it appears to be the right way round.
    I’m using the PVRTC 4Bpp RGBA format, the colours & alpha channel are coming out fine.

    Has anyone else had this happen? Am I missing something?

    Cheers,
    TheDoktor

    P.S. This is my first forum post, I’m sorry if I sent it to the wrong forum, I was debating sending it to the GLES forum but this one seemed more applicable.

    #32486

    Gordon
    Moderator

    Hi,

    You are correct: OpenGL and OpenGL|ES textures are flipped vertically by PVRTexTool when compared to textures for other APIs (DirectX 9, D3DM etc.). The reason is to do with the different behaviour of render to texture on OpenGL when compared to other APIs and was the subject of much debate here. The idea is that the orientation of pre-rendered textures (i.e. PVRs) should match the expected orientation of a rendered texture.

    The SDK has been designed to use this orientation; all UVs are set up to render the textures the correct way up given PVR data and PVRGeoPod exporter exports geometry with correct UVs, for instance.

    Your opinion on this would be of interest on this subject as there was a lot of internal discussion about it. Possibly it could be more obvious in the documentation as well.Gordon2008-11-10 12:33:30

    #32487

    TheDoktor
    Member

    Thanks for the response.
    Could you add a ‘Y flip’ command line option to PVRTextool ? (and as an option on the GUI version)
    I’m planning on batch converting all my textures to PVR so this would solve the problem for me. I think it would also be of use to anyone who is doing anything multi-platform.

    Since I don’t use the PVR format exclusively for my textures I can’t really change my render code to flip the UVs. Also I’m still maintaining a GL version with DDS textures. I suppose I could interrogate the texture source and flip at runtime but this seems messy to me.

    I imagine flipping the data on load is not a straight forward affair as the data is compressed.

    Cheers,
    TheDoktor.

    #32488

    Gordon
    Moderator

    Flipping the data on load is not as difficult as you might imagine (even for the compressed formats), but obviously is not very desirable. I’m looking at putting some provision like you’ve suggested into the PVRTexTools for our next release. Your point concerning multi-platform is a good one.

    #32489

    crushforth
    Member

    I’ve noticed there is a -yflip command line option for the command line version of PVRTexTools but it doesn’t seem to be working at the moment.  Would it be possible to get this fixed in a future version?  It’d be really handy as all of our textures are batch converted.

    Apologies if this is already working and I’m just doing something wrong.

    Thanks

    Craig

    #32490

    Gordon
    Moderator

    Firstly, make sure you have the latest version of the PVRTexTool utility from our website.

    Passing a line:

    Code:
    PVRTexTool.exe -ifile.png -f888 -yflip0

    forces no flip.

    Code:
    PVRTexTool.exe -ifile.png -f888 -yflip1

    forces a flip.

    Please post again if this doesn’t work for you.

    #32491

    crushforth
    Member

    Ok thanks.  I was using ‘-flipy’.   Everything is working perfectly now.

    Thanks again.

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.