Caustic Graphics and the CausticGL Ray Tracing API
CausticGL Ray Tracing API
Brief Summary of Caustic Graphics
Last April I posted an article about a little known startup company called Caustic Graphics that claimed to have "solved" ray tracing with a combination of hardware and software advancements. The founders of the company came with a strong pedigree and put forth a convincing argument as to why their solution for ray tracing was indeed superior to anything else available in the commercial or education space. You really should catch up on the foundations of the company, the plans for hardware accelerators built specifically for ray tracing and the basics on the CausticGL software stack in our previous piece before going forward.
Real-time demo with AA enabled
In today's article we are going to take a look in more detail at the software side of Caustic Graphics CausticRT platform - CausticGL. Though I am a far cry from a rendering engine developer I think the technical brief that Caustic provided for us should allow me to share some interesting thoughts and comparisons to other graphics APIs.
What is CausticGL?
In our previous article we briefly discussed the idea of CausticRT - a ray tracing acceleration platform composed of both a software and hardware layer, though the hardware layer is in fact an optional portion. What we are interested in looking at today is CausticGL as it is the interface by which a developer can write ray tracing-based renderers. CausticGL is a programming API based around the OpenGL ES 2.0 standard with some heavy modifications and extensions included in it for ray tracing support and performance tweaks for compute and data structures built around rays.
Since CausticGL is based around the OpenGL ES 2.0 standard, it includes everything a developer would need to build a ray tracing renderer. Geometry submission, a high-level shading language and of course frame buffer objects are all supported but CausticGL is NOT itself a renderer. Because at its root it is nothing more than a programming API the developer has the same free reign to design different lighting techniques or effects that any modern rasterization based engine would have. Caustic even goes as far to say that the program utilizing the CausticGL API doesn't have to be visual at all - the unique ray tracing performance optimizations the company has made could make it interesting for high-performance computing or other mediums.
CausticGL runs as a completely independent application to other graphics APIs and uses stand-alone libraries/DLLs on both Mac OS X and Windows based systems. Because it doesn't replace the primary graphics APIs, the possibility exists that applications will be able to utilize BOTH at the same time: using CausticGL for ray tracing purposes and OpenGL for more traditional graphics workloads. Hybrid applications are indeed a possibility though the prospect seems somewhat tricky as it would require balancing two different memory systems (one for each API) and some kind of complex synchronization.
An image rendered by the CausticRT platform
As we keep alluding to, CausticGL does not HAVE to run on the proprietary Caustic hardware that we discussed in our previous article. To the contrary, the API will run on CPUs and GPUs to some degree and has the ability to load balance the most appropriate calculations to the most relevant processor in the system. Caustic still believes that its hardware will be the fastest rendering option with which to run CausticGL-based applications but with the end-game that Caustic has planned and is pushing for, they are desperate for developers to know that the hardware is NOT required.
That particular end-game that Caustic has targeted is the standardization of CausticGL by the Khronos Group as the defacto standard for ray tracing based programming APIs. The Khronos Group is the organization behind OpenGL and OpenCL and it would seem likely that it would indeed be looking for a new standard for ray tracing based programming. Of course, Caustic would have to rename the API for other companies to willingly approve of it and as with any standard submission process, there is going to be a lot of political work in the background as at least one other company will likely submit a competing ray tracing standard.
The CausticRT Pipeline
Much like OpenGL or DirectX, CausticGL is based around a pipeline with multiple stages each executing shader code.
The most crucial part of a ray tracer is of course, the rays themselves. In the CausticGL API, ray shaders are associated with a particular object in the scene; code that is run when a ray intersects with the object and determines the lighting and other material effects that will eventually be accumulated into the frame buffer for output to the user.
Ray shaders can access certain parameters: uniform data of the primitive object to which the ray shader is associated and variable data (information that varies based on the location on the primitive object) as well by using vertex shader information and interpolated vertices.
The rays themselves are created by other shaders using some unique CausticGL extensions to GLSL that add functions like "createRay()" and "emitRay()". When a ray is emitted the CausticRT platform (combination of software and what hardware is available) is responsible for the necessary testing to determine which object the ray intersects and then the appropriate ray shaders are called. At that point other rays can be created or the pixel accumulation can be finished.
One major benefit that CausticGL offers developers for ray tracing is that rays can be emitted one at a time without a need to track its progress or sync it with other similar rays, etc. All of the management of the rays "in flight" is handled by the CausticRT platform behind the scenes.