Refactoring & Rendering a Cube

Before the we are able to work on portals there still needed to be work done to setup the graphics pipeline and render objects to the screen. But, before even that, the code needed a little TLC. I refactored the previous code into three classes. Here is a UML class diagram describing the current layout. All classes are final for now.

Windows Class

The Window class encapsulates Win32 methods for creating the window and the Window's handle. This includes the register window class method, creating the window instance, and wndProc method. In order to achieve minimal coupling between the window and the game, the Window class has subscribe methods that take in function pointers. The Game's Update and Render method are then set as callbacks to the Window's paint method in main. To encapsulate the wndProc as a non-static method, I created a static and non-static member version of wndProc. On Win32 window instance instantiation, embed the Window's instance pointer on the Window's handle through GWLP_USERDATA. 


In the static WndProc method, the Window's instance is retrieve from the window's handle to call the non-static version of WndProc.

DXContext Class

The DXContext class encapsulates the DirectX device, adapter, swap chain, and command queues.
The DXContext maintains RTVs, provides accessors for them, and contains a Present method. It also has a method for creating descriptor heaps.

CommandQueue Class

The CommandQueue class takes the DirectX12 Command Queue, the command allocators, the command list, and the fence, and puts it into one abstraction. It uses an object pool of command allocators and command lists. It provides proper synchronization for the command queue. 

Game Class

The game class contains game specific code. The previous Update and Render methods are now within this class.

Rendering an object

Beyond refactoring the code, I setup our graphics pipeline by implementing a very basic vertex and pixel shader and configuring them through the Pipeline State Object (PSO) and Root Signatures. The vertex shader currently only modifies the vertices by multiplying them by a combined model-view-projection matrix. The pixel shader is as simple as it can get; it just outputs the color fed in from the rasterizer. The current object I am generating is a cube with with both vertices and index buffers. Here is the current output:




Comments

Post a Comment

Popular posts from this blog

Rendering a Scene

Image
Code so Far Here is the  code  for this section: Rendering a Scene Up to now I have just been generating a cube, which is good and all, but what I really want is to render a scene which can show off the ray tracer. I also want to render a scene that will allow me to test the accuracy of my render. To this end, I will be rendering the Cornell box. The Cornell box is commonly used 3d test model. It comes in different configurations but the models have corresponding photographs associated with them which allows us to compare the accuracy of our render to real life. Sample Cornell Box The image above is one such example of a Cornell box. Cornell boxes usually contain a red wall on the left, a green wall on the right, and a white wall on the back, floor, and ceiling. Objects are placed within the box and an area light illuminates the box from the top. Cornell Box in Blender For my project I will be using the model found from here . The model is shown above. The corresponding object hierarch
Read more

Enabling Raytracing - Part 2

Image
Code so Far Here is the code  for this section: Enabling Raytracing - Part 2 This week I added the shader binding table for raytracing. The shader binding table is where the data is bound to root parameters. This is contrary to rasterization where the parameters are bound through command list calls such as SetGraphicsRootConstantBufferView . One that was done I updated the render loop to support raytracing. This included transitioning the output buffer to unordered access, setting the pipeline state, and calling the DispatchRays method using the  D3D12_DISPATCH_RAYS_DESC which contains info about how many rays to generate, and the shader binding table. For my demo, one ray is generated for each pixel. After calling DispatchRays , our output image is written to. I then copy the image to the render target. The shaders were also updated to actually generate rays, and output the color of the cube. The RayGen shader was updated to call the TraceRay. The ClosestHit shader was modified to ca
Read more

Denoising

Image
  Code so Far Here is the  code  for this section Denoising Last time I implemented a path tracer that used importance sampling for optimization. This week, to wrap up this project I added a denoiser. When it comes to denoising there is a couple approaches. They are described here  but they are filtering technique, machine learning techniques, and sampling techniques. Filtering techniques are cheap but blur the image. Machine learning uses autoencoders to reconstruct images from noisy images. Sampling techniques use spatial and temporal data to denoise the image. Because, I am not denoising the image per frame I wouldn't be able to take advantage of spatial temporal solutions like Nvidia's real time denoiser (NRD). NRD would have been a better solution than machine learning however due to its performance. For my program I opted for a machine learning encoder. There were multiple to choose from the most popular were Nvidia's Optix, and Intel's Open Image Denoise (OIDN).
Read more