Marching Squares -Animation

Here is a link to the Marching Squares of particles. It seems to be slow. After unsuccesfully trying to migrate the marching squares algorithm from linux to windows, it turned out to be that its not slow because of marching squares. probably there is no hardware acceleration in linux, or something wrong in the build process.

Interface Update - Threaded Blob Detection & Messaging

After much ado, I've gotten the message passing, parsing, storing, and displaying running concurrently with video input.

The upside is that this is stable for reasonable sets of blobs. The downside is that this hasn't been optimized yet, so it runs at about 5 fps. This should improve in the next couple of days as I go through and optimize the code for message parsing and storing.

Here is a video of the input from the sending computer alongside the output from the listening computer:

Additional Literature

Here is some recent work related to our task of water representation and rendering.

Surface Creation/Extraction

Most recent method proposed for surface extraction from a particle system.
Real-time particle isosurface extraction

This paper creates a surface from a particle system. It mentions several alternative methods, including splatting, marching cubes, and ray-casting.
Realistic and Interactive Simulation of Rivers
Presentation Slides

Rendering and Textures

Animating water realistically, then applying a non-photorealistic appearance.
A Method for Cartoon-Style Rendering of Liquid Animations

Updating texture information according to fluid flow/advection.
Texturing Fluids

In contrast, this paper generates a new texture for each frame:
A Texture Synthesis Method for Liquid Animations

SPH

Performance analysis of stable fluids, including new speedup methods
Hardware-aware analysis and optimization of stable fluids


Judging from this literature search, some possible research avenues that could be explored as part of this project include animating water in a non-photorealistic style and possibly surface creation.

Marching Squares

An output from the marching squares algorithm for an isovalue of 0.5. The grid values were generated randomly from 0 to 1 (not the particle system).
Should the endpoints of the simplices be triangulated to get a surface ?

-Sundar

Interface Update

I got Processing up and running with a webcam using JMyron and blobDetection. This is a video I took of my fingers with a small LED shining on them in a dark room.


The next step will be to write a small C++ program using the oscpack and listen to messages sent by oscP5 within Processing on another computer.

Particle System Videos

Particle system -> discrete step/toon style texture from velocity magnitudes in an embedded grid.
Right click save-as link to video

Particle system -> heightfield from particle positions collecting in scalar values at embedded grid corners.
Right click save-as link to video

Combining heightfield and toon texture, similar resolutions.
Right click save-as link to video

Continous/non-toon low resolution texture mapped over higher resolution heightfield.
Right click save-as link to video

More pre-visualization - boxfield
Right click save-as link to video

Interface Notes

These notes are from my meeting with Alan Price this afternoon. Major props go out to Alan for doing all the hard work of finding these utilities and sorting through all the bad ones out there.
============================================================

It looks like we'll be using Processing (and its 3rd party libraries) to take care of all the interactive aspects of the project.

We will use the jMyron library to capture the video frames from the webcam resulting in images of the user's contact points (fingers and palms) with the table's surface. Processing will then take these images and find the blob boundaries using the blobDetection library. Once the blob boundaries have been determined, we can send them in message form to a second computer over the network via the OSC communication library. The second computer will be running our C++/OpenGL application with calls to the oscpack C++ library. We will listen for these messages, parse them, and extract the coordinates of all the vertices for each of the blobs.

The big question is: will all this processing burn up too much CPU?

I guess we'll see...

Meeting Notes

Here are my notes from the meeting we had today. Feel free to correct me if I misunderstood something!
============================================================

We decided to get a basic framework up and running by Sunday which will provide the interaction input and the graphics output for the SPH algorithm.

It looks like we'll try marching squares for the surface generation from particle data. Once we get this going we can decide if this algorithm is fast/robust enough to meet our needs. Sundar will adapt his marching cubes code and display it orthographically in OpenGL as a surface.

We are going to throw together a simple particle system (just bouncy particles with initial velocities) and use this as input for the marching squares algorithm. Matt will work on this component as well as investigate possible uses of velocity data for generating convincing animated "ripple textures" for the surface.

Jae is going to get the interface side of things working with processing and blob detection (or possibly touch lib) and output the results of the input video as blob outlines in OpenGL.

We will meet on Sunday (04/13/08) and talk about how things are going with the framework and decide on the next steps to take.

Literature Search

We've been going through the literature and found these papers that seem relevant to our problem:

The classic SPH paper

A sand implementation

SPH on the GPU

Fluids to Solid phase changing

Granular Materials

Fire and Gaseous stuff

Directable Photorealistic Liquids


So far, we haven't come up with a paper that tackles the idea of a fully parameterizable SPH model (running the gamut from smoke to fluids to particulate matter). The last paper listed has come the closest to this.