Rendering an IsoSurface using Cuda


I would like to render a 3D matrix as an IsoSurface using OpenGL using CUDA.

I am not sure how to do this , and is there an example that I can look at.


Hi there @fb1, welcome back, it has been a while since you last posted.

I am not aware that we have any current tutorials on this topic, but of course there are some CUDA samples for CUDA/OpenGL interop like simpleGL or possibly nearer to isoSurface simulation fluidsGL.
Of course there are some older forum posts on the topic as well like Modern GL Interop
And then there is the official documentation

I hope this helps already!

Hi @MarkusHoHo ,

thanks for the reply. I did find an example in the 2_Graphiics section marchingcubes. Marching cudes has been suggested to me previously.

One thing that I am not sure about, is what is the correspondence between OpenGL and the Cuda.

I am also not sure that I fully understand the difference between glu, glut, glew and OpenGL and and how they interact with the CUDA implementation.

In general we work with with ccp4, map or mrc volumes (z *(x * y ) , ie a stack of xy planes) , the example is raw format I am not sure that I have got the correct interpretation of the raw volume. I tried to convert the mrc to raw using IMAGIC or other and I am seeing disaary in the slices.

Anyway it would be nice to have a proper example without so many unknown.


OpenGL specifies graphics behavior without taking into account the actual machine implementation. So OpenGL by itself doesn’t do anything useful; it is usually (in my experience) paired up with a machine interface. These are sometimes referred to as OpenGL extensions, although that term is a bit too overloaded for my taste. The machine interface makes the “connection” with the machine-specific graphics implementation, e.g. via Microsoft methods (on windows) or X (usually, on linux). OpenGL, being driven by a standards committee, also may have a time lag between when a feature is desired by developers, and when it is available. “Extensions” are often used to fill this gap.

GLU, glut, and GLEW are libraries that provide extensions to OpenGL, add on additional capability, or are part of the OpenGL-to-machine interface. That is why they appear “separately” from OpenGL. All of the discussion so far is not unique to CUDA or NVIDIA. I won’t be able to give an extended OpenGL tutorial here, including on these ancillary topics. But there are plenty of resources available, even textbooks available, to learn OpenGL, and to learn about what the various add-on libraries do.

CUDA is not a graphics language per se. CUDA is for general purpose computing.

OpenGL is a graphics language (or API).

So if you want to compute the location of an isosurface in a spatial volume, perhaps using some general arithmetic, then CUDA might make sense for that.

If you have an isosurface defined, and you want to turn that into an asset that can be displayed in computer graphics directly, CUDA is not the right vehicle for that, OpenGL is.

Because of the natural compute->graphics data flow that seems evident/canonical here (use CUDA to define the surface, use OpenGL to display it, or “render” it), there is a defined mechanism called CUDA/OpenGL interop (a subset of CUDA/graphics interop).

CUDA/OpenGL interop allows for data exchange between CUDA and the graphics side/engine. The mechanism always works as follows: an asset (e.g. texture or buffer object) is created/defined on the OpenGL side. Then it is shared to the CUDA side. The sharing makes the data associated with the object usable by CUDA in an understandable way (e.g. as a pointer to an array). When the OpenGL side has access to the object (e.g. for “rendering”) the CUDA side does not. When the CUDA side has access, the OpenGL side does not. The hand-off back and forth is controlled by interop API calls.

Perhaps an OpenGL “purist”/expert will come along and correct my terminology.

Hi @Robert_Crovella ,

thank you for your very useful reply and clarifying things a little.

I am trying the marchingcube example to see if I can adapt it to my problem. I still have a problem with interpreting the mrc volume into a suitable data format. A typical map (3D volume) would carry either an mrc or map extension.


this may possibly be of interest