Imagination PowerVR SDK Blog

Problems with PVRShaman

pvrshaman

#1

Hi,

I'm playing with PVRShaman. On Windows (version 1.12, SDK version 2.10) when I use built-in effects files (e.g. the existing pfx file Colours.pfx or the Basic Lighting of the effect library), I get warnings such as:

warning: LIGHTPOSWORLD0 does not exist - using default value.   

warning: LIGHTDIRWORLD0 does not exist - using default value.   

I have another problem with #defines (which should be supported in GLSL as far as I know, at least the OpenGL ES 2.0 Programming Guide tells me that it is). In this example:

[HEADER]
[/HEADER]

[VERTEXSHADER]
    NAME VertShader
    [GLSL_CODE]
        #define GLSLPROGRAM
        #define GLSLEND            
       
        attribute vec4  Vertex;
        uniform mat4  MVPMatrix;
       
        GLSLPROGRAM
               
        void main()
        {
            gl_Position = MVPMatrix * Vertex;
           
        }
       
        GLSLEND
               
    [/GLSL_CODE]
[/VERTEXSHADER]

[FRAGMENTSHADER]
    NAME FragShader
    [GLSL_CODE]
        void main()
        {
            gl_FragColor = vec4(1.0, 1.0, 0.0, 1.0);
        }
    [/GLSL_CODE]
[/FRAGMENTSHADER]

[EFFECT]
    NAME GreenShader

    ATTRIBUTE    Vertex        POSITION
    UNIFORM        MVPMatrix        WORLDVIEWPROJECTION

    VERTEXSHADER VertShader
    FRAGMENTSHADER FragShader
[/EFFECT]

PVRShaman behaves strangely since it might or might not compile in the pfx editor (depending on previous changes) but it always fails when trying to "Rebuild Shaders".
Using

       #define GLSLPROGRAM uniform float dummy1;

       #define GLSLEND uniform float dummy2;

would solve the problem for me, but I still think that there is a bug in the way #defines with empty replace text are handled.

Best,

Martin   
 




Martin Kraus2012-04-24 10:02:12

#2

Hi Martin.


You’ll get those warnings about lights if the POD that you’re applying the effect on doesn’t contain that specific light type (i.e point light, directional light).





Also I can’t seem to reproduce the issue of expanding empty defines. Are you using the latest compilers provided with the 2.10 SDK?Arron2012-04-24 12:31:22


#3

Hi Arron,

OK, I just didn't understand the error message.

I'm using PVRShaman version 1.12 (PC Windows emulation SDK build 2.10@839132) and GLSL ES Compiler glslcompiler_sgx535.exe from from the 2.10 SDK.

I'm doing this:
- copying and pasting the code into a text file (.pfx) with notepad
- starting PVRShaman
- opening a built-in object, namely a sphere
- adding a material, selecting to assign it to the sphere, using the existing pfx file

The pfx editor reports success with the compiling of the vertex and fragment shader but nonetheless PVRShaman reports:

--- Loading Effects ---
PFX test2.pfx failed to compile.
Material 'NewMaterial1' using effect file 'test2.pfx' ... failed.

If I then choose "Rebuild Shaders" or "Apply Shaders", I still get the same error but the effects editor also fails to compile with these messages:
 
Compile failed.
ERROR: 0:12: 'Vertex' : undeclared identifier
ERROR: Unexpected end of source found
ERROR: gl_Position must be written by all paths through a vertex shader.
ERROR: main() function is missing.
ERROR: 4 compilation errors. No code generated.

If I change the pfx file in the editor (e.g. by adding a space), it compiles again. But if I then rebuild or apply the shader to the model, it fails again. Thus, I don't think it is a problem of the compiler but rather of PVRShaman.



Martin Kraus2012-04-24 13:59:19

#4

I just tried the same thing on MacOS X and couldn’t reproduce the problem.

However, another problem appeared: if I have TextEdit in RTF mode and copy&paste the code into it, then “make plain text” in TextEdit and save it (as UTF-8 or Western Latin 1), then PVRShaman cannot parse the spaces. I assume the compiler is unaware of some kind of white space that results from this procedure.




#5

Hi Martin.





Thanks - I’ll check this issue out.





I’m not too sure regarding the RTF > Plain text conversion. PVRShaman is only ‘ASCII’ aware, so any unicode characters that may result after such a conversion will not be correctly parsed.