Imagination PowerVR SDK Blog

Blender PVRGeoPOD issues



I've run into a couple of issues trying to export simple scenes from Blender 2.62 (OS X) with the POD exporter.

All of these tests were on an empty scene with a simple plane added (Add->Mesh->Plane)

1) World rotation:

The plane is on the x-y plane. Vertices are exported correctly having looked at them in shaman ("OpenGL" and "Model Space" selected). However the world matrix (from calling GetWorldMatrix) comes up as this:

1 0 0 0

0 0 1 0

0 -1 0 0

0 0 0 1

I've looked at the exporter script, and obj.matrix_local seems to be where the script gets the transformation from. However when I print that out in Blender's python console it is the identity matrix in this case though, so it looks like the rotation is being added by the PVR library?

2) Vertex colors:

Specifying ARGB (the default) seems to in fact give RGBA, and selecting RGBA seems to give ARGB in the CVPRTModelPOD after calling ReadFromFile. However the type in the POD file is set to what was selected in the exporter. Shaman's Object Data window shows something different again; the vertex colours are listed in a 4x4 matrix with the column order as below.

Exporter Selection  -> CPODData.eType  ->  CPODData component order -> Shaman component order 

float -> EPODDataFloat -> BGRA -> BGRA




I can work around these issues in my rendering code, but they seem like bugs in the exporter. We also use Maya - I haven't checked how consistent the output is from there, but I'd like to avoid having to special-case workarounds for the Blender exporter.

Cheers for any help, and thanks for all the POD tools in general, they're really great!



Has anyone at imgtec looked at this?

Perhaps I should say that the rendering code we use might be based on an older version of the code from the SDK, as we’ve got some custom modifications on top. The Shaman oddities are using the stock tools though.


Sorry for not getting back to you sooner.
I took a brief look at the exporter and it does appear to not be exporting the vertex colours in the order suggested by the EPODData* value/PVRGeoPOD GUI. Cheers for bringing this to our attention.I was hoping to investigate the issue further last/this week but unfortunately didn't get a chance. If you would like,once this has been fixed we can supply you with an updated version.
As for the extra transformation, this is there as Blender's co-ordinate system doesn't match OpenGls.