Projection

This is the design dilemma for Viewport class. Space holds the camera transform matrix and lighting vector, 3D objects hold the object data, and virtually knows best how to draw itself.

The first approach is to encapsulate the drawing capacity in each object class, and associate a Space reference. The object class calls dojo.gfx.Sapce.applyCameraTransform to project itself into 2D space, renders the surface using dojo.gfx.Viewport.renderLighting. This approach would not work if we take the z-order and shadow cast from other objects into account.

The second approach is to offload the rendering to Viewport. The Viewport would iterate all 3D objects and only render what are in our horizon and compute the shadow cast from other objects. The main obstacle for this approach is how Viewport knows to render the object:

Abstract 3D objects to fundamental objects like surface, line

The object submits a set of surfaces, lines to Viewport, then let Surface do all the work. Though any surface can be approxmated by polygons or NURB surface theoretically, it is really overkill for simple object like cylinder, cone; and quite computation-extensive.

Object exposes callback functions for Viewport

Object class generally has a better understanding the object data.

dojox.gfx3d.Object exposes the following callback functions for Sapce to render itself:

dojox.gfx3d.Object.getShadows(lightings)

Based on the Viewport's lighting vectors, the shadow vector cast from the object itself.

dojox.gfx3d.Object.render(camera, lightings, shadows)

Based on Viewport's camera transform matrix, the object is projected to 2D surface, using lighting vector, global shadow vectors to render the surface.

A preliminary approach ignores the shadow, so only the lighting and z-order are considered.