|
This document will explain the source code folders and files that
make up Torque 3D's rendering system. If you have not done so already,
make sure you read the following docs first:
You can find the core GFX files in engine/gfx. Some of the
source files in this system are meant to be sub-classed based on
platform. There are currently 4 main gfxDevice classes:
- GFXDevice
- GFXD3D9Device (inside the D3D9 directory)
- GFXGLDevice (inside the gl directory)
- GFXNullDevice (inside the Null directory)
As you can see, each platform has its own GFXDevice. The same
goes for other platform dependent files: gfxShader, gfxCubemap,
gfxVertexBuffer, and so on. Some of the other source files are
stand-alone. For instance, gfxStructs.h contains classes/structs and
functions used by all platforms. This usually involves generic
information, such as GFXLightInfo containing light type, position, etc.
Because Torque 3D supports cross-platform compatibility, it is
important to keep the GFX layers separate. The D3D folder contains only
two files: screenshotD3D.h and screenshotD3D.cpp. Just as the name
implies, these two files are used in capturing screens while running a
game. (Currently D3D9 only).
You will see the major platform specific classes represented here, such
as the GFXdevice, TextureManager, VertexBuffer, etc. The functionality
remains the same, but the application and execution are specific to the
API.
Much like the D3D sections, the gl folder and its files contain
rendering functionality specifically meant to run on a Mac. Once again,
the major systems are integrated into the OpenGL layer (StateBlock,
GFXDevice, PrimitiveBuffer, etc).
Within the gl directory is another folder: ggl. The source code in this
section make up the Torque OpenGL Library. In the code itself, you will
find the various OpenGL configurations, bindings, and extension
definitions.
The Null folder contains gfxNullDevice.h and gfxNullDevice.cpp. This
device layer is used primarily for dedicated servers, which typically
do not require any rendering. Dedicated servers usually just process
simulation events and relays that information to the clients. There is
no real reason to waste processing power and memory rendering objects
that no one will see.
The 3 systems found in this folder are: CubeMapData, gfxStateBlockData, and debugDraw.
debugDraw does exactly what it sounds like. Once you enable
debugDraw, you can pass it data (Point3Fs and ColorF) which will then
render points, cubes, and other polygons. For instance, if you pass in
the points that make up a Player's bounding box, you will see a box
surrounding that player when running the game.
CubemapData is a class exposed to TorqueScript, making the class
a ConsoleObject. A Cubemap is a texture that represents a rendering of
the surrounding environment. The easiest example to explain would be a
Sky cubemap rendered onto a body of water. The cubemap would consist of
various sky images taken from different angles.
GFXStateBlockData is extremely important. Since GFXStateBlocks
are meant to be created in script, a ConsoleObject that can hold
StateBlock description was needed. GFXStateBlockData is that
ConsoleObject. This covered in more detail in Stateblocks.
You can ignore this folder, as it was used during internal testing.
Another section of engine code that is considered an important part
of GFX can be found under renderInstance (engine/renderInstance). The
files found in this directory make up the various render managers. We
will cover these in the next GFX document. For now, just remember these
classes are responsible for controlling the rendering flow of your
game.
This guide is another high level walk through of a Torque 3D system.
Even though we covered some major files and concepts, you should take
the time to read through the code comments left by the engine
developers. Some of this will make more since as you read through the
remaining GFX documents.
|