is it possible?

[madmuppet]

would it be possible to program a mandelbox viewer using c and opengl? reason being I am learning c already and my video card is a generation too old to make use of opencl.

if so where to begin? .. I have some ideas but I'm sure theres lots of things I have'nt begun to think about yet so hints appreciated.

if not what language would be recommended? and why?

thanks in advance al.

[Syntopia]

Depends on what you want to do.

If you want to render fractals using the CPU, C is perfectly fine. OpenGL will not help you there at all, since everything is done on the CPU. This is the approach taken by Mandelbulb 3D, and Mandelbulber.

But if you want to render using the GPU, you can use the flexibility of OpenGL shaders and the GLSL language. Instead of using the traditional OpenGL pipeline, you render a single fullscreen quad using a custom pixel shader, which is invoked for each pixel. The most difficult part is getting the setup right - after that GLSL is very easy to work with - like C, but with support for matrices and vectors builtin. This is the approach taken by Boxplorer, Fragmentarium, fractal.io, and most other GPU renderers.

Both methods have their pros and cons. GPU will be faster (for reasonable graphic cards), but less flexible: some effects cannot be done on an individual pixel basis (e.g. the post-processed Depth-Of-Field used in Mandelbulber requires sorting), and I doubt you can find a GPU with GLSL support for double precision floats.

OpenCL would be more flexible that OpenGL and GLSL, but is much more complicated to setup.

[zenzero-2001]

If I'm not mistaken OpenCL doesn't only support the GPU on the graphics card but also multi-core CPUs. Perhaps, you could program in OpenCL for the CPU? I don't know too much about OpenCL, but I get the impression that the same code should work on a mult-core cpu and a gpu:

http://www.amd.com/us/products/technologies/stream-technology/opencl/pages/opencl-intro.aspx

Here is a really cool webiste with OpenCL code for GPU / Multi-CPU Mandelbrot (and other code geekery!) - should keep you busy! 

http://www.bealto.com/mp-mandelbrot.html

As Syntopia said, if you wish to use OpenGL for the graphics then you are better off using / learning GLSL rather than the traditional OpenGL pipleline, as I believe the latter is deprecated. GLSL skills would also be transferable to mobile devices, if you ever decided to develop for those.

OpenGL will only help with the graphics, whereas OpenCL should help with the fractal calculation (which I'm guessing is more likely to be the performance bottle neck).

[cbuchner1]

Intel has a web site with the details which features they support in their OpenCL SDK and which they don't.

http://software.intel.com/en-us/articles/opencl-sdk/

One of the major issues would be operating system support. They only support 64 bit Linux (and that support is Beta).

[Syntopia]

One of the major issues would be operating system support. They only support 64 bit Linux (and that support is Beta).

They also support windows: I've tested Intel's OpenCL SDK on my Windows machine some months ago, and it runs fine. And yes, the same code may be run on both GPU and CPU. I tested a Quaternion 4D Julia fractal implementation, and on my machine it was 7x faster on the GPU (Nvidia Geforce 9800GT  GPU @ 1.5 GHz, and Intel Core 2 Quad Q8200 @ 2.33GHz.).

OpenGL will only help with the graphics, whereas OpenCL should help with the fractal calculation (which I'm guessing is more likely to be the performance bottle neck).

Just to be clear: the approach with OpenGL/GLSL also does the entire fractal calculation on the GPU. There is no distinction between graphics and fractal calculation and there are no polygons involved. OpenCL will not be faster then OpenGL/GLSL (but will be more flexible, e.g. allowing for double precision calculation if hardware supports it).

[zenzero-2001]

Just to be clear: the approach with OpenGL/GLSL also does the entire fractal calculation on the GPU. There is no distinction between graphics and fractal calculation and there are no polygons involved. OpenCL will not be faster then OpenGL/GLSL (but will be more flexible, e.g. allowing for double precision calculation if hardware supports it).

Thanks for clarifying that, I didn't think about performing the actual calculation in GLSL.

[David Makin]

OpenCL would be more flexible that OpenGL and GLSL, but is much more complicated to setup.

Doesn't seem that difficult on a Mac through Xcode, though I haven't tried it yet, at the moment I'm sticking to simple shader 2 so things work on iOS too.

[eiffie]

Check out "Boxplorer" on Google Code. (c and opengl) It was put together by some people at this forum. I have used the code as a sanity check for my own programming. There is also a Boxplorer2 with added features like DOF etc.

[madmuppet]

thanks for all the info .. looks like I got a ton of work ahead of me ..:p

anyone want to chime in what compilers they are using? I have been using emacs and gcc up till now .. I recently had a look at codeblocks and visual studio and they are an additional layer of complexity

[marius]

thanks for all the info .. looks like I got a ton of work ahead of me ..:p

anyone want to chime in what compilers they are using? I have been using emacs and gcc up till now .. I recently had a look at codeblocks and visual studio and they are an additional layer of complexity

I made boxplorer2 buildable with g++ on linux, the free vc++ on windows and xcode on the mac using some very simple makefiles.
Thanks to SDL abstraction, mostly. See http://code.google.com/p/boxplorer2/source/browse/#svn%2Ftrunk

The particular c++ compiler really isn't that relevant; the cycle burning glsl code gets compiled by the graphics driver, on the fly.

[madmuppet]

thanks for all the help .. very much appreciated ..

al.