blackberry/GamePlay — pull request #571 by WolfgangD (2012-11-05 15:39:41+00:00)
Title: Next

First implementation of automatic material file generation from collada files in gameplay-encoder.

Material values set are: (dae-name -> gameplay-name (default-value))
ambient -> u_ambientColor (0.2, 0.2, 0.2, 1.0)
diffuse -> u_diffuseColor (0.8, 0.8, 0.8, 1.0)
specular -> u_lightColor (0.8, 0.8, 0.8, 1.0)
shininess -> u_specularExponent (0.0)
transparency -> u_modulateAlpha (1.0)

If diffuse has a texture, then the sampler u_diffuseTexture will be set and the texture-shader will be set. If diffuse is a color then the color-shader will be set. A texture is only supported within the diffuse-tag so far (I guess that it's like that in the gameplay-implementation as well. In Collada it is also possible to set a texture for the ambient, emission,...).

Different lighting-shaders are currently unused because the 'define' - variable is not set. So I have to implement the lighting.

At the moment I set all uniform-variables even though they are not needed. This implicates a warning when the shader is being used in the program. This has to be fixed.

mipmap is always set to false currently.

I added a new flag to the Encoder: with -m it is possible to 'enable' the dae encoder
The output file will be stored at the same place as the .gpb file with the same name but the extension .material
Since gameplay doesn't support jpg, there will be a warning when jpg's are used in the dae-file and a 'broken' material-file will be stored (have to fix that). Currently I don't check if textures have a size to the power of 2.

Textures automatically get the path res/texture.ext (e.g. res/stone.png)

Open questions:
should we auto-generate a png if we have jpg's?
should we copy all textures to the outputpath/res ?
should we auto-generate the size of the textures that they have a size to the power of 2? (we have to reset the UV's in this case)