It's unused, and it's a bad idea - it's important for authoring tools
and for performance that vertex formats are well-defined instead of
dynamically created.
When rendering the shadow map offscreen using framebuffer objects, it's
not necessary to create a color renderbuffer. Currently
FramebufferParams only lets you choose between a renderbuffer and a
texture for both color and depth attachments. This changes that, and now
you can ask for a texture, a renderbuffer, or nothing.
This improves performance. On my computer, with an 8192x8192 shadow map,
this improves overall frame time by 8.0%.
Shadow shimmering is a visual artefact where the outlines of shadow
mapped objects don't stay stable when the camera is moved or rotated.
The reason is that as the shadow map's origin moves, the objects
rendered to the shadow map have temporal aliasing around their edges.
The solution is to only move the shadow map in texel-sized increments.
Because the shadow map's projection is orthographic, moving the shadow
map origin in texel increments ensures that objects that aren't moving
don't show any temporal aliasing, as the position of the samples of the
object in worldspace stay the same.
If CONFIG_QUALITY_SHADOWS is defined (which it always is) then the
fragment shader code that samples the shadow map will take five samples
in a cross shape around the point to be sampled, to apply antialiasing.
Currently, the offset of these samples is hardcoded to 0.00025× the
shadow map resolution. This is very inconsistent: if the shadow map
resolution is 128×128, then these samples are 0.032 texels apart, which
is a waste of four texture samples, and essentially means that no
antialiasing is applied. If the shadow map resolution is 8192×8192, then
these samples are 2.048 texels apart, which causes visual artefacts
around shadow edges, instead of giving smoother shadows.
The correct thing to do is to always sample exactly one texel away from
the original position. This is easy in GLSL 3.30, as it includes a
textureOffset function which offsets a texture fetch by an exact number
of texels. This is faster than manually calculating an offset ourselves,
it fixes visual artefacts at high resolutions, and it properly applies
antialiasing at low resolutions.
This significantly speeds up text rendering. On my computer, looking at
the program editor with a full screen of text, this commit takes the
framerate from under 30 to 60 (hitting vsync).
Performance could be further improved in the gl33 renderer by using
instancing or glPrimitiveRestartIndex instead of glMultiDrawArrays, but
that would be a more invasive change.
All of the interface rendering could use a unified quad batching system,
instead of it being limited to CText, but that would require some
refactoring in CText as it currently draws using a different coordinate
space to the rest of the interface.
Fixes#1104.
Currently the engine can draw debug spheres to show crash sphere
positions. This extends this to draw arbitrary spheres and cuboids,
transformed arbitrarily. With these in place it's now very quick and
easy to create a debug visualisation - for example, it's a one-line code
change to render the bounding box or sphere of every EngineObject.
This commit improves rendering performance by doing a better job of
checking whether an object is visible via its bounding sphere or not.
The engine maintains a bounding box for each EngineBaseObject that's
exactly large enough to fit every vertex. From this, it computes a
bounding sphere, and only draws objects if the sphere is within the view
frustum. Previously, the bounding sphere was always centered on the
EngineBaseObject's origin, even for models where the bounding box center
is significantly offset from the origin. Now, the bounding sphere is
always the tightest sphere which fits the bounding box.
krzys-h