Nothing too exciting…

The rasterizer sample now loads all the major geometric primitives supported by the ray-tracing sample. The code changes required a handful of minor fixes here and there (as the same code was now being used in a different context, thus exposing some holes in the original code), but otherwise was fairly trivial.

The current code uses a simple smooth-shading, normal shader as lights and materials are not yet implemented in the sample.  Also, there’s some disparity in the camera setup, which I suspect is due to an error in the ray tracing camera setup code as the rasterizer camera setup is quite concise.

Geometry Only

Rasterizer sample showing the basic geometric primitives using a normal-based shader

Unused Uniform Variables in GLSL

In GLSL, if a uniform variable is declared but never used, then glGetUniformLocation() will return -1 (i.e. not found) for that variable.  This is good to know since (1) it saves some time if you’re doing incremental development and try testing your code when it’s setting the variable but not yet using its value, and (2) it means that in dynamically constructed shaders, it’s okay to include “extra” uniforms that may not be used – the shader compilation will remove the unused variable – and as long as the client code first checks for the presence of the uniform in the final program, some client-side setup can likewise be skipped.

Update: Phong Shading (Initial Imp.)

The code has been updated to read and use the lights from the scene files to produce simple Phong shading.  It is not a full implementation yet, but the basic GLSL parameter passing in place.

Unfortunately, the geometry below is all currently flat-shaded.  I need to add code to detect the flat versus smooth faces in the .blend file and update the geometry shader to respect that flag.

Update v2: IJW Code Reuse

Scripting: it just worked (again).  The Javascript implementation was essentially fully reusable from the ray tracing sample.  It took about 30 seconds of coding to get a scene that uses Javascript to create the scene to display with the new rasterization sample.

Sure there are still visual fidelity issues, but it’s great to see that the LxEngine code base is achieving its goal of being highly reusable without a confusing level of abstraction / generalization in the components themselves.

One more shader fragment for the tile procedural and an updated data file later:

Definition of “Complete”
According to the objectives of this sub-project, it’s fair to say the rasterized versus raytraced images results match sufficiently to call this sub-project done.  The remaining mismatches are primarily: (1) lack of shadows, (2) light position mismatch, (3) color tweaking.  Regarding lack of rasterized, soft, area light shadows, that is a sizable sub-project in itself; I’d like to pursue some other areas of the code before embarking on that one.  Regarding the light position mismatch, that’s a defect in the ray-tracer code: there’s no real learning value in attempting to compensate for that defect.  Regarding color tweaking, it’s close enough that I’m satisfied with the results.

There are plenty of areas for further improvement (there always are!) such as bitmap texture support, light shaders, nested uv spaces, shared variables, etc.  However, in the interest of exploring different areas of graphics code and based on the aims of this particular effort, I’m labeling this sub-project complete.

A complicated, nested procedural example
I’m fairly happy with the system’s capabilities.  For example, the foremost sphere in below image demonstrates a fairly complicated setup.  The diffuse channel contains a nested procedural: there is outer checker pattern which defines an inner checker pattern for one tile and a spot pattern for the other tiles.   Furthermore, the UV scaling on each level varies (the inner checker is 2×2, the inner spot is 3×4).  Lastly, the specular channel is completely independent as it defines a checker pattern of it’s own with a completely different UV mapping.

Here’s what the corresponding data file for the nested procedural sphere looks like (in the JSON scene format):

{
    description     : "Nested checker",
    type            : "plyfile",
    content         : "sphere.ply",
    style           :   {
        scale       : 0.00392156863,
        translate   : [ 0.0, -1.25, 0.5 ],
        exponent    : 128,
        material :       {
            phong : {
                diffuse  : {
                    checker : {
                        primary     : {
                            checker : {
                                uv : { spherical : { scale : [ 24,9 ]}},
                                primary : [ .4, 0, 1],
                                secondary : [ .2, .6, .3],
                            },
                        },
                        secondary   : {
                            spot : {
                                uv : { spherical : { scale : [ 36,24 ]}},
                                radius : .45,
                                primary : [ .5, 1, 1 ],
                                secondary : [ 0, 0, .1],
                            },
                        },
                    },
                },
                specular : {
                    checker : {
                        uv        : { spherical : { scale : [ 32,16 ]}},
                        primary   : [ 1, 1, 1],
                        secondary : [ 0, 0, 1],
                    },
                },
            }
        },
    }
}

Effect System Support
A quick look some of what the system currently supports:

• Pluggable shader fragments
  • Current Mappers cube, spherical, spherical-xy
  • Current Procedurals: checker, spot, tile
  • Current Base Shaders: phong
• Fully dynamic material shader generation
  • Shaders can be nested arbitrarily (to the limit of what the video card can support for a single shader)
  • Objects can share the same procedural and mapping for diffuse and specular, or have unique definitions.  The correct shader will be generated automatically.
  • If two materials have the same structure but different parameters, the system automatically reuses the existing shader and simply changes the uniform variables.
• Inherited Stylization in Scene Graph
  • Child nodes automatically inherit any parent attribute, unless the child overrides it.  Example: the three stacked cubes share a parent that defines the stylization; the children only define the transform and geometry.
  • Shader fragment definitions can automatically pick up these style parameters.  Example: the checker procedural automatically grabs the current primary and secondary colors defined by the parent if it is not given explicit values to use.

The LxEngine code now an improved GLSL shader pipeline for triangle rendering.  The engine has received a couple architectural improvements as well, but the focus was primarily on learning the basics of GLSL.

• Support for multiple lights with basic per-pixel Blinn-Phong shading
• The geometry shader can optionally generate per-face normals or pass through per-vertex normals
• Support for a simple fixed-color point shader
• Support for multi-stream OpenGL vertex buffer objects (VBOs)
• Removed all direct OpenGL references from the main Renderer class; all GL calls implemented behind an IDriver interface

Target result from the ray-tracer