Progress!

Well, after midterms and some other tough schoolwork, we've finally made some progress on DroidViz.

Most notably, the vector fields are now rendering in fullscreen. In the fluidsolver project referenced earlier, the window's bottom corner is (1,1) and the top opposite corner is (0,0). For some reason, the default window size in GLES on the android is from -1 to 1, with (0,0) directly in the center of the window. After adjusting our calculations, we now have things rendering in fullscreen.

Most importantly, the code in svn now compiles and runs. We were running this code in a separate project hosted elsewhere until we could get our stuff together. I've just spent the last few hours cleaning up the Google Code SVN, formatting code, porting stuff, etc. Things are finally current on the SVN. Feel free to check it out if you want.

Most exciting, Google has just released the NDK, revision 3. With this release, we now have access to OpenGL ES 2.0, and with that - FRAGMENT AND VERTEX SHADERS. OMFG. We'll be able to make droidViz DROP DEAD GORGEOUS. We're pretty psyched here, so we'll be spending more time on development to get this out sooner than later.

Keep it real,

-Griff

F*** YEAH SEAKING

Well, we finally have something interesting rendering!

We are running un-optimized fluid code (read: using floating point numbers (eew) ) on the android, and we're able to render a simple vector field. YAY!

The changes needed for Jos Stam's code were simple. Instead of using GL in immediate mode, we needed to give GL ES a vertex array and tell it how many entries within this vertex array to render.

CODE:

static void draw_velocity ( void )

{

int i, j, k;

float x, y, h;

h = 1.0f/N;

// This Disable Client State is not needed every frame. (OPTIMIZATION)

glDisableClientState( GL_COLOR_ARRAY );

glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f );

glLineWidth ( 1.0f );

// An index for the vertex array

k = 0;

// Update the vert array

for ( i=1 ; i<=N ; i++ ) {

x = (i-0.5f)*h;

for ( j=1 ; j<=N ; j++ ) {

y = (j-0.5f)*h;

line_verts[k++] = x;

line_verts[k++] = y;

line_verts[k++] = x+u[IX(i,j)];

line_verts[k++] = y+v[IX(i,j)];

}

}

// Draw the new array

glVertexPointer( 2, GL_FLOAT, 0, line_verts );

glDrawArrays( GL_LINES, 0, ( N * N * 4 ) );

}

Because input will be coming from the touch screen, we need to figure out how to handle this at the NDK level, or simply pass it in to the NDK level from the Java level. Currently, we're just setting the input variables at compile time. This is producing good results.

Unfortunately, the algorithm is not stable. I blame the floating point numbers, but this remains to be seen. We'll be investigating in deeper detail later.

This code will be uploaded to SVN within a day or two (intermittent internet connection problems ahoy...)

-Griff

Fluid Dynamics

Hey guys,

So: Fluid dynamics. GO!

We found a paper by Jos Stam on Fluid Dynamics for Games. The paper can be found here: http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf

The paper describes an easy to implement, yet optimized and fast fluid solver for applications in games. The solver can be witnessed in action performing the visuals and gameplay for a game called "Plasma Pong", viewable here:

http://www.youtube.com/watch?v=VvvpyMeZmQc

Not only this, but the source code has been posted for the fluid solver on his personal website:

http://www.dgp.toronto.edu/~stam/reality/Research/pub.html

The paper also describes how to implement fixed-point operations for optimizations on ARM platforms. Wow. It seems that someone is on our side here.

No reason to reinvent the wheel folks! We plan to work these projects into droidviz. We should have a working demo (scaled down) of the fluid solver implemented in JNI by the end of next week. After this, we'll move on to post processing and particles.

I'll be posting some documentation about how the library will interface with the application at the JNI level soon. More documentation to come this following week. YAY SPRING BREAK!

-Griff

Scope of the Project

Hello all,

I was writing an API and Implementation document today, and I started to look critically at the scope of the project.

Milkdrop is a wonderful visualizer - which plugs into Winamp. It has a simple preset and scripting engine which allows users to create wonderful looking visualizations using information about the music currently playing on a sample per sample basis. The automation of the Milkdrop visualizations is driven by the incoming samples.

It'd be really great to do this for droidViz - but it appears that it'll be a bit out of the scope of the project. See, Android uses the OpenCore libraries to decode all supported music types to PCM data which is then piped to the audio core. Unfortunately, this library is not exposed at the application level, thus making it impossible for us to utilize. In order to do something similar, we would need to integrate about 10 codecs at the native level and decode the audio to PCM to feed to our visualizer engine, then find a way to port this PCM data to the Audio core - probably using AudioTrack. Unfortunately, this is a bit out of the scope of the project.

We'll be making droidViz a purely graphical library - which will allow users to create interesting visuals with or without PCM data - simply by manipulating functions at the Java level. If the user implements some sort of audio codec and pulls PCM data and uses that to drive visualizations, good for him - but that's not what droidViz is going to do automatically for you.

That said, we'd really like to see this happen in the future. Perhaps, once the OpenCore libraries are exposed at the application level, we can implement this easily. We'll be planning around this possible addition throughout the development of the project.

Next up - the API/Implementation documents.

-Griff

droidviz

FIRST!

This is the first post on the droidviz blog. We're working toward an open source visualization engine for the Android platform (think milkdrop).

We're currently in the planning phase of the engine. The project has just started, and we're all psyched to see what the Android platform is capable of.

Stay with us as we start commits.

Code: http://code.google.com/p/droidviz/

Thanks to Sean O'Sullivan and the Rensselaer Consortium for Open Source Software!

-Griff