[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ] [ Search: ]

C.5.9 Rendering and Drawing Changes

iGraphics2D Alpha Color Support

‘iGraphics2D’ now supports an alpha channel. iGraphics2D::FindRGB() accepts an optional alpha value (0 being completely transparent, and 255 being fully opaque) which defaults to 255. All canvases will then blend the pixels appropriately if the color depth is 15 bpp or higher. Furthermore, as iGraphics2D::Write() also handles alpha in both foreground and background colors, it is recommended for transparent backgrounds, instead of using ‘-1’ as the color value, to obtain a color value from FindRGB() that has the same R, G, B components as the foreground color, but an alpha component of 0.

Render Buffer Changes

The ‘iRenderBuffer’ interface was made renderer-independant. Consequently, creation was moved out of ‘iGraphics3D’ and into ‘csRenderBuffer’ in the ‘csgfx’ module (see ‘csgfx/renderbuffer.h’). The semantics of the parameters have changed too: notably, instead of specifying the byte size of a buffer, the element count is specified. The same change has been made to CopyToBuffer() (which has been renamed to CopyInto() to enforce human correction of the arguments).

More serious changes involve the publication of render buffers by renderers. Previously meshes provided render buffers via name, and these were mapped using name <-> OpenGL name mapping. But most meshes only provided a few standard-named buffers (such as, ‘vertices’, ‘texcoords’, etc.), and the mapping itself took some time (5%+ per frame). This has been reworked.

Now, meshes can provide a set of 16 buffers in a fixed structure. Meshes can provide ‘index’, ‘position’ (vertices), ‘normal’, ‘color’, ‘color_lighting’ (pre-lit colors), ‘texcoord0’, ‘texcoord1’, ‘texcoord2’, ‘texcoord3’, ‘texcoord_lightmap’, ‘generic0’, ‘generic1’, ‘generic2’, ‘generic3’, ‘tangent’ and ‘binormal’ buffers. At the very least, meshes should provide ‘index’, ‘position’, and if possible ‘texcoordn. The old system with custom named buffers is also supported.

Both kinds of buffers can be mapped, and the destinations for both kinds of buffers are the same (listed here): ‘position’, ‘normal’, ‘color’, ‘primary color’ (alias for ‘color’), ‘secondary color’, ‘texture coordinate n’ (where 0 <= n < texture units; ‘texture coordinate’ is alias for n = 0), and ‘attribute n’ (where 0 <= n < 16). Note that you can not map buffers of different kinds (the ‘normal’ and the custom buffers) to same destination; the result is undefined).

The normal buffers are named ‘position’, ‘normal’, ‘color’, ‘primary color’, ‘lit color’, ‘texture coordinate n’ (where 0 <= n < 3), ‘texture coordinate lightmap’, ‘generic n’ (where 0 <= n < 3), ‘binormal’, and ‘tangent’. These appear in the ‘source="..."’ tag within the XML shader description.

Mapping of custom buffers is accomplished as so:

 
<buffer
  customsource="custombuffername"
  destination="texture coordinate 1"
/>

And, mapping of a normal buffer is done this way:

 
<buffer
  source="tangent"
  destination="texture coordinate 2"
/>

As a convenience, three buffers are mapped automatically by default (as long as the mesh provides them). They are:

Render Priority System

It is no longer possible to define render priorities in a map file. You can now only redefine render priorities from the engine API. See section Render Priorities and Objects in Sectors.

Cg Matrix Bindings

Previously, the semantics of a Cg vertex program matrix parameter were determined through the variable name; e.g. a name of ‘ModelViewProj’ bound the combined model view and projection matrix to the variable. This is still supported but deprecated. Crystal Space now requires Cg 1.3 which allows the matrix semantics specification in a way similar to other semantics specification. For example:

 
uniform float4x4 ModelViewProj

Becomes:

 
uniform float4x4 ModelViewProj : state.matrix.mvp

Check the ‘data/shaders/’ directory for further examples. For more detailed information, consult the Cg and ‘ARB_vertex_program’ documentations.

Transform Split

To allow more control over how geometry is transformed when using shaders the ‘csRenderMesh::object2camera’ has been split into two transforms: ‘object2world’ and ‘world2camera’. The ‘object2world’ transform is sent via a shader variable, while ‘world2camera’ is specified via iGraphics3D::SetWorldToCamera() (but it is also available as a shader variable to shader programs).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html 1.76.