Wednesday 21 March 2018

Direct X Raytracing: Further Unification

DirectX Raytracing (DXR)

DXR has recently been announced and many oldtime graphics programmers are obviously very interested in how this might change the future of GPU RealTime (RT) rendering. This article will be from the perspective of a Gen~3.5 render engineer and not someone currently writing production code against this new API.

API Summary

DXR presents new API for specifying 3D scene and initial rays that is passed on to the gpu hidden (device) layer to trace and have it report back results in the form of normal executing shader code [2]. For full details check out the DXR forum post [3].

Highlighted features:
  • "Independent" (to usercode) Rays defined by origin, direction, and min/max t.
  • Executed shaders for intersection hits (miss, nearest, any)
  • Executed shaders for ray generation and optional custom intersection test shaders


Harmonizing Techniques

DX Raytracing has the potential to harmonize many of the existing and varied rendering techniques. Many current rendering subsystems try, in their own unique way, to trace and sample light, material, and geometry in the scene. Though perhaps not yet performant enough, the availability of RT raytracing could unify these sampling mechanisms either directly through raw DXR or via an engine layer.  The introduction of RT raytracing also further marries offline rendering with RT (as PBR before it).   Below is a list of potential shifts in how RT rendering might grown and develop with the introduction of this common API.   


Primary Rays

It is very unlikely that, in the near future, primary (from camera) rays will be raytrace due mostly to cost. Rasterization is greatly superior in performance to raytracing for some obscene level of scene complexity. Even with high scene complexity, modern render engines use various forms of occlusion testing to reduce overdraw/overtesting.  Still, raytracing primary rays might have some advantages in the areas of transparency, non triangle rendering, and reduced render engine complexity.
Primary rays from camera in red. Secondary in black. [1]


Ubershader

As documented in the initial DXR API there are potential issues with hit shaders and material variation [2, section 3.1] . A single call to DispatchRays may end up having rays hit multiple geometry that in scene actuality have multiple material (and therefore shader) definitions. Since the call to DispatchRays has only the specified hit shader there exists a problem with trying to represent all materials in a single hit shader (what one might call an ubershader). This problem can be overcome by mixed shader combinations, uv storage and post shading passes, or callable material shaders within hit shader.

Local Lighting Sampling

Many of the screenspace techniques developed over the last decade (ie SSAO) are about computing the potential occlusion of light by local geometry [5]. A simple locally limited raytrace can compute caustic, emissive, specular occlusion, ambient occlusion, multi-layer inter refection. Blending high quality local light sampling with more coarse grained lighting information is already done with techniques like Screen Space Reflection (SSR) [8].

Localized raytracing computes lighting in a similar but less obtuse manner than screen space tracing or voxel tracing.


Transparency

It was once hoped that raytracing would resolve the difficult technical issue that transparency affronts to rasterization [6]. However transparency does not appear to be solved by DXR for two reasons. It is unlikely that (initially) the primary view will be raytraced. It is possible to say raytrace only the purely non opaque parts of the primary view but this would still likely be quite costly.  Second, the execution order strictness on the hit any shader is undefined [2, section 4.10]; meaning that it cannot be used out of the box to perform do order independent transparency. Reording of these intersection samples would be required to correctly shade the raytrace [7]. It might be possible instead to use hit nearest shader to find the first transparent object and then to continue to trace from there iteratively.


Level of Detail (LOD)

Scene complexity reductions (lower poly count, lower material variation) is just as desired for raytracing as rasterization [4]. Its is not entirely obvious as to how DXR would be used to support LOD as it would need to be per ray and fully dynamic along the trace path. It could perhaps be supported through a combination of hit shaders and DXR API scene filter/masks. More complex solutions could involve regions with portals for tracing between LODs. DXR does not appear to have an out of the box LODing solution.

Shadows

Primary shadows (ie Sun cascaded shadow maps) are likely not to be imminently replaced with raytracing as the cost would be prohibitive due to the amount of scene being traced. Soft shadows have a somewhat possible different character with raytracing than with rasterization as nearest occluder information is available. Very likely some shadow mapping will remain for the time being and will be instead be supplemented with raytraced local shadowing (especially for contact shadows).


Photon Mapping

Under specific conditions it tends to be advantageous to trace rays from the light source and not from the camera. A shadowmap in some way is a first hit ray coherent photon map. Raytracing from light source through bounce lighting could enable some cost effective raytraced caustic rendering. A photon can be reverse frustrum traced to determine its potential location in a screen space buffer.

Special Rendering

Due to the optional custom intersection shader DXR implicitely supports specialized tracing. This type of specialized tracing could aid in the usage of non-polygonal (ie voxel) rendering and lend to high quality effects like fur, volumetric effects, particle rendering, and LOD occlusion [9].

Emissive surface

Emissive materials have been supported in some high quality render engines for some time now. There are a range of techniques to make this type of effect work from voxel tracing to screenspace sampling to shader raytraced billboards [10]. Now this technique can be unified when costs allow and likely integrated into the general local raytracing shader.

Light Probes

If still required for performance, light probes can now be minimally rendered with selective rays and maxium distanced specified. Multiple probes can also be batched in a way that lends to cache coherency. Light information coming from raytraced sources can also be voxelized and then temporally and spatially propagated. In this way raytracing still acts as a harmonizing mechanism for all lighting computations even if those computations are later stored and interpolated.

Potentially Obsolete Techniques

  • Secondary shadow maps (maybe)
  • SSAO (likely)
  • SSR (likely)
  • SSO (likely)
  • Caustic emulations (maybe)

Challenges for the DXR Paradigm

The DXR API specifically states that each ray is considered to be independent (when in flight) and has unique reference-able data. This makes GXR a pure raytracing API in that there is no user level access to ray hierarchy (aka coherent bundles). Given that it still remains a practical question as to if coherence mapping of rays adds any performance benefit to the raytracing process [11], the decision to hide ray hierarchy from userland code is likely the correct one.

There are however several downsides to this extremely simple and raw API that cannot be covered here but might be in a future article. They are simply listed below.

  • Sampling has to reconstruct (texture) filtering parameters
  • Hidden but perhaps leaky abstraction of performance (driver specific)
  • Cache issues with user code level adaptive sampling
  • Ubershader and limitations on "TraceRay" might make usage complex
  • Analytical (biased) tracing might be superior for low RT performance constraints
  • Unexposed but useful information is hidden


[1] https://blogs.msdn.microsoft.com/directx/2018/03/19/announcing-microsoft-directx-raytracing/
[2] D3D12 Raytracing Functional Spec
[3] DirectX forums: Getting started with raytracing
[4] Perceptual level of detail for efficient raytracing of complex scenes
[5] Bent Normals and Cones in Screen-space
[6] Order Independent TransparencyIn OpenGL 4.x
[7] Order Independent Transparency with Per-Pixel Linked Lists
[8] Efficient GPU Screen-Space Ray Tracing
[9] Sparse GPU Voxelization of Yarn-Level Cloth
[10] The Technology Behind the DirectX 11 Unreal Engine"Samaritan" Demo
[11] Coherent GPU Ray Tracing: Improving Data Locality

Tuesday 13 March 2018

Twenty years later: Offline vs Realtime Rendering

Just like its predecessor Riven was a game composed of prerendered CGI images. Twenty years later Obduction a sequel in series was created as realtime with the unreal engine. Given the advancement of hardware and CGI algorithms over 20 years how do these two compare?

Comparison validity

It does not initially seem fair to compare offline rendering to realtime (desktop) rendering. Beyond simply stating that this analysis will be qualitative the following arguments can be made:

Performance

Riven was rendered offlline using 13 SGI Indigo workstations. The performance estimate for this as though it is a single server is likely no more than ~2.0 Gflops.  In contrast today something like a gtx 1070 has on the order of 6 Tflops. Worst case frame time for an offline render in riven was an hour or less. While Obduction is fully realtime (30 fps) it uses temporal super sampling that can require up to half a second to settle. Resolution in Riven is at least 1/4 the pixel density of realtime however it is extremely difficult to draw a quantitative comparison due to scene complexity. The original offline rendering still likely has 2-6 times the raw compute power available to it per frame over the realtime advancements.

Tools and Budget

There are likely no first order arguments that exist that would suggest that CGI workflow tools have degraded in performance and usability.  It should be much easier to create high quality 3d scenes in 2013 than in 1993. Riven had a budget of ~4 million (2013 dollars) with a development time of 4 years. This contrast with the smaller budget of 2.5 million (2013 dollars) and 3 year dev time for Obduction.

Style


Finally to do qualitative comparisons of images we should first make it clear that this is an apples to apples comparison. The graphical style of Riven and Obduction are the same in the following ways.

  • Attempts at photorealism
  • Objects with history (wear)
  • Real world detail (construction)

Critique


Obduction

con - environment lighting, flat lighting, no contact/secondary shadows, spectacular inconsistent scene lighting,  texture as material errors, incorrect weathering, incorrect usage, incorrect or missing construction, visibly low poly

pro - PBR, soft shadows, very high resolution textures,


































Riven


con - sharp shadows, low res textures, poor organic representations, inconsistent materials, excessive bump mapping, stretched textures, unrealistic heighfield terrain

pos - raytraced materials and shadows, thousands of lights, apparent occlusion effects, properly weathered objects, properly constructed objects, real world details, no environment lighting,



























Conclusion

Graphically Riven is a significantly better work. It stands to reason that it should be possible to achieve the graphical quality of riven in realtime today. Advancements in computer performance, content tools, and graphic algorithms lend credence to this idea.  Obduction however is not a data point in support of this theory.

[update]
There apparently is a realtime version of riven in development called Starry Expanse. We will have to see what the end product looks like but the results already appear to be an improvement over Obduction. (See images at http://www.starryexpanse.com/2017/06/10/stacking-shelves-gehns-lab/)


Ref

https://en.wikipedia.org/wiki/SGI_Indigo

https://en.wikipedia.org/wiki/MIPS_architecture#MIPS_III

http://mrillustrated.com/faq.php