Beta builds


Beta and experimental renderer builds. Not recommended for general use.


Unreal Tournament renderer
This renderer adds new experimental lighting for meshes. It supports per pixel mesh lighting. It supports partial HDR in some parts of the lighting path, along with some additional color scaling options.

Experimental renderer build for UT (version 4.36 only): utglr_2024_12_30_beta.zip (93 KB).

Steps required to enable new features
Need to add one line to the [OpenGLDrvPL.OpenGLRenderDevice] section of UnrealTournament.ini to enable the new features in this renderer:
EnablePatch=True

The UseFragmentProgram option must be enabled for the per pixel mesh lighting to work.

Binary patches applied, at runtime in RAM, not persistent
This experimental renderer applies two small binary patches as part of supporting the mesh lighting changes.

A branch instruction in higher level render code is modified to prevent 2D clipping, which also ends up destroying vertex normals that are needed later.

A vtable hook is installed for one function in GLightManager of class type FLightManagerBase. The hooked function does some mesh lighting related setup. The hook scans internal data structures to extract lighting information to be used for pixel lighting later, and changes flags on lights to be pixel lit so that existing lighting code ignores them.

Screenshots
I took a few screenshots to illustrate the changes, though to a large extent they are still best observed in motion. In the case of per pixel lighting only, the changes are minimal and difficult to notice in many fixed frames. This is intentional as want to generally keep the same lighting equations and apply lighting per pixel rather than per vertex. With small triangles, vertex lighting can approximate pixel lighting quite well. There is an intentional small math change in the derived lighting equation to save a fragment program instruction. Looking back at this, the approximation could probably be improved, though it is still expected to be difficult to notice in the final output. In the case of per pixel lighting with the HDR option, I think some things come out looking nice, but if allow for too much range, there can be problems with the meshes getting a bit too bright compared to other world geometry, as the lighting changes only work with meshes.

These screenshots are all 3 instances of the exact same frame in the order of [Orignal | PixelLighting | PixelLightingHDR]. Also note that due to post processing gamma correction and image format conversion, there are some very small artifacts, mostly a few off by one changes, to some parts of the image that would otherwise be identical.

The player's weapon may have a few big triangles due to being so close. The only major change for pixel lighting is seen across the flak shell. In motion, light may move much more smoothly across some parts of the weapon model. With HDR some things look a bit more shiny and metallic.



The player model looks essentially the same with pixel lighting, as it's a case of fairly small triangles. With HDR, there's the trade off of more range, but also getting a bit brighter compared to the world geometry with no lighting changes.



This is one of a few not so good flag frames with regards to lighting in the original where it is very jagged with vertex lighting. Pixel lighting smooths this out quite well. With the HDR settings used here, can see some of the color preservation effect, which can balance color preservation with intermediate range limiting. There is some very blue light around the blue flag, but everything else is bright enough that much of it saturates out to effectively white light in the original. The HDR frame illustrates a balance between more range for intermediate lightning calculations and color aware scaling back down to standard range for the final frame. In this frame, apart from trying to scale things back a bit to limit how much brighter the mesh can get, it also needs some scaling or limiting simply to prevent significant loss of detail from too much saturation in the final frame.



New settings
New lighting related settings in the Rendering\OpenGL PL Support section in the Advanced Options window.

PixelLighting - [True/False]
Per pixel lighting (meshes only).

PixelLightsMax - [Integer]
Maximum number of per pixel lights. Any remaining lights will be per vertex. Generally best to leave set to the maximum of 4.

PixelLightHDR - [True/False]
Don't clamp light color components to 1.0.

PixelLightHDRLimit - [Floating point]
Maximum value of light color components for the HDR path. Can use to prevent some things from becoming too bright. Default value is 2.0. Can be set in the range 1.0 - 4.0. When limiting, uses scaling that preserves color.

Deus Ex renderer, from 2009
Experimental renderer build for Deus Ex: dxglr_2009_12_20_beta.zip (131 KB).
Experimental renderer build for Deus Ex: dxglr_2009_8_12_beta.zip (131 KB).

This renderer adds new experimental lighting features for meshes. It contains a new mesh drawing function that hopefully draws everything almost exactly like the old one when the other new features are not activated. However, this is a beta build and testing all cases is difficult, so it may have some rendering bugs.

Need to add one line to the [OpenGLDrv.OpenGLRenderDevice] section of DeusEx.ini to enable the new features in this renderer:
EnablePatch=True

Then need to change one other setting to True (either in the file or through the Advanced Options window):
NewMeshPath=True

Also need to make sure that UseVertexProgram and UseFragmentProgram are enabled for the interesting parts of the new features to work. Either way, the new mesh path can still be used. This may be useful for helping to determine if certain parts of it contain any bugs. It may run a bit faster too.

Other new lighting related settings in the Rendering\OpenGL Support section in the Advanced Options window.

PixelLighting - [True/False]
Per pixel lighting (meshes only).

PixelLightsMax - [Integer]
Generally best to leave set to the maximum of 4.

PixelLightHDR - [True/False]
Don't clamp light color components to 1.0.

PixelLightHDRLimit - [Floating point]
Maximum value of light color components for the HDR path. Can use to prevent some things from becoming too bright. Default value is 2.0. Can be set in the range 1.0 - 4.0. When limiting, uses scaling that preserves color.

FragmentProgramEpsilon - [True/False]
Enable this to potentially avoid performance problems on GeForce 6 and 7 series cards (depends on the driver and if it might make particularly poor attempts at certain optimizations).


Copyright 2007 - 2009, 2024 Chris Dohnal