Review Index:

Caustic Graphics and the CausticGL Ray Tracing API

Author: Ryan Shrout
Manufacturer: Caustic Graphics

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. 

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

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. 


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. 

Image courtesy:
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. 

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:

No comments posted yet.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote><p><br>
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.