Order to Chaos

We’re all getting settled in here at FIEA. We’ve been here for a few months and things are becoming more routine; and by routine I mean most of the time we are going through the same motions but usually in different ways. The standard has become class, projects, and improv. However the professors have ways of throwing a wrench into the gears. On occasion they will call for status reports earlier than expected to see how well the group knows the project they have spent the past week or more working on. On other occasions they will mix things up completely and change the entire objective. These are things that WILL occur in the industry, and are vital tools to learn in a real-world environment.

Too many students are used to procrastination (myself included). At FIEA we’ve learned quickly that a day wasted directly reflects on the quality of the product. Whether the aforementioned product is the project you’re working on, your grade, or your reputation.

Fluid simulation, Atari 2600 programming

Fluid simulation update

I added more features to my fluid simulation. Follow the links to see movies:

• Fast approximate far-field interactions
  
• Semi-lagrangian simulation for comparison
  
• Brute-force O(N^2) vorton simulation for comparison
  
• Other visualization modes (still preliminary)
  
• Objects affect the fluid
  

I also submitted an abstract to GDC for 2008.

Atari 2600 Programming

I collect Atari games, consoles, controllers and other Atari-branded stuff from the 1970's and 1980's. I'm also beginning to program the 2600. Its CPU is a 6507 which has the same instruction set as the 6502 but has fewer address pins. Many computers from that era used the 6502 including other Atari consoles and computers (5200, 7800, 400, 800, etc.), Commodore computers and the original Nintendo (NES). It's the first CPU for which I learned assembly programming. The Atari retro development community is quite active and even now, around 30 years following its release, people continue to pioneer new ways to get more out of that console, e.g. higher image resolution. Each year at the Classic Gaming Expo people release several new games for the Atari 2600, and they usually sell out immediately.

I recently obtained a collection of EPROMs (which currently have Atari games burned onto them) and 2 modified Atari 2600 cartridges with ZIF sockets that fit these EPROMs. I put the chips into a conductive plastic container I got from Skycraft Surplus for $2. This gives the appearance I'm engaging in industrial espionage.

Programming is where it's at!

Wow, are we really starting our 7th week? It seems like we've just begun, yet we've already done so much. We've finished our first two rounds of prototypes, and I was very pleased with the work both of my teams did. Those were written in Flash and Actionscript, and several very interesting games came out of those two-week rounds. Now we are starting on our 3D prototypes using Panda and Pyton, and again we have just 2 weeks to create a game - this time focusing on story. Of course, that's not all we are doing. The programmers are working on some very involved C programs (after doing a few tough assembly programs - whew!), the artists are all designing/texturing/animating character models in Maya, and the producers are, well, producing. I can pick on the producers because I originally came into the program as a producer (a technical producer as you may hear them called). But after sitting in on the programming classes and realizing I didn't have a good answer for "What does a producer do?", I decided to switch tracks. And don't let "Sir Charles" (or Chuck as we like to call him) fool you. The job of a producer is not that sexy. The real sexy jobs are held by programmers. Don't believe me? Just take a gander at Dr. Gourlay's blog on "Fluid-like Simulation". Very Sexy!

But we already knew that. What I have learned is that you really have to prioritize here. In undergrad, prioritizing just meant figuring out what you could put off, and what you couldn't. But here, you are working with teams that depend on you. And frequently you are working on different teams at the same time. Should I work on my programming assignment right now? What about my prototype team that needs me to write code for our game? And how's my development plan team coming along? Of course, the other team members on each team are also juggling assignments and teams, so getting everyone to do what you need when you need it means we all have to do a little "producing" of our own.

Fluid-like simulation (preliminary)

Existing fluid simulations based on solving the Navier-Stokes equations or its derivatives are slow algorithms. For games, we need something faster, perhaps at the cost of quantitative realism.

I aim to invent a simulation algorithm to satisfy these requirements:

• Fast; must run in real-time
• Scalable; i.e. O(N) or better
• Qualitatively similar to real fluids
• Simple to implement and modify
• 3D
• Interacts with other entities
• Multiple immiscible fluids (e.g. water and air, including surface rendering)
• Combustion

I will use an ad-hoc simulation using something akin to point vortices that interact with their nearest neighbors .

You can get more info from my website: http://www.fiea.ucf.edu/~mgourlay/Fluid/

Earlier this week I managed to create some preliminary results of a fluid-like simulation of something like a vortex ring moving through something like a fluid, including these features:

• Nearest neighbor tracking
• Particle rendering
• Particle interaction

These simulations share in common with real fluids vortex self-advection due to nearest neighbors and vortex diffusion. Mathematically these properties differ from those of real fluids but qualitatively this simulation has those properties. As you can see from the simulations, the vortex ring does indeed propagate as you would expect from such a ring in a real fluid. The aggregate speed is probably wrong though.

These preliminary simulations lack a number of features present in actual fluid dynamics, including vortex stretching and tilting (important for cascading from laminar to turbulent flow), no-slip boundary conditions (necessary for generation of vorticity such as generating wakes and lift) and potential (i.e. irrotational) flow (necessary for bulk fluid motions such as occurs in shear flow far from the shear layer itself). The simulation code currently includes propagating long-range interactions. I intend to add the other features soon.

You can find some movies and more details here:

http://www.fiea.ucf.edu/~mgourlay/Fluid/2007sep17/