pvrtexlib

This topic contains 9 replies, has 2 voices, and was last updated by  Tobias Hector 5 years, 7 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #30785

    I am trying to write a texture to the “old” Version2 file format but I can’t get it running.

    CPVRTextureHeader header(
                 PVRStandard8PixelType.PixelTypeID,
                 image.height(),
                 image.width(),
                 32,
                 1, // num mipmaps
                 1, // num array members
                 1, // num faces
                 ePVRTCSpacelRGB, // colorspace
                 ePVRTVarTypeUnsignedByte, //var type
                 premultipliedAlpha
                 );

    CPVRTexture sDecompreseedTexture(header);

    // copy image data

    ok = sDecompreseedTexture.saveFileLegacyPVR(fn, eOGLES);
    [/CODE]

    I always get false as response and a file with 0 bytes is created.
    Saving it with saveFile works wirhout any problems.

    I did not find any way to get some debug information, error message or something else that might help to solve my problem.


    AndreasLoew2012-03-19 13:48:26[CODE]
    CPVRTextureHeader header(
                 PVRStandard8PixelType.PixelTypeID,
                 image.height(),
                 image.width(),
                 32,
                 1, // num mipmaps
                 1, // num array members
                 1, // num faces
                 ePVRTCSpacelRGB, // colorspace
                 ePVRTVarTypeUnsignedByte, //var type
                 premultipliedAlpha
                 );

    CPVRTexture sDecompreseedTexture(header);

    // copy image data

    ok = sDecompreseedTexture.saveFileLegacyPVR(fn, eOGLES);
    [/CODE]

    I always get false as response and a file with 0 bytes is created.
    Saving it with saveFile works wirhout any problems.

    I did not find any way to get some debug information, error message or something else that might help to solve my problem.


    AndreasLoew2012-03-19 13:48:26

    #35575

    Hi Andreas,

    If you switch the var type to “ePVRTVarTypeUnsignedByteNorm” this will fix your problem.

    Thanks,

    Tobias

    #35576

    ePVRTVarTypeUnsignedByteNorm did not make any difference but setting depth from 32 to 1 did somehow solve the problem. What value is depth supposed to have?

    I diffed 2 files created with the “old” and the “new” version of the lib and got some changes in the header – the rest seems to be identical. The changes are that the mask bits (dwRBitMask etc) are all 0 instead of set to a useful value (e.g. 0xff000000 like it was before).

    #35577

    Ah sorry, didn’t actually notice the depth of 32 there… This value is for 3D textures, not pixel depth. It’s basically the number of z-slices in a texture. The old PVR2 format doesn’t support 3D textures so it’s unable to save to this type – 1 is thus the correct value in this case. The number of bits per pixel are instead taken care of in the PixelFormat in PVR3.

    The “Norm” designation should also be necessary – if it’s not returning false without “Norm” then I need to look over the code, as this is not a valid combination for this function. If it’s not returning false then it will probably be giving you an invalid texture. If it is saving, could you try opening it in PVRTexTool to see what’s being output?

    Thanks,

    Tobias

    #35578

    The “Norm” was applied later during a Transform I still had running… so this seems to be fine.
    The file looked fine in the Tool.

    The only thing that’s still different is that the mask bits are not set in the header.

    #35579

    Hi Andreas,

    Ah right fair enough. Well that makes sense then.

    The bit masks were always rather unnecessary – the pixel formats have always been handled by the pfFlags in PVR2. The recommendation for reading PVR2 files is generally to just ignore these masks for this reason, which is the same reason that they won’t be set when using the legacy format save.

    Thanks,

    Tobias

    #35580

    I am now tying to save data as RGB565. pixeltype = PixelType(‘r’,’g’,’b’,0 ,5,6,5,0);

    The file writes and everything seems to be ok – result is true for conversion & writing data.

    But now I get 0xffffffff in the dwpfFlags field. Which means that the complete file is invalid.

    This is really frustrating. While the new API adds nice new features you removed some really important stuff like useful error messages. I currently have no chance to know what is going wrong.

    And how am I supposed to print useful error messages if the API says that everything is ok?

    #35581

    Additionally some information is missing in legacy format – such as the PVRTEX_ALPHA is never set.

    When exporting RGB565, RGBA4444 and RGBA5551 seem to be completely broken – other formats seem to work.

    AndreasLoew2012-03-19 21:49:15

    #35582

    Hi Andreas,

    The 565 issue is a known problem, I’ve fixed this in the next build and it should be available shortly. Equally I’ll check the other two formats but the fix I’ve done should cover all of them. The fact that it’s outputting any file at all is a bug which shouldn’t have happened. I assume you’re using UnsignedShortNorm for all of these?

    PVRTEX_ALPHA was included before for PVRTC textures as that was its original purpose – to differentiate between RGB and RGBA – an OGLES1.x consideration. Maintaining it generally meant scanning the entire texture for any non-opaque blocks and setting the flag at various points – which was an unnecessary slowdown.

    With PVR3 the idea is that the header stores only data that is necessary to load the format into any given API. Further data, such as whether any transparency is present should be stored into the meta data. The meta data was added mostly for cases like this, where a user wants to store data that the format doesn’t specifically support. So if you wish to use similar functionality, create a MetaData type to store it in, and scan for alpha data. Alternatively if you only wish to know if a format supports alpha, checking for the “a” character with a switch statement to mop up compressed formats will also work. I can add in a “scan for alpha” function in the next release – I’m already planning on adding functions to tell you various facts about a texture so this should fit nicely.

    The main reason I fell back to true/false returns instead of error messages was because often, functions only had one error message anyway – with too many of them being just “failed to do function”. At some point I plan to expose a debugging interface that will produce a log of various events and any problems that might occur, but sadly there was no time to get it into this release.

    Hope that helps,

    Tobias

    Tobias2012-03-20 09:32:31

    #35583

    Hi Andreas,

    Just realised that my advice about the MetaData is moot as you’re still using PVR2 files. As with the bit masks, the PVRTEX_ALPHA is technically unnecessary and a bit of a pain to support properly. When using the specific alpha PVRTC formats the PVRTEX_ALPHA flag is set – which is the only time it actually becomes technically necessary.

    Otherwise, the advice remains the same about the scanning for alpha data, you’ll just need to check if your alpha byte is less than the maximum value. Assuming you’re using RGBA8888 data, for similar functionality, just check every fourth byte to see if its value is less than 255. Unfortunately as this is legacy it will mean manually editing the file though.

    If you’re having too much trouble, it might be worth suggesting that you use the 2.9 library instead as this still has full support for PVR2 files, unless there is any specific functionality you need from the new library? If you’d like to pursue this instead then I can provide you with a drop of the 2.9 library if you email us at devtech@imgtec.com.

    Thanks,

    Tobias

    Tobias2012-03-20 10:01:47

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