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