V

Avatar



MSAOpenCL for Java and Processing

Recently I have been doing some work with OpenCL and i found myself messing up with old code and re-writing most of it .  At first it was interesting and quite funny but no more, so,  I thought it was time to make things easier for myself and just make things reusable by creating a wrapper which would wrap most of the boring and time-consuming parts. This would be a wrapper on OpenCL for Java and/or Processing. Well, a well known guy named Mehmet “Memo” Akten has done such a wrapper in C++ for the OpenFrameworks and Cinder libraries. I have ported it  to Java.

There are some problems with reading/writing from/to GL textures. For some reason it crashes on me. I have been working with JavaCL‘s author, so hopefully it will be working soon.

:: Download

Download it, install it and try it.
If you find any problems or if you have suggestions, let me know.

Have fun.





Evaluate a Cubic Bézier on GPU

I’ve made an application as an example for this thread on how to compute/evaluate a Cubic Bézier Curve using a Geometry Shader. The formula is pretty straightforward as described by this wikipedia article (look for Cubic Bézier Curve). I will not go over the bézier math or theory. I assume you have some knowledge in shader programming (GLSL is the case) and some math background would help, while not really a need. All that said, let’s get to work.

On this case we will need 4 points: 2 anchor points (the line end points) and 2 control points. The control points won’t really touch the curve, they work more as directional information on the curve itself.

As we need to send this data to the shader i have decided to use  LINES as input primitive, 2 points define a line so it’s perfect, we’ll use that for the 2 anchor points. As for the control points 2 different texture units (glMultiTexCoord3f) attached to the line’s vertex data will do. Using geometry shaders besides setting the input primitive type we also need to set the output type. LINE_STRIP is fine, as it works perfectly for what we’re doing. That’s all on the application side.

On the vertex shader side it’s pretty simple:

[VERTEX SHADER]
void main( void )
{
    gl_FrontColor = gl_Color;
    ControlPoint1 = gl_MultiTexCoord0.xyz;
    ControlPoint2 = gl_MultiTexCoord1.xyz;
 
    gl_Position = gl_Vertex;
}

What the code is doing is sending the data further down the pipeline to the geometry shader, where all the magic happens. At this stage, having both Anchor and Control points we can now define the curve by a given detail. Think of detail as a number of step-points along the curve which makes it look smoother or flatten (tesselation, subdivision, smoothing, etc).

Both control points are sent by the application for the geometry shader, still, as in the the vertex shader comes before the geometry shader, we will need to send them down on the vertex-shader, otherwise the GS won’t be able to “see” them (i know, hurray for Cg). We’re now almost done. By using the function from the above link(s) and as shown below we compute the curve with a given detail on the geometry shader, by generating new vertices along the curve purely on the gpu side. I think it to be pretty straightforward and the code should be self-explanatory.

[GEOMETRY SHADER]
uniform int g_Detail;
varying in vec3 ControlPoint1[];
varying in vec3 ControlPoint2[];
 
// Found in nvidia sdk
vec3 evaluateBezierPosition( vec3 v[4], float t )
{
    vec3 p;
    float OneMinusT = 1.0 - t;
    float b0 = OneMinusT*OneMinusT*OneMinusT;
    float b1 = 3.0*t*OneMinusT*OneMinusT;
    float b2 = 3.0*t*t*OneMinusT;
    float b3 = t*t*t;
    return b0*v[0] + b1*v[1] + b2*v[2] + b3*v[3];
}
 
void main()
{
    vec3 pos[4];
    pos[0] = gl_PositionIn[0].xyz;
    pos[1] = ControlPoint1[0];
    pos[2] = ControlPoint2[0];
    pos[3] = gl_PositionIn[1].xyz;
    float OneOverDetail = 1.0 / float(g_Detail-1.0);
    for( int i=0; i<g_Detail; i++ )
    {
        float t = i * OneOverDetail;
        vec3 p = evaluateBezierPosition( pos, t );
        gl_FrontColor = gl_FrontColorIn[0]; 
        gl_Position = gl_ModelViewProjectionMatrix * vec4( p.xyz, 1.0 );
        EmitVertex();
    }
 
    EndPrimitive();
}

What’s next? That is up to you. You’re not going to leave me with all the work, are you ?

Download the example + source.
You will also need to install Vitamin 0.5.6 as the project is built with it.





Float

I have recently released at inércia Demoparty, a gift i made for Sue. It started as a christmas gift that would express myself and ofcourse keep me from following everybody else to the local shop and spend my money on something  made by others.

There is no executable this time, as i don’t know if i can spread the music, still, nobody can stop me  (for the moment) from giving you a video. So here it is, Float.





Mass cube rendering

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.





Monologue Muet – Outside projection

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.