The below diagram shows how some of the main classes in the com.ardor3d.framework and com.ardor3d.input packages interact with each other in an example application that has two different scenes that are shown on three different canvases. This diagram closely corresponds to how the LwjglAwtExample example is laid out.

Guice and the other initialisation code wires up the object graph and then fires off the FrameHandler updates. These updates can either by done in a thread started by the initialisation code, or perhaps by a thread managed by AWT or SWT, if the application is embedded in a windowing toolkit.

Each frame, the FrameHandler calls the two Updater instances that update the state of each Scene, and then tells each of the three Canvases to render out their views of the scenes.

The Updaters typically handle input via the LogicalLayer, which in turn fetches the actual input data from a PhysicalLayer. The PhysicalLayer has canvas-specific wrappers for mouse and keyboard input that each check the current state of input for its canvas. That allows us to have mouse positions that are relative to the canvas as opposed to the whole screen, and it allows input to be directed to different canvases, so that you can change the viewport of one canvas without affecting the others. The wrappers are either event-based (for AWT and SWT) or poll the actual physical state of the devices (for LWJGL).

See also:

• ArchitecureNotesJan2009