The Rendering Engine

Initialising the Renderer

BrZbBegin()

BrZsBegin()

Pre-Rendering Pre-Processing

Hidden Surface Removal Schemes

BrZbDepthToScreenZ()

BrZbScreenZToDepth()

BrZsDepthToScreenZ()

BrZsScreenZToDepth()

Rendering Functions

BrZbSceneRender()

BrZsSceneRender()

BrZbSceneRenderBegin()

BrZsSceneRenderBegin()

BrZbSceneRenderAdd()

BrZsSceneRenderAdd()

BrZbSceneRenderEnd()

BrZsSceneRenderEnd()

BrZbRenderBoundsCallbackSet()

BrZsRenderBoundsCallbackSet()

BrZsPrimitiveCallbackSet()

Terminating the Renderer

BrZbEnd()

BrZsEnd()

Scene Rendering

The Rendering Engine

Phase 1

• Traverse the actor hierarchy and produce a stream of models, materials, transforms, and rendering styles

Phase 2

• Discard back faces

• Produce a stream of lit 2D face elements (typically triangles or quads)

• Possibly perform binary space partitioning (for hidden surface removal)

Phase 3

• Possibly perform hidden surface removal (ordering, zbuffering, etc.)

• Render faces to destination image (pixel map)

Depending upon the platform, BRender will exploit dedicated hardware wherever possible to perform some of the phases.

In terms of how the process appears when using the BRender API, the following gives a simplified C skeleton of a possible application.

BrBegin(); /* The BRender library is Initialised */
...
/* The application is initialised */
...
BrZbBegin();/* The rendering engine is initialised */
...
/* Set up a scene in terms of an actor hierarchy */
...
/* Elements in the scene are pre-processed by being added to the registry (models, materials, textures, shade tables) */
...
do/* Main loop */
{do /* Perform rendering of the scene from each camera */
{ ...
/* Start supply of scene details to renderer */
BrZbSceneRenderBegin(world,camera,colour_buffer,depth_buffer);
	...
	for (...; ...; ...)/* Rendering one or more actor hierarchies */
		{ ...
		/* Specify each branch of world hierarchy to include in rendering */
			BrZbSceneRenderAdd(...);
			...
		}
		...
		/* End supply of scene details to renderer */
		BrZbSceneRenderEnd();
		...
	} while (...);
	...
	/* Update the scene */
	...
} while (...);
...
BrZbEnd();/* Close down the rendering engine */
...
BrEnd();/* Terminate the BRender library */

Initialising the Renderer

BrZbBegin()

BrZsBegin()

Non-Null pointer to an allocated block of memory to be used as a heap to hold rendered*2 primitives and referenced vertices generated during rendering.

br_uint_32 size

Size of primitive heap. To ensure that everything is rendered completely, this should be large enough for the renderer to store the temporary data structures used to hold details of each rendered primitive and the transformed vertices indexed by them. A primitive can be anything from a point to a triangle (possibly a quad). For the purposes of estimation you should allow 26 bytes for each primitive and 64 bytes for each unique vertex. The number of unique vertices can be calculated from the number of primitives, according to how vertices are shared by models' faces. At best there will be an average of one vertex per face primitive (a tetrahedron - four faces, four vertices), at worst there will be an average of three vertices per face primitive (a scene of independent triangles)*3.

Note that clipping is likely to increase the number of vertices.

If you estimate that there is an upper limit of about 1,000 faces (of front facing surfaces) in a rendering sequence with an average of 2.5 vertices per triangular face (including increases due to clipping) then the value of this member should be 1,000(26+2.564), i.e. 186,000 bytes, call it 200KB.

Pre-Rendering Pre-Processing

If an item is no longer involved in a scene, then it can be removed from the registry using a function such as BrTableRemove()284.

Functions to search the registry for a particular item or to enumerate over all items of a certain type can be found in the supplementary sections of structures br_model228, br_material151, and br_pixelmap272.

Hidden Surface Removal Schemes

The Z-Buffer

Note that as depth buffer values are treated by the rendering engine as unsigned words, before rendering the depth buffer should be filled to the maximum depth, i.e. 0xFFFFFFFF. The following example call will suffice whatever the word size of the depth buffer:

BrPixelmapFill(view->depth_buffer,0xFFFFFFFF);

The functions BrZbBegin()28, BrZbSceneRender()34, etc. are provided for applications requiring a Z-Buffer rendering engine.

The following functions are provided to convert between depths, screen and view co-ordinates.

BrZbScreenZToDepth()

A screen z value as obtained from functions such as BrOriginToScreenXYZO()252.

const br_camera* camera

A non-NULL pointer to the camera being used for rendering, i.e. relevant to the depth values used in the z buffer.

A 32 bit depth value suitable for writing to a z buffer pixel map.

The Z-Sort

The Z-Sort is a very fast, low quality scheme using relatively little memory (particularly for simple scenes). Before rendering, all primitives (faces or smaller elements, such as lines or points) are sorted according to the z value of one or more of their vertices. The primitives are then rendered farthest first.

Clipping of intersecting faces involves a severe performance hit and is only likely to be implemented on very capable platforms. Checking for cyclic overlaps reduces performance still further.

The particular method BRender uses to sort primitives is to use a bucket sort. This involves the use of one or more order tables. Each order table divides a stratum (depth range) of the observer's z-axis into a number of equal sub-strata (depths). The model geometry of each model actor (using a particular order table) will be converted into rendering primitives, and each primitive will be added to the bucket (a linked list) corresponding to the sub-strata appropriate to its z-values. It is called a bucket sort because the order table may be considered as an ordered row of buckets into which items are thrown (in any order) according to their value (one bucket per range of values). Thus the order in which primitives of the same sub-strata are drawn is undefined.

Each order table effectively defines a separate layer of the rendered image, like an acetate. One should thus take care if order tables' depth ranges overlap, to avoid far faces being drawn over near faces. This is only likely to be a problem for intersecting models in separate order tables. Order tables are drawn in order of sort_z (typically the nearest end of an order table).

The application is responsible for ensuring model actors are using appropriate order tables. The rendering process can then traverse the actor hierarchy, processing each model into primitives and inserting these into the appropriate order tables. Actors can be assigned to order tables specifically, or by inheritance - there is a default, single bucket order table (spanning the entire view volume) which will be inherited if no ancestral actor defines one. Each new order table that is encountered during this process is inserted into an ordered linked list of order tables. When complete, the list of order tables is traversed, with the primitives rendered from each bucket in turn (from back to front).

Performance is relatively independent of the number of buckets you have, given the use of a radix sort to determine into which bucket a primitive should be placed. Performance does decrease however, the more order tables you have. This is due to the overhead, as each new order table is encountered, required to insert the order table at the correct position in the linked list of order tables. This is only likely to be significant with a large number of order tables.

It is difficult to give guidelines, as approaches to determining an appropriate set of order tables depends so much on the type of scene (sometimes, even from frame to frame, as models rotate and intersect). Approaches can vary from having a single order table with a large number of buckets, to a single bucket order table for each model.

The functions BrZsBegin()28, BrZsSceneRender()34, etc. are provided for applications requiring a Z-Sort rendering engine.

The following functions provide means of converting between z sort depth values (as required by order tables and supplied to primitive call-back functions). Note that the z sort depths are actually in a different range from view z values, i.e. depths are in the range [hither_z,+yon_z] whereas view z values are in the range [hither_z,yon_z] (both ranges near to far).

BrZsScreenZToDepth()

A screen z value as obtained from functions such as BrOriginToScreenXYZO()252.

const br_camera* camera

A non-NULL pointer to the camera being used for rendering, i.e. relevant to the depth values used in primitives and order tables.

A depth value suitable for writing to an order table or comparing with values of z obtained from a z sort primitive call-back.

Other Schemes

Binary Space Partitioning

Voxels

Ray Tracing

Scan Line Rendering

Rendering Functions

Note that there are two key call-back functions that can get called during rendering. These are a custom model rendering call-back (see br_renderbounds_cbfn307) and a render bounds call-back (see br_model_custom_cbfn247). The custom model rendering call-back is specified within the br_model228 structure defined for a model actor and enables an application to make a model's rendering dependent upon information only available at the time it's processed by the renderer. For similar reasons, the render bounds call-back is called for every model that affects the output image, allowing the application to take note of information only available at the time the model's are processed by the renderer. The trivial use of the render bounds call-back is to keep track of modified rectangles of the output image. The render bounds call-back is specified before rendering commences, using Br[Zb|Zs]RenderBoundsCallbackSet()38|38.

There is also a special call-back, br_primitive_cbfn307, only used in the Z-Sort renderer. This allows customised insertion of primitives into order tables.

BrZbSceneRender()

A non-Null pointer to the pixel map to render the scene into, whose type is colour_type as supplied to BrZbBegin()28.

br_pixelmap * depth_buffer

A non-Null pointer to the pixel map to be used as a depth buffer whose type is depth_type as supplied to BrZbBegin()28. It must have the same width and height as the colour buffer. See BrPixelmapMatch()286.

BrZsSceneRender()

A non-Null pointer to the pixel map to render the scene into, whose type is colour_type as supplied to BrZsBegin()28.

BrZbSceneRenderBegin()

A non-Null pointer to the pixel map to render the scene into, whose type is colour_type as supplied to BrZbBegin()28.

br_pixelmap * depth_buffer

A non-Null pointer to the pixel map to be used as a depth buffer whose type is depth_type as supplied to BrZbBegin()28. It must have the same width and height as the colour buffer. See BrPixelmapMatch()286.

BrZsSceneRenderBegin()

A non-Null pointer to the pixel map to render the scene into, whose type is colour_type as supplied to BrZsBegin()28.

BrZbSceneRenderAdd()

A non-Null pointer to an actor hierarchy, which must be a descendant of the world hierarchy supplied to BrZbSceneRenderBegin()35.

BrZsSceneRenderAdd()

A non-Null pointer to an actor hierarchy, which must be a descendant of the world hierarchy supplied to BrZsSceneRenderBegin()35.

BrZbSceneRenderEnd()

BrZsSceneRenderEnd()

BrZbRenderBoundsCallbackSet()

Returns a pointer to the old call-back function.

BrZsRenderBoundsCallbackSet()

Returns a pointer to the old call-back function.

Exactly when the call-back function gets called is undefined except that it will be sometime between BrZsSceneRenderBegin()35 and BrZsSceneRenderEnd()37. It is also not necessarily associated with a particular point in the rendering process.

BrZsPrimitiveCallbackSet()

Returns a pointer to the old call-back function.

Terminating the Renderer

BrZbEnd()

BrZsEnd()