bFlipTextureV Maya export option breaks POD

This topic contains 2 replies, has 2 voices, and was last updated by  jordo 8 years, 4 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #29882

    jordo
    Member

    Okay, aside from spurious issues with the exporting of node data, I’ve run into a very consistent issue with the bFlipTextureV option in the Maya exporter.  If it is not selected, the model exports fine – if it is selected, the interleaved vertex data buffer is two bytes too short in the POD file, causing file load to fail after the interleaved data chunk is read.  If I push the file read cursor (m_BytesReadCount) back two bytes after reading the bad interleaved vertex data, the rest of the file loads fine (though the vertex data renders garbage).

    Here are the options when the file works:

    Code:
    bFixedPoint=0
    bFlipTextureV=0
    bInterleaved=1
    bSortVtx=0
    bTangentSpace=0
    cS=2
    dwBoneLimit=9
    ePrimType=0
    eTriSort=0
    exportBoneGeometry=0
    exportControllers=1
    exportGeom=1
    exportMatrices=1
    exportMappingChannel=1
    exportMaterials=1
    exportNormals=0
    exportObjectSpace=1
    exportSkin=1
    exportSplines=0
    exportVertexColor=1
    fTangentSpaceVtxSplit=0.000000e+000
    psVcOptUVW[0].eType=1
    psVcOptUVW[0].nEnable=131
    psVcOptUVW[1].eType=1
    psVcOptUVW[1].nEnable=128
    psVcOptUVW[2].eType=1
    psVcOptUVW[2].nEnable=128
    psVcOptUVW[3].eType=1
    psVcOptUVW[3].nEnable=128
    psVcOptUVW[4].eType=1
    psVcOptUVW[4].nEnable=128
    psVcOptUVW[5].eType=1
    psVcOptUVW[5].nEnable=128
    psVcOptUVW[6].eType=1
    psVcOptUVW[6].nEnable=128
    psVcOptUVW[7].eType=1
    psVcOptUVW[7].nEnable=128
    staticFrame=0
    sVcOptBin.eType=1
    sVcOptBin.nEnable=135
    sVcOptBoneInd.eType=10
    sVcOptBoneInd.nEnable=1
    sVcOptBoneWt.eType=1
    sVcOptBoneWt.nEnable=1
    sVcOptCol.eType=5
    sVcOptCol.nEnable=15
    sVcOptNor.eType=1
    sVcOptNor.nEnable=135
    sVcOptPos.eType=1
    sVcOptPos.nEnable=135
    sVcOptTan.eType=1
    sVcOptTan.nEnable=135

    Exporting the exact same file with the only difference being:

    Code:
    bFlipTextureV=1

    Results in a POD that cannot be loaded. 

    Note: The stride of my vertex data is 25 bytes, since there is not actually any vertex coloring in the Maya file, hence the vertex color data is omitted.

    #33298

    Scott
    Moderator
    jordo wrote:
    Okay, aside from spurious issues with the exporting of node data, I’ve run into a very consistent issue with the bFlipTextureV option in the Maya exporter.  If it is not selected, the model exports fine – if it is selected, the interleaved vertex data buffer is two bytes too short in the POD file, causing file load to fail after the interleaved data chunk is read.  If I push the file read cursor (m_BytesReadCount) back two bytes after reading the bad interleaved vertex data, the rest of the file loads fine (though the vertex data renders garbage).

     

    Hi,

     

    I haven’t been able to reproduce this with the Maya scenes I’ve tried. Would it be possible for you to send your scene and .pod files to devtech@imgtec.com. Also, which platform are you seeing this on and with which SDK? Does PVRShaman fail to load the .pod file?

     

    Thanks,

     

    Scott
    #33299

    jordo
    Member

    Email sent with example POD files.  From my email (posting here for further reference):



    It may be important here that we have the vertex color options selected in the
    exporter, but the model itself has no vertex coloring on it, and the exported
    POD does not contain any vertex color data.  The bFlipTextureV setting appears
    to work correctly for models that we export that do have vertex coloring in the
    Maya scene.

     

    These PODs were both exported from
    Maya 8.5 on Windows, using the latest PVRGeoPOD
    plugin.

     

    Neither one of these files will open
    in PVRShaman for me – both give the error “File does not exist or may be
    corrupt”.  The files were originally exported with the extension “.podca”, but I
    have renamed them to “.pod” here.

     

    I’m using the OpenGL ES1.1 Linux SDK
    on an iPhone device, however I have verified that the data being read on the
    device exactly matches the data in the POD file – and the same erroneous
    interleaved vertex data section can be observed in the file, regardless of
    SDK.

    jordo2009-08-06 18:09:50

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