(For more resources related to this topic, see here.)

Creating engaging scenes

There is no adopted style for a 3D website. No metaphor can best describe the process of designing the 3D web. Perhaps what we know the most is what does not work. Often, our initial concept is to model the real world. An early design that was used years ago involved a university that wanted to use its campus map to navigate through its website. One found oneself dragging the mouse repeatedly, as fast as one could, just to get to the other side of campus. A better design would've been a book shelf where everything was in front of you. To view the chemistry department, just grab the chemistry book, and click on the virtual pages to view the faculty, curriculum, and other department information. Also, if you needed to cross-reference this with the math department's upcoming schedule, you could just grab the math book.

Each attempt adds to our knowledge and gets us closer to something better. What we know is what most other applications of computer graphics learned—that reality might be a starting point, but we should not let it interfere with creativity. 3D for the sake of recreating the real world limits our innovative potential.

Following this starting point, strip out the parts bound by physics, such as support beams or poles that serve no purpose in a virtual world. Such items make the rendering slower by just existing. Once we break these bounds, the creative process takes over—perhaps a whimsical version, a parody, something dark and scary, or a world-emphasizing story. Characters in video games and animated movies take on stylized features. The characters are purposely unrealistic or exaggerated. One of the best animations to exhibit this is Chris Landreth's The Spine, Ryan (Academy Award for best-animated short film in 2004), and his earlier work in Psychological Driven Animation, where the characters break apart by the ravages of personal failure (https://www.nfb.ca/film/ryan).

This demonstration will describe some of the more difficult technical issues involved with lighting, normal maps, and the efficient sharing of 3D models. The following scene uses 3D models and textures maps from previous demonstrations but with techniques that are more complex.

Engage thrusters

This scene has two lampposts and three brick walls, yet we only read in the texture map and 3D mesh for one of each and then reuse the same models several times. This has the obvious advantage that we do not need to read in the same 3D models several times, thus saving download time and using less memory. A new function, copyObject(), was created that currently sits inside the main WebGL file, although it can be moved to mesh3dObject.js. In webGLStart(), after the original objects were created, we call copyObject(), passing along the original object with the unique name, location, rotation, and scale. In the following code, we copy the original streetLight0Object into a new streetLight1Object:

streetLight1Object = copyObject( streetLight0Object, "streetLight1", 
streetLight1Location, [1, 1, 1], [0, 0, 0] );

Inside copyObject(), we first create the new mesh and then set the unique name, location (translation), rotation, and scale:

function copyObject(original, name, translation, scale, rotation)
{
    meshObjectArray[ totalMeshObjects ] = new meshObject();
    newObject = meshObjectArray[ totalMeshObjects ];
    newObject.name = name;
    newObject.translation = translation;
    newObject.scale = scale;
    newObject.rotation = rotation;

The object to be copied is named original. We will not need to set up new buffers since the new 3D mesh can point to the same buffers as the original object:

newObject.vertexBuffer = original.vertexBuffer;
newObject.indexedFaceSetBuffer = original.indexedFaceSetBuffer;
newObject.normalsBuffer = original.normalsBuffer;
newObject.textureCoordBuffer = original.textureCoordBuffer;
newObject.boundingBoxBuffer = original.boundingBoxBuffer;
newObject.boundingBoxIndexBuffer = original.boundingBoxIndexBuffer;
newObject.vertices = original.vertices;
newObject.textureMap = original.textureMap;

We do need to create a new bounding box matrix since it is based on the new object's unique location, rotation, and scale. In addition, meshLoaded is set to false. At this stage, we cannot determine if the original mesh and texture map have been loaded since that is done in the background:

newObject.boundingBoxMatrix = mat4.create();
newObject.meshLoaded = false;
totalMeshObjects++;
return newObject;
}

There is just one more inclusion to inform us that the original 3D mesh and texture map(s) have been loaded inside drawScene():

streetLightCover1Object.meshLoaded = 
streetLightCover0Object.meshLoaded;
streetLightCover1Object.textureMap = 
streetLightCover0Object.textureMap;

This is set each time a frame is drawn, and thus, is redundant once the mesh and texture map have been loaded, but the additional code is a very small hit in performance. Similar steps are performed for the original brick wall and its two copies.

Most of the scene is programmed using fragment shaders. There are four lights: the two streetlights, the neon Products sign, and the moon, which sets and rises. The brick wall uses normal maps. However, it is more complex here; the use of spotlights and light attenuation, where the light fades over a distance. The faint moon light, however, does not fade over a distance.

Opening scene with four light sources: two streetlights, the Products neon sign, and the moon

This program has only three shaders: LightsTextureMap, used by the brick wall with a texture normal map; Lights, used for any object that is illuminated by one or more lights; and Illuminated, used by the light sources such as the moon, neon sign, and streetlight covers.

The simplest out of these fragment shaders is Illuminated. It consists of a texture map and the illuminated color, uLightColor. For many objects, the texture map would simply be a white placeholder. However, the moon uses a texture map, available for free from NASA that must be merged with its color:

vec4 fragmentColor = texture2D(uSampler, vec2(vTextureCoord.s, 
vTextureCoord.t));
gl_FragColor = vec4(fragmentColor.rgb * uLightColor, 1.0);

The light color also serves another purpose, as it will be passed on to the other two fragment shaders since each adds its own individual color: off-white for the streetlights, gray for the moon, and pink for the neon sign.

The next step is to use the shaderLights fragment shader. We begin by setting the ambient light, which is a dim light added to every pixel, usually about 0.1, so nothing is pitch black. Then, we make a call for each of our four light sources (two streetlights, the moon, and the neon sign) to the calculateLightContribution() function:

void main(void) {
    vec3 lightWeighting = vec3(uAmbientLight, uAmbientLight, 
uAmbientLight);
    lightWeighting += uStreetLightColor * calculateLightContribution
(uSpotLight0Loc, uSpotLightDir, false);
    lightWeighting += uStreetLightColor * calculateLightContribution
(uSpotLight1Loc, uSpotLightDir, false);
    lightWeighting += uMoonLightColor * 
        calculateLightContribution
(uMoonLightPos,
    vec3(0.0, 0.0, 0.0), true);
    lightWeighting += uProductTextColor * calculateLightContribution
(uProductTextLoc, vec3(0.0, 0.0, 0.0), true);

All four calls to calculateLightContribution() are multiplied by the light's color (white for the streetlights, gray for the moon, and pink for the neon sign). The parameters in the call to calculateLightContribution(vec3, vec3, vec3, bool) are: location of the light, its direction, the pixel's normal, and the point light. This parameter is true for a point light that illuminates in all directions, or false if it is a spotlight that points in a specific direction. Since point lights such as the moon or neon sign have no direction, their direction parameter is not used. Therefore, their direction parameter is set to a default, vec3(0.0, 0.0, 0.0).

The vec3 lightWeighting value accumulates the red, green, and blue light colors at each pixel. However, these values cannot exceed the maximum of 1.0 for red, green, and blue. Colors greater than 1.0 are unpredictable based on the graphics card. So, the red, green, and blue light colors must be capped at 1.0:

if ( lightWeighting.r > 1.0 )  lightWeighting.r = 1.0;
if ( lightWeighting.g > 1.0 )  lightWeighting.g = 1.0;
if ( lightWeighting.b > 1.0 )  lightWeighting.b = 1.0;

Finally, we calculate the pixels based on the texture map. Only the street and streetlight posts use this shader, and neither have any tiling, but the multiplication by uTextureMapTiling was included in case there was tiling. The fragmentColor based on the texture map is multiplied by lightWeighting—the accumulation of our four light sources for the final color of each pixel:

vec4 fragmentColor = texture2D(uSampler, vec2(vTextureCoord.
s*uTextureMapTiling.s, vTextureCoord.t*uTextureMapTiling.t));
    gl_FragColor = vec4(fragmentColor.rgb * lightWeighting.rgb, 1.0);
}

In the calculateLightContribution() function, we begin by determining the angle between the light's direction and point's normal. The dot product is the cosine between the light's direction to the pixel and the pixel's normal, which is also known as Lambert's cosine law (http://en.wikipedia.org/wiki/Lambertian_reflectance):

vec3 distanceLightToPixel = vec3(vPosition.xyz - lightLoc);
vec3 vectorLightPosToPixel = normalize(distanceLightToPixel);
vec3 lightDirNormalized = normalize(lightDir);
float angleBetweenLightNormal = dot
( -vectorLightPosToPixel, vTransformedNormal );

A point light shines in all directions, but a spotlight has a direction and an expanding cone of light surrounding this direction. For a pixel to be lit by a spotlight, that pixel must be in this cone of light. This is the beam width area where the pixel receives the full amount of light, which fades out towards the cut-off angle that is the angle where there is no more light coming from this spotlight:

With texture maps removed, we reveal the value of the dot product between the pixel normal and direction of the light

if ( pointLight) {
    lightAmt = 1.0;
}
else { // spotlight
    float angleLightToPixel =
        dot( vectorLightPosToPixel, lightDirNormalized );

    // note, uStreetLightBeamWidth and uStreetLightCutOffAngle
    //  are the cosines of the angles, not actual angles
    if ( angleLightToPixel >= uStreetLightBeamWidth ) {
        lightAmt = 1.0;
    }
    if ( angleLightToPixel > uStreetLightCutOffAngle ) {
        lightAmt = 
(angleLightToPixel - uStreetLightCutOffAngle) / 
(uStreetLightBeamWidth - uStreetLightCutOffAngle);
    }
}

After determining the amount of light at that pixel, we calculate attenuation, which is the fall-off of light over a distance. Without attenuation, the light is constant. The moon has no light attenuation since it's dim already, but the other three lights fade out at the maximum distance. The float maxDist = 15.0; code snippet says that after 15 units, there is no more contribution from this light. If we are less than 15 units away from the light, reduce the amount of light proportionately. For example, a pixel 10 units away from the light source receives (15-10)/15 or 1/3 the amount of light:

attenuation = 1.0;
if ( uUseAttenuation ) {
    if ( length(distanceLightToPixel) < maxDist ) {
        attenuation = (maxDist - length(distanceLightToPixel))/
maxDist;
    }
    else attenuation = 0.0;
}

Finally, we multiply the values that make the light contribution and we are done:

lightAmt *= angleBetweenLightNormal * attenuation;
return lightAmt;

Next, we must account for the brick wall's normal map using the shaderLightsNormalMap-fs fragment shader. The normal is equal to rgb * 2 – 1. For example, rgb (1.0, 0.5, 0.0), which is orange, would become a normal (1.0, 0.0, -1.0). This normal is converted to a unit value or normalized to (0.707, 0, -0.707):

vec4 textureMapNormal = vec4
( (texture2D(uSamplerNormalMap, vec2(vTextureCoord.s*uTextureMapTiling.s, 
vTextureCoord.t*uTextureMapTiling.t)) * 2.0) - 1.0 );
vec3 pixelNormal = normalize(uNMatrix * 
normalize(textureMapNormal.rgb) );

A normal mapped brick (without red brick texture image) reveals how changing the pixel normal alters
the shading with various light sources

We call the same calculateLightContribution() function, but we now pass along pixelNormal calculated using the normal texture map:

calculateLightContribution(uSpotLight0Loc, uSpotLightDir, 
pixelNormal, false);

From here, much of the code is the same, except we use pixelNormal in the dot product to determine the angle between the normal and the light sources:

float angleLightToTextureMap = 
dot( -vectorLightPosToPixel, pixelNormal );

Now, angleLightToTextureMap replaces angleBetweenLightNormal because we are no longer using the vertex normal embedded in the 3D mesh's .obj file, but instead we use the pixel normal derived from the normal texture map file, brickNormalMap.png.

A normal mapped brick wall with various light sources

Objective complete – mini debriefing

This comprehensive demonstration combined multiple spot and point lights, shared 3D meshes instead of loading the same 3D meshes, and deployed normal texture maps for a real 3D brick wall appearance. The next step is to build upon this demonstration, inserting links to web pages found on a typical website. In this example, we just identified a location for Products using a neon sign to catch the users' attention. As a 3D website is built, we will need better ways to navigate this virtual space and this is covered in the following section.