I have recently done some experimental work in order to render mass amounts of cubes. I was moved by this video from Smash, i wanted to know how far i would be able to go on my NVidia GT240M (rendering side). My first choice was Geometry Shaders.
I quickly wrote an app that sent a list of points in space to the GPU and a geometry shader would generate a cube mesh for each one of  the points. Tested it on 100.000 cubes and the framerate was bad(10fps or so). The time was now for optimization.

Next step was to optimize the cube generation by lowering from a 24 vertex cube to 14 vertex triangle strip. Things got better, but nothing close to my expectations. I was not satisfied, i mean, i had alot of cubes on screen (100K which was not that much) and that was it, nothing else. We’re talking about 20fps or so, for 100.000 cubes (around 1.2 million triangles per frame). Later on i added vertex normals to the geometry shader and started to work on some lighting/shadowing, but i ended up going back on the rendering side of the job. Meanwhile, i was speaking with a friend of mine about this idea and we were discussing ways to compute lighting but i couldn’t stop thinking about my real problem. So it came to me.

Previously, i have done some experiments with opengl hardware instancing, but never got  to do much about it .  What better time than now, so i grabbed the project and took it for a spin. After a few hours i had the same amount of cubes on screen with a much much better framerate. Quickly implemented some eye-candy (coloring, texturing, vertex lighting), some tweaking here and there and as i was listening to Mr. Peter Broderick (hi, i love you man) added some audio analysis to the feature list.
Last but not least, a kind of “Brownian Motion” was used to generate points in space, increased the cube count to 512*512 and watched it flow ( at 20fps ).

In conclusion, Hardware instancing was much easier to implement  and performance seems much better at first sight. Above is a video of 262.144 audio-reactive cubes with GPU animation and basic lighting at around 20fps. For my video card i think that is very good. On a sidenote, i have not given up on the geometry shaders. I am not sure what will be my next step regarding the subject (back to geometry shaders?) but for now this is it. Hardware Instancing kicked Geometry Shaders in the ass.

This is the outside projection for Monologue Muet exhibition, a photography work by Sue Elie Andrade De.
Based on her video called The Rain, i have created the outside projection with response to physical properties, like doors and windows.

I have noticed that OpenCL4Java is on version 1.4beta by now and that my examples were crashing when running on a GPU device. Today i took the time to do something about it. I have downloaded the new version and have updated the examples to run with 1.4beta. Everything seems to work just fine now, if you have a different opinion, please do let me know.

Download: http://victamin.googlecode.com/files/JavaCL_1_4b.zip

Have fun!

Since Star Wars(tm) (so i’ve read), texture-based techniques have been used to improve the detail on planar and easily curved surfaces. The one i’m talking about here is called Greebles. Apply an heightmap texture on a surface and on a per-pixel basis, geometry is generated acoording to the pixel’s intensity. By doing it you get more detailed surfaces without having to model every little part by yourself, making things more interesting, realistic and much more appealing.

To achieve this i’ve picked Vertex Texture Fetch. It allows you to access texture data on the vertex shader. Pass a texture to the vertex shader and offset the surface vertices by the pixel’s intensity. To improve the looks, bump-mapping with multiple lights have been used. Everything presented here is generated on the GPU, even the objects. Runs nicely on a Nvidia 8200M. Lots of  space for improvement.

I finally took  the time to play with OpenCL. I was motivated by the particle example from Rui Madeira. After speaking with him, he gave me a few other links on more examples like Memo Akten‘s 1.000.000 particles running with mouse interaction on the GPU, the very NVidia’s first OpenCL application example, etc. I was intriged!  So i took the day to play with OpenCL4Java and ported Rui’s example to Java running on Processing’s IDE.  I’ve tested it with a Intel Quad core and i found the Rui’s sample to crash with GTX280 videocard. I didn’t gave it much thought but it might be for that for-loop in the program on the particle-particle iteration. In the other hand, Memo’s example ran easily on the gpu side. I should have made an example of mine, but it was easier to just port their examples and get things running. That was the main goal.

I have only tested this under Windows XP 64bit with ATI Stream SDK and Nvidia drivers. If you find any problem, please report.
One other thing: Memo’s example isn’t the real thing. It’s simply the CL program. So you won’t be able to get all the fuzzy million particles around. Not yet.

Library/Examples available here: http://victamin.googlecode.com/files/OpenCL4Java_1b.zip

Installation steps:
1. Copy the library to processing’s libraries folder
2. Install ATI Stream SDK (i have packed the OpenCL.dll file, still you might have to install the whole pack). If you’re using Nvidia, install the OpenCL drivers and toolkit
3. Open the example and run it.

Enjoy and have fun!