Aliasing Beauty
Finally, i posted about the Aliasing Beauty, a relative to Black&White project created for Written Images book. Read more..
Finally, i posted about the Aliasing Beauty, a relative to Black&White project created for Written Images book. Read more..
So here it is, the application and source code for GML Viscosity.
I finally took the time to clean up this project and make a public release. In the packages you will find binaries and source code for the application, so if you’re thinking of using it and come up with something nice, let me know. After the first release i have fixed some problems with memory access and crashes. I have also added a simple UI for easy pick of tags from the “data/tags” folder on your hard-drive.
What is it?
- GML Viscosity is an experiment. It is application used to draw GML tags on a viscous liquid rendered purely on the GPU side.
What does it do?
- It liquifies your tags, in a way you can hardly read them but still looks cool (thats graffiti).
- It is possible to load gml files from the disk or directly from the “lots of zeros”book database.
How can I interact?
- Not implemented on this version. This version selects and draw gml files randomly from the web or from a tags folder. For a smart person it should be easy to add mouse support. The code is also prepared to support multitouch so, it should be easy to implement TUIO and create your multitouch version.
- Use ‘r’ key to randomly fetch a new tag from the website and if available it will draw it on the screen.
- Use the GUI window to pick any tag from the folder “tags” inside data folder.
Where can i get it?
Windows Version | MacOSX Version
Have fun.
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.
Hello there. Here is a new tutorial, this time about ping-pong on the gpu. I’ve been wanting to write about it for sometime, finally it’s off my todo list. Let’s get down to business. Ping-pong technique is normally used with a shader that needs it’s result as a source parameter for it’s next iteration. This is usually used in the gpu as for now it is not possible to write a program’s result to itself, so, we’ll need another equal buffer to save the current result for how next step/iteration. That was too hard?
So imagine we have 2 image buffers Image1, Image2. Usually to change data from Image1, you would simply access it and write directly back to the same positioion. Now, when we’re talking about a shader fragment program we can’t simply do that. You may ask now, what’s the solution? Ping-pong it!
Here is what i’m talking about:
// // Initialization // int W = 100; int H = 100; ImageArray = new int[2][W*H]; int CurrActiveBuffer = 0; // Current active buffer index // // Mainloop // for( int j=0; j<H; j++ ) { for( int i=0; i<W; i++ ) { // ERROR! Write to same buffer. Not possible in gpu shader //Image1[i+j*W] = Image1[i+j*W] * 2; // Mul by 2 // Ping-pong version int src = CurrActiveBuffer; // Current active buffer (Input) int dest = 1-CurrActiveBuffer; // Back buffer (Output) ImageArray[dest][i+j*W] = ImageArray[src][i+j*W] * 2; // Mul by 2 } } // Swap back and front buffers (read becomes write and vice-versa) CurrActiveBuffer = 1-CurrActiveBuffer; // CurrActiveBuffer ? 0 : 1;
As you can see we start with buffer 0. That’s where we get out data from (read) and write it to Buffer 1. Once the operation is done, we swap buffers every frame. This way we’ll be able to use last iteration’s data as input for the next iteration.
Now let’s put this in OpenGL language. I will be using a FrameBufferObject (FBO) and 2 textures here. The framebuffer will be holding to both textures as 2 Color Attachments. So let’s get coding:
// // Initialization // int W = 100; int H = 100; int FboID; int TexID[2]; int CurrActiveBuffer = 0; // Current active buffer index // Create the frambuffer glGenFramebuffersEXT( 1, &FboID ); glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, FboID ); // Create 2 textures for input/output. glGenTextures( 2, TexID ); for( int i=0; i<2; i++ ) { glBindTexture( GL_TEXTURE_2D, TexID[i] ); glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR ); glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR ); glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE ); glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE ); // RGBA8 buffer glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, W, H, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL ); if( _hasMipmapping ) glGenerateMipmapEXT( GL_TEXTURE_2D ); } // Now attach textures to FBO int src = CurrActiveBuffer; int dest = 1-CurrActiveBuffer; glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, TexID[src], 0 ); glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, TexID[dest], 0 ); ); // // Mainloop // int src = CurrActiveBuffer; int dest = 1-CurrActiveBuffer; FBO.Bind(); glDrawBuffer( dest ); glBindTexture( GL_TEXTURE_2D, TexID[src] ); ShaderProgram.SetTextureUniform( 0 ); RenderScene(); FBO.Unbind(); // Swap back and front buffers (read becomes write and vice-versa) CurrActiveBuffer = 1-CurrActiveBuffer; // CurrActiveBuffer ? 0 : 1;
Why would you want to ping-pong? Well for instance imagine you are doing a water effect in the gpu. You’ll need to access data from your previous buffer right? Using the CPU that would be trivial as you have the last frame’s memory buffer allocated somewhere which you can read/write access directly. That doesn’t really work on the gpu side that way (but we’re getting closer with CL, CUDA, DC)
Have fun.
, Next