Processing shader pipeline and built-in uniforms ?

capturevision

Hello,

Trying to tackle the steep learning curve of GLSL programming, I have read the following in the Processing doc about PShaders ( here).

Processing can send to the shader up to 8 different lights and their associated parameters. The full list of light uniforms that can be used to get this information in the shader are the following:

    uniform int  lightCount:             number of active lights
    uniform vec4 lightPosition[8]:    position of each light
    uniform vec3 lightNormal[8]:     direction of each light (only relevant for directional and spot lights)
    uniform vec3 lightAmbient[8]:   ambient component of light color
    uniform vec3 lightDiffuse[8]:     diffuse component of light color
    uniform vec3 lightSpecular[8]:   specular component of light color
    uniform vec3 lightFalloff[8]:      light falloff coefficients
    uniform vec2 lightSpot[8]:        light spot parameters (cosine of light spot angle and concentration)

I don't quite understand that.

Does this means that in every PShader, they are predefined uniforms, that are 'automatically' filled by Processing ?

And, if so, how to use them ? By declaring uniforms of the same name and type in the shader's code ?

As you can see, I'm perplex about this one.. :) so any explanation would be cool as I'm trying to port some shader ( goal :

• DOF
  • SSAO
  • Blinn Phong ...

Thanks.

codeanticode

Yes, in order to use the built-in lighting model in Processing (which basically mimics the fixed-function lighting model in OpenGL 1.x and 2.x) you have to declare uniforms with the same name and type as indicated in the PShader tutorial. Of course, if you want to define your own, more sophisticated, lighting model, you could by adding additional uniforms and setting them manually with PShader.set().

capturevision

@codeanticode, another question comes to my mind regarding lighting in Processing... The backbone renderer is OpenGL so.. I wanted to know what kind of equivalence was there between the processing's lights functions, and the OPENGL lights states and values..

Don't know if it's very clear.. In short and for example , when I say pointLight(..);, does the state of one of the eight OpenGL light changes ? Can I define one light in Processing and one in low-level OpenGL, and assume the lit object will take both lights into account ?

Thanks in advance, because this question was never really clear to me..

codeanticode

No, the lighting setup in Processing won't affect the state of the OpenGL lights in the fixed-function pipeline, they are completely independent. Even if you set the light states using OpenGL functions (glLightfv, etc), they will be ignored by Processing, as the P3D renderer bypasses the fixed-function pipeline with its own shaders.

capturevision

@codeanticode : So..

As I'm writing scenegraph framework for P5, if I have scene nodes that could be wheter P5 lights or OpenGL object & lights to render, is there a way to emulate the OpenGL lights parameters with P5 functions like pointLight,etc.. so I could create a generic Light class with two subclasses GLLight and P5Light, which, with appropriate parameters would give the same effect ?

To make it clearer.. if I say :

GLLight glLight = new GLLight();
// set OpenGL light params..
drawGLBox(10);

P5Light p5Light = new P5Light();
// set equivalent P5 light params...
box(10);

Will I be able to achieve the same appearance for the two boxes ? Is it possible ?

codeanticode

I think the best way to check what OpenGL parameters (in the fixed-function pipeline, since OpenGL 3+, OpenGL ES 2+ don't have built-in lighting) correspond to the Processing lighting functions would be to take a look at the source code of the OpenGL renderer in Processing 1.5.1, which was the latest version to use the fixed-function pipeline:

http://processing.googlecode.com/svn/tags/processing-1.5.1/java/libraries/opengl/src/processing/opengl/PGraphicsOpenGL.java

particularly the lighting functions (ambientLight, pointLight, etc). The renderer in Processing 2.0 was implemented to emulate the behavior of the 1.x API as closely as possible.

capturevision

@codeanticode,

Thanks a lot andres, will go and deep into P5 source code then.. Did it already and it's always full of (good