Jogl3-backend making of

6. August 2012: Preparation of the scene graph visitor

First, the code for copying the scene graph and visiting all leaves of it, has to be written. jReality already had a scene graph proxy class, that could copy the whole jreality scene graph and unwrap it.

I explain: In the scene graph you can attach a single Geometry object at different branches if you wish the same geometry to be drawn with different Transformations or Appearances. However in the backend you need to draw this Geometry once for every time it appears in the scene graph. So we have to create one object (will call it JOGLGeometryInstance) for every leaf containing Geometry and collect all the Appearances and Transformations on the path from the scene root to the Geometry. This accumulated Appearance is saved in the JOGLGeometryInstance, the accumulated Transformations together with the camera position and properties in a class called JOGLRenderState.

We also need to collect all lights, but let's do this later. First we want to see results.

So for the first testing of our scene graph unwrapper we only drew the points in red. Then you could already move the objects around, as you see all their vertices and the ToolSystem works independently.

Then I started implementing point Sprites to make spheres out of points and let them appear round. The point sprite code draws a rectangle (this is called a sprite) for every point and then calculates the depth value for every pixel in this rectangle, pixels outside the circle are discarded. Then you get the impression of a sphere. I call this displacement mapped point sprites.

Unluckily there is no screen shot passed on from this time.

In the screenshot below you can see polygon rendering of all the Geometries in the scene graph. For testing it uses a constant light direction and the diffuseColor(?) from the scene graph. You can also see the point sprites, that I have done earlier. The grey rectangle in the foreground actually is a Geometry inside the scene graph attached to the camera. It has the invisible property and is used to define the viewport.

polygon rendering with small point sprites

23. August 2012: Texture

Next step is to get Texture loading and rendering working. Texturing gives really satisfying results and is rather easy to implement: Convert Image object to raw data, load raw data to GPU, set some properties like data format, width, height, mipmapping, copy teture coordinates to a vertex buffer object, load the vertex buffer object, and add these lines to your shader:

vertex shader:

in vec4 vertex_coordinates; out vec3 texCoord; void main(void){ texCoord = vertex_texturecoordinates; }

fragment shader:

uniform sampler2D front; in vec3 texCoord; void main(void){ glFragColor = texture( image, texCoord.st); }

the Matheon bear with texture

27. August 2012: Skybox

Rendering a skybox is just as easy as rendering textures. simply turn off depth testing and render a cube with a texture for each face. The textures can be found in the root Appearance of the SceneGraph. In the screenshot below you see on top the new backend with skybox, and behind the old backend which can only be distinguished by its reflection mapping and tubing of the lines.

new backend with skybox on top, old backend on the below

30. November 2012: Let there be light

Now we really collect all the lights in the scene, global and local. Then I do something that I never heard of before. I write all the light properties - direction, color, position, cone angle - to a 1D-texture. This way the number of lights in the scene is only limited by maximum texture dimension (I think we get a maximum of about 100 lights per scene this way). Then follows some really unreadable fragment shader code, that ready all these light attributes from the big 1D texture and calculates for every fragment the light influx. Result is the following screenshot, which shows the difference between old (on top) and new (on the bottom) backend.

lighting seems to work correctly

12. January 2013: Lighting works wonderfully

Now we are really done with our lighting code. The first main differency and improvement to the old backend is that we process not only 6, but up to 100 lights. (This can even easily be pushed to 1600000 lights by using the second texture dimension) The second improvement becomes clear when looking at the next two screenshots. The first one shows the new backend, which uses the phong shading model, i.e. every pixel gets its own normal and position when calculating the light influx. The second screenshot shows the old backend which only calculates the light influx for every vertex of the Geometry and then interpolates between the vertices to get approximate light influx values for all pixels. Especially the specular light contribution (white spot in the middle of the green cone) and the spot light cone edges profit from the phong shading.