Rendering pipeline modernization.

[CacoFFF]

Rendering pipeline design notes and ideas.

The rendering system in UE1 is on that is particularly complex compared to other games and engines of the time given it's capabilities.

We will be discussing here how to design a more modern and GPU friendly approach to achieving proper rendering, and establishing bases for improvements.

As a part of the discussion, we will be:

• Listing some of the issues with the existing pipeline.
• Brainstorming a better approach to these.
• Use these ideas to come up with a bigger picture of what the pipeline will look like.

[CacoFFF]

Goals:

• Reduce amount of draw calls in the rendering API by considering renderer states and constraints.
• Give the opportunity to the render device to manage and utilize complete and untransformed geometry storage.
• Take advantage of GPU processing power by move projection, lighting and fog calculations to it.
• Create a design simple enough that allows easy implementation of improved visuals and effects.

[CacoFFF]

The unreal mesh formats do not have a proper common interface to query material and material groups, all Unreal meshes should have a way to easily identify the textures/materials and the effects applied to them for proper reordering and batching.

[CacoFFF]

A lot of the rendering effects, such as lighting and texture panning may end up being reimplemented in shaders, for this reason these effects need to be moved to the headers/SDK so that they can also be used as documentation for renderer developers.

[CacoFFF]

The game uses something called Moving Brush Tracker to temporarily merge dynamic geometry from movers into the level's geometry, this allows various BSP tree traversing routines to draw these surfaces, as well as use them to block some visibility checks.

While getting rid of the Moving Brush Tracker for good won't be feasible for a while, at least not depending on it for rendering is a major milestone given that allows decoupling of dynamic BSP from static BSP, giving opportunities to optimize rendering for both separately.

Another advantage of being able to render movers, or brushes in general as if they were simple models, is being able to preview them in Unreal Editor.

[SeriousBuggie]

Wanna note this BSP models for brushes ugly as hell. AFAIK they build in very simple way, similar to dirty build only geometry button in UnrealEd.

On complicated brushes this lead to weird glitches like:

• invisible walls,
• invisible colliding stuff,
• invisible walls which allow pass some sort actors only (e. g. hit scan not pass, players pass, projectiles pass - any set there possible),
• collision model not match visible model.
• big object collide with invisible wall, small - no.
• and so on.

[SeriousBuggie]

Also Moving Brush Tracker when inject brushes models, can hit vertex limit which lead to immediately crash of game, even if there all be fine before.

[CacoFFF]

Yes, we found that fixing the Moving Brush Tracker is not worth the effort, and that slowly offsetting it and discarding it would be more benefitial in the future.

[CacoFFF]

Currently visible actors and lights are both being picked from the actor list, and filtered through the viewport's point of view against the BSP tree, every single time a Frame is queued for rendering.
By Frame I mean, a deformation in space that forces the pipeline to issue another set of rendering commands, such as a mirror or a skybox effect.
This can cause severe performance issues by running over long actor lists and applying dynamic lights to surfaces, actors multiple times.

Ideally, we want to first obtain all possible renderable frames (and their respective frustums) as well as specific renderer structures (shadow mapping 'frames') and then either:

• Run filtering of dynamics considering all points of view so that the render device can obtain all the necessary information before drawing anything on screen.
• Allow the renderer itself to run occlusion checks on hardware when rendering each Frame.

[CacoFFF]

Unreal levels come with shadowmaps baked into surfaces where lighting is applied to them, this then allows the game to calculate proper lightmaps based on these.
While static lighting is calculated during the first time a lightmap is rendered, dynamic lights need to be calculated on every frame (and by extension from above comment, Frame), triggering a 'upload' to the GPU memory.

There are two ways a renderer can tackle this, by:

• Generating and merging dynamic lightmaps in an extra render pass prior to rendering static and dynamic BSP.
• Calculating dynamic lights directly on the fragment shader and merging them with the static lightmap color.

In either case, it's needed for the renderer have the necessary information regarding dynamic lights and surfaces they're being applied on to proceed.
This means that the render interface must properly enumerate and sort these pairs (light effect > light actor > surfaces) and pass this information to the render device.

This particular issue depends on:

• All qualifying dynamics (in particular dynamic lights) being listed prior to rendering: Rendering pipeline modernization. #937 (comment)
• Light effect specification being available for the render device to implement: Rendering pipeline modernization. #937 (comment)
• And for applying lights on mover geometry: Rendering pipeline modernization. #937 (comment)

[CacoFFF]

When rendering geometry, the pipeline can properly sort objects based on transparency and other characteristics (Textures and Polyflags for example) to avoid switching rendering states which seriously speeds up the render device, one problem with this is how actors and movers (as well as the level itself) can contain multiple sets of characteristics and how the dynamic filtering system (as described on #937 (comment)) only accounts for the entire actor as a whole, forcing state changes and stalls on the render device if said actor has multiple parts with different polyflags on it.

To deal with this, it's necessary to easily recognize these parts in the mesh (and also brush?) format as mentioned in #937 (comment), and split these into different 'material objects' if needed, this way these sub-sections of an actor can be assigned to separate rendering passes ensuring proper application of transparency effects.

[CacoFFF]

Some renderers may apply certain optimizations when drawing solids depending on the draw order, while with renderers that don't make use of Depth/Z it was necessary to sort geometry back to front, with renderers that can discard geometry or pixels it's best to sort front to back.

To avoid unnecessary one-size fits all approaches, the render device interface should be expanded so that they can optionally sort drawable objects as these renderers see fit.