(non fractal) OpenCL programming example

[hobold]

Apologies that this isn't primarily about fractals. But it might be interesting to other programmers, who might have some use for a simple ray tracer written in OpenCL.

Some of you might remember the juggler demo on the Commodore Amiga home computer. Floating point throughput has increased by a factor of ten or hundred millions since then. One day it struck me that's enough to animate good ole' juggler in realtime (on a sufficiently beefy GPU - my dated Radeon HD 5870 delivers a stable 60 fps).

A bit more info and the (GPL'ed) source code can be found here: http://vectorizer.org/jugCLer/index.html.

[cKleinhuis]

nice one, in fact i saw it often, i received my amiga500 in the year of 1989
somehow i ignored it all the time, i read in an c++ programming book about raytracing back then, but since i had to wait halve a day for a single image i abandoned it then would be nice to see a video of it, since i think i am not able to get it running here

[hobold]

Well ... I am partly trolling for help here

Maybe one of the forum participants manages to compile it for Windows. It was successfully compiled and run under Linux with AMD's SDK, as well as MacOS X 10.7's native OpenCL support. And the one platform specific function - obtaining the wall clock time - has been in use in some other Windows program before.

So porting shouldn't be hard ... but the various OpenCL compilers have proven to be choosy, so the kernel source might require tweaks. I might not have done everything right with regards to the OpenCL dialect of C.

BTW, the author of the first juggler resurrection (as mentioned in the readme.txt contained in the tarball) has suggested that I port it to WebGL. But I don't think that I can work around the limitations of the GLSL programming environment.

[cKleinhuis]

for me c# is the only language i am using right now , for c# exists a opentk library with opencl support, which i have not used until now,
the only limitations for weblsl seems to be the real hardware limitations, what do you do for the juggler ? i think you have some kind of raymarching
and some scene definition for the rendering...?

[hobold]

GLSL was intended for a rather narrow purpose. As far as I understand, there are no proper variables ... everything has to be packed into textures, which can then be sampled during shader execution.

The jugCLer is a classical raytracer. It intersects view rays with spheres, computes secondary rays for shadow tests and reflections, and so on. One has to jump through a few hoops to do this without recursive function calls, because OpenCL does not allow those (only one or two GPUs today actually support general recursion efficiently).

Floor and sky dome are special cases, everything else is an array of spheres (each with a center, an radius, and some surface material). The CPU keeps updating the sphere positions (and the light source and the camera) between frames, whereas the GPU kernel treats the scene description as invariant (per frame).

Most of everything is basic and dumb, so to speak. The only slightly advanced features are antialiasing of the checkerboard floor (faked, really) and ambient illumination of the spheres, so that they show some of their contours even when in shadow (faked, too).

[David Makin]

Has anyone got decent OpenCL examples in the form of Xcode projects, I now have no time for any other development systems.

[hobold]

Has anyone got decent OpenCL examples in the form of Xcode projects, I now have no time for any other development systems.

Apple has several OpenCL examples among the sample code on their developer website. Unfortunately, the older examples seem to be unmaintained, and no longer compile.

Some of the newer code samples look less scary, because Apple has hidden a lot of the boilerplate ugliness behind an interface that looks more like CUDA. But using these goodies means giving up on OpenCL's promise of portability.

[flexiverse]

Ah..I love that juggling demo....

Brings me all nostalgic for cgi. It's that lovely shiny raytraced now 'retro' look that really
Got me excited about cgi.

So pleased there is a retro cgi youtube...

http://www.youtube.com/user/VintageCG


I'm sure  I've seen a real time demo of the juggler ages ago using cpu power!

http://www.pouet.net/prod.php?which=1914

This would be easily done in real time now on modern gpus.

In-fact what is exciting is now with gpus all those. 80s retro cool shiny cgi
Can be done in real time !

Infact someone like syntopia or inigo quilez could program the juggler in their sleep
In like 5mins going by their amazing fractal shader demos they have done !

Here is some other 'source code' info to re-create it:-

http://meatfighter.com/juggler/

I'm sure it's quite easy to  use a raymarcher instead now...

Rendering fractals is way way more complicated than a flat plane and sphere !


More on real time raytracing here:  http://www.codinghorror.com/blog/2008/03/real-time-raytracing.html

[David Makin]

I confess I've never really been interested in "portability" since it usually means that when ported from the original OS the other versions suck no matter how compatible things are supposed to be, much better to re-write what needs re-writing

[Syntopia]

GLSL was intended for a rather narrow purpose. As far as I understand, there are no proper variables ... everything has to be packed into textures, which can then be sampled during shader execution.

As long as it is read-only, GLSL has variables you can set from the CPU side (called uniforms). For instance, you could pass an array of sphere centers using the 'glUniform3fv' command. So a simple raytracer is not too difficult.

Things got more difficult if you want to build spatial acceleration structures - but it is still doable in GLSL: these guys made a nice WebGL path tracer with BVH acceleration: http://cg.alexandra.dk/2012/12/21/glsl-and-webgl-pathtracing-benchmark/

Btw, the reason textures may be necessary is because the size of the uniform variables is quite limited: I think that the OpenGL standard only guarantees 4K is available.

[flexiverse]

As long as it is read-only, GLSL has variables you can set from the CPU side (called uniforms). For instance, you could pass an array of sphere centers using the 'glUniform3fv' command. So a simple raytracer is not too difficult.

Things got more difficult if you want to build spatial acceleration structures - but it is still doable in GLSL: these guys made a nice WebGL path tracer with BVH acceleration: http://cg.alexandra.dk/2012/12/21/glsl-and-webgl-pathtracing-benchmark/

Btw, the reason textures may be necessary is because the size of the uniform variables is quite limited: I think that the OpenGL standard only guarantees 4K is available.

Gauntlet is thrown then....

Since the juggler is basic phong raytracing with spheres , 1 plane , and movement is procedural/formulas ..a shader toy version should be easy with your coding chops !