How can I use the graphics pipeline to render volumetric data based on a density function?

Question

Both graphics APIs (OpenGL and DirectX) devise a well defined pipeline in which several stages are programmable. These programmable stages require to take a fixed minimum amount of data and are supposed to do a well defined range of operations on it, and output some defined minimum output, so that data can be passed on to the next stage correctly. It seems as if these pipelines are designed to work with only a limited amount of types of geometric data, which in the case of both D3D and OGL are vertex data and texture co-ordinates.

But, if given a case when the application I plan to make doesn't use vertices ( or even voxels ) to represent its geometric data and does not exactly do transformations or projections or rasterisation or interpolation or anything like that, such limitations of the APIs or the pipeline make things difficult.

So, is there a way in which we can change graphics pipeline in a way so that the functionality of what each stage does to the data and the type of data that is outputted in each stage is changed to my advantage? If not, then is there a way by which I can use the 'raw' API functions to construct my own pipeline? If not, then please mention why it isn't possible.

EDIT : My Application uses density functions to represent geometry. The function has a value at each point in space. I divide the frustum of the camera into a 3d grid, each block can be projected as a pixel. On each block, I integrate the density function and check if its value is more than a required value. If yes, then its is assumed that something exists in that block and that pixel corresponding to that block is rendered. so, now in my renderer, I want to pass the function ( which i represent with a string ) to the graphics hardware instead of vertex data in vertex buffers. this also implies that the vertex shader won't have vertices to transform into homogeniouse clip space and the fragment shader doesn't get pixel info. instead, now most of the looking up and evaluation happens per pixel.

Answer 1

You can absolutely use the GPU to render volumetric data.

Since you want to evaluate a set of functions per pixel on the screen, a simple approach is to render a full-screen triangle. This is just a single triangle that covers the entire screen (actually, it covers more than the screen, since the screen isn't triangular, but the parts off-screen are discarded by the GPU). You can then use the pixel shader (which receives the screen coordinates of the pixel it's shading) to construct a ray through your volume, evaluate functions, whatever you need to do.

(In contrast to the other answers, I don't recommend a compute shader because it sounds like you want to do per-pixel operations, and a full-screen triangle + pixel shader is generally more efficient for that than a compute shader—although compute shaders will certainly also work.)

The full-screen triangle method is very common in real-time graphics for postprocessing operations, so you can probably find all the information you need on it with a bit of googling.

BTW, it may interest you to read Rendering Worlds with Two Triangles by Iñigo Quílez, a talk which describes how to render 3D scenes composed using mathematical functions (specifically, distance fields) using the full-screen pixel shader technique.

Answer 2

Ray tracing and other techniques are commonly done with Compute Shaders, which Direct3D has supported since the release of D3D11 and OpenGL has supported since 4.3 (and longer via the use of OpenCL and some contortions).

Answer 3

It sounds very much like you want to use a GPU compute shader, or utilize a "Shader Storage Buffer" object to help augment the pipeline to fit your needs. Mathematicians, scientists, and other people who look to the GPU for computation on things that don't exactly translate into standard graphics use this kind of thing.

Although the contemporary graphics pipeline is very flexible, developers still tend to stumble on some restrictions. The compute shaders feature, however, makes life easier for us to not think about pipeline stages as we are used to thinking about vertex and fragment. We are no longer restricted by the inputs and outputs of certain pipeline stages. The Shader Storage Buffer Object (SSBO) feature for instance has been introduced along with compute shaders and that gives additional possibilities for exchanging data between pipeline stages, as well as being flexible input and output for compute shaders.

http://community.arm.com/groups/arm-mali-graphics/blog/2014/04/17/get-started-with-compute-shaders

If this does not point you in the right direction, would you mind expanding the concept of yours that doesn't fit the vertex/fragment paradigm?