DXR Demo - Michael Hamm

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

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

Code so Far Here is the  code  after this section Enabling Raytracing - Part 1 Now that we have created a basic render using rasterization, the next goal is to create the same render using ray tracing, and a mechanism to switch between the two rendering modes. For this I followed the  NVidia raytracing tutorial  which is split into two parts. In order to switch between the the two modes I needed to bind keyboard events from the Window to the Game class. Just like how the WM_Paint method is subscribed to currently, I added subscription callback mechanism for WM_KEYDOWN, and WM_KEYUP Window's events that the game class now subscribes to.  On space bar, the window is configured to switch between raytracing and rasterization. For now, since raytracing is not implemented, if the user presses space bar, it goes between using rasterization, and rendering nothing. This was updated within the render loop of the game. After making these updates, this is the current state of the program: Afte

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&

All good projects must start somewhere. Before we can begin working on portals, a window needs to be created, and DirectX 12 needs to be initialized. For this, I heavily utilized Jeremiah's tutorial on DirectX 12: https://www.3dgep.com/learning-directx-12-1/ . This is the  code so far . There is a lot of code here! With almost 800 lines of code, the final result!? (drum roll)  Yes! A Window! There is a lot moving components within DirectX 12 in order to initialize it. Way more than DirectX 11! In order to initialize DX12 we first we needed to get the adapter, then create a device, then create a command queue, then create a swap chain, then create a descriptor heap for retender target views, then create render target views, then create command allocator per back buffer, then create a command list, then create a fence... Phew! Once all of that is done we can finally run our game loop. The render loop contains the most important logic in understanding how DX12 is being used. The rende

Welcome. I am a programming student at the Florida Interactive Entertainment Academy (FIEA) and this blog's aim is to chronicle my ten-week solo programming project during my final semester. The project at hand involves the implementation of raytracing, harnessing the power of DirectX 12 and DXR. DirectX 12, the latest DirectX API as of its introduction on July 28th, 2015, alongside Windows 10, allows for advanced low-level programming. It streamlines graphics programming by reducing driver overhead and enhances efficiency in multi-threading tasks. This level of control, however, comes with an increased responsibility for the graphics programmer to thoroughly understand and manage the complexities involved in getting a program operational. As a first-time user of DirectX 12, I anticipate a challenging yet rewarding journey ahead. In this blog, I aim to document the developmental milestones, challenges, and technical insights that arise during the creation process. Expect to see dee