Frame and Vertex Shaders, Examples, Final Thoughts
Frame Shaders

Frame shaders serve as the source for the initial rays that are emitted and are used to implement the “camera” for a traditional ray tracing engine or for whole-screen based filters, etc. 

Caustic Graphics and the CausticGL Ray Tracing API - Graphics Cards 8

A frame shader will execute once for every pixel in the output frame buffer and is responsible for all other rays that will accumulate color to the pixel.  Much as ray shaders have access to object-specific data, the frame shaders have parameters based on the entire scene to work with. 

Vertex and Geometry Shaders

Because of the way that ray tracing works, much of the logic associated with geometry in a 3D scene has to be adjusted.  Modern rasterization engines use complex culling algorithms to remove geometry from the scene that the camera can’t “see” – this speeds up the rendering engines as it reduces the number of pixels that need to shaded and processed.  The same methods are not transferable to the traditional ways we think about ray tracing – instead any piece of geometry is potentially visible to any RAY that happens to be bouncing around the scene.  If a ray bounces off of a visible object, then hits the BACK of another object (that would not normally be visible to the camera) and then bounces to another visible object, there may be some attributes of that “hidden bounce” that the programmer wants access to.  (Maybe that back of that object was a bright, shiny gold and you wanted that effect to be transferred to the visible pixel that the ray hit afterwards.)

Because of this, CausticGL and the CausticRT platform must retain all of the scene geometry for the entirety of the frame rendering process.  That could create an issue if the scene is VERY complex as the memory requirements could be higher than most rasterization implementations of the same scene.  The trade off could come in terms of visual fidelity, at least in theory.

Because of this memory complexity, modifications of the geometry of a scene using vertex shaders are handled very carefully.  Traditional vertex shaders are permitted in CausticGL, and they are the same as the OpenGL variants, but they are run for every vertex in the vertex buffer.  Because the memory footprint has the potential to be very large, that could be a taxing operation on the system depending on the hardware the application is running on.  It also indicates why Caustic Graphics told us they spent so much time on (and were so secretive about) the memory controller and technology in its CausticOne and CausticTwo acceleration hardware. 

The solution to this problem for the CausticRT platform, as this technical brief tells us, is a use of internal, behind-the-scenes acceleration structures to speed up the determination of the ray-geometry intersections.  These structures are often one of the key components of any ray tracing engine, but Caustic seems to be handling them for you at the cost of technological transparency.  If the geometry remains unchanged from frame to frame, no work is necessary to modify the acceleration structures of course but if some modifications are needed, CausticGL implements some custom matrix-based modification functions that do NOT require a COMPLETE rebuild of the structures. 

Examples

In the technical brief, Caustic then walks the reader through building the classic “Whitted Scene” that most any graphics programmer learned in the first week or so of college, post-1985. 

Caustic Graphics and the CausticGL Ray Tracing API - Graphics Cards 9
Image courtesy: http://www.jayaustin.us/?p=30

I won’t bore you with the syntax and details of how it is done; you can see how simply it is achieved yourself by downloading the technical brief below.

The Real Story is Standardization

CausticRT, both the upcoming hardware and CausticGL software API, has the lofty goal of creating a flexible platform for ray tracing development.  By using a well known and understood programming model (based off of OpenGL) and handling most of the performance critical aspects of ray tracing in the background, Caustic is hoping that more and more developers will find ways to implement ray tracing in their projects.  If updated and maintained properly, CausticRT could become a flexible enough architecture to meet the needs for today’s high-end developers and advance the medium to a point where ray tracing is the primary method of rendering.  Of course, much of this depends on the advancements in hardware – both for CPUs, GPUs and Caustic’s own ray tracing accelerator cards – as we still need more processing power to achieve high resolution, fluid real-time ray tracing. 

Caustic Graphics and the CausticGL Ray Tracing API - Graphics Cards 10

Obviously Caustic wants to get word out about its CausticRT platform and CausticGL – the more developers and researchers using it the better chance it has of making significant and speedy progress through the Khronos Group towards the goal of standardization.  The benefits of getting a standard would be astronomical to the end user and developer – just as with DirectX and OpenGL, processing companies like NVIDIA, AMD and Intel would then have a very specific instruction set to implement on their hardware allowing them to focus on performance and implementation.  Developers would also be more likely to start implementing the ray tracing API on a larger scale once the majority of PC hardware (or at least in gamers PCs) properly accelerates the API.

There are some hurdles of course.  The first is time – while Khronos does act quickly compared to some other standards groups, it’s unlikely that we’ll see anything happen within a year that will dramatically change the current status of ray tracing APIs.  Caustic will also have to plead its case against the likes of NVIDIA and its NVIRT ray tracing engine and standard for dominance.  More than likely, we will see some combination of both APIs implemented into the final standard (if one comes) but the company that contributes the majority portion could have a leg up for future hardware sales and mindshare.  Finally, Intel has a little something called Larrabee coming down the pipe sometime in 2010 and that could put an entirely unique twist on the whole debate depending on how it performs compared to current GPUs and CPUs.  Caustic will tell you that it welcomes the Larrabee as a processor for CausticRT but obviously there are politics involved in this debate.

Overall, I have to say that after looking at the technical brief that Caustic sent us last week, I definitely have a better understanding of what the goals of the company are and how it plans to achieve them.  Though I am not a graphics developer by training, I know enough just to be dangerous and it really does seem like the ray tracing implementation that CausticGL offers is a big move forward compared to creating ray tracing engines in the traditional ways on an engine-by-engine basis.  Another key to the implementation of this API is performance – how will CausticGL perform on today’s CPUs and GPUs in addition to the company’s own acceleration hardware?  Developers will definitely want to see some great results (and a dedication to future performance enhancements) before putting the future of their own products and technology in Caustic’s hands.

You can grab Caustic Graphic’s Technical Brief on CausticRT right here if you are interested in reading it for yourself. 

Additional Reading:

« PreviousNext »