Another bug bites the dust...

I meant to do a post about this yesterday (and another one on it a while back), but with all the finals stuff it kept slipping my mind (and also it seemed hardly too exciting).

After fixing the "particles explode" bug, Christine and I noticed that there was something still wrong with our water particle behavior - namely, that given enough time the particles would always compress down to the floor of the MACGrid. I've been trying to solve this final bug with the particle motion while Christine's been tackling level sets, and yesterday I finally figured it out. We have a function we named "constrain velocities" that sets velocities to zero on the boundaries of the MACGrid. We have it in our simulation in a place based on where we'd seen it in our notes, particularly in "Fluid Flow for the Rest of Us". As it turns out, though, we needed to run that step each time we modified our velocities (meaning after the advection AND projection steps), which in hindsight makes a lot of sense.

Not as exciting as Christine's update about working level sets (hooray!), but progress nonetheless. I've begun doing our final writeup as Christine finishes going over our level sets. This project is due tomorrow, but it seems as though we might finish...!

Marching Cubes ish

I've been working on implementing marching cubes and I've made some progress...It seems to be drawing the triangles semi correctly but I think our particles are not being distributed properly. Also, I can't figure out how to tell it to draw the sides since they're out of bounds... Here's a couple videos (particles aren't being drawn to size)

Sphere

 

Sphere with particles

 

Faucet

En route to level sets?

Soo I've been reading pretty much every document about level sets published online trying to make sense of it all because math is not my thing, and finally I decided to actually start writing code. I had been confusing myself with the 100 different ways that people do level sets, but I seem to have made some progress. I have cell centers drawn as yellow if they have a positive signed distance and pink if it's negative. I want to do narrow banding next, and tomorrow we're going to start investigating marching cubes. I haven't gotten a screen capturing software yet and we haven't worked out the frame rendering, so I made two super makeshift "animations". You get the idea though.... I threw in a couple stills afterwards as well since they're actually probably better to look at. As always, it's a work in progress. I'm just super happy we figured out the blowing up for the most part (Yay Jason! Stupid AMatrix...)

And Again!

I really don't know where these breakthroughs come from.

Literally over a week of trying to debug, and then three little lines after 20 minutes of code exploration fix everything.

I was going after our problem of "liquid sim explodes after a while," figuring that "code doesn't reset properly" could take a backseat for now. It's only after I gave up in frustration and took a stab at the reset thing that I was able to make any progress. Fixing the reset thing took under half and hour, and by doing so I ended up fixing both problems. Ugh.

Here's some video of a water sphere and a "faucet" running (in real time - not recorded). Maybe not the most elegant thing ever, but... Looks good to me! Feels pretty good, too.

 

The next step (I assume) is joining Christine on level sets and maybe then adding on some bells and whistles to the finished product. Though to be honest, with this little time left and finals starting up tomorrow, I'll be grateful if we get the level sets working properly in time.

That's all for now,

Jason

Where We Stand

Hi,

So here's where we are now:

We discovered that dynamic cell resizing actually still works, and solved a small problem where we thought my updated code didn't work on Christine's computer (turns out it did). We realized that we weren't extrapolating velocities in the Z direction yet (as our early tests were in 2D and we just recently switched over to 3D) and we fixed that as well.

We have two main problems now.

The first is that, after a while, the particles stop behaving like water and simply explode (I've included a video below).

The strange thing about this is that oftentimes the PCG stops converging at the moment of impact with the ground, but the simulator will continue running like water for a good while afterwards before exploding. However, when we use a smaller number of particles (say 3) spaced out a good distance from each other, the PCGs always converge and the particles eventually come to a stop (as expected). The more particles we use, the faster the sim explodes (faucet gives us only a few moments of behaving properly). We think there's a few things that could be happening here:

1. Overlapping particles are causing insane, impossible pressures, causing the velocities to explode (Karl notified us of this one - he said the same thing had happened in his sim when they initialized particles in the same place). It would explain why the more particles there are the faster the simulation explodes, as more particles means higher probability of a collision.
2. There could be weird boundary conditions we're neglecting. There seems to be something strange going on with ground plane collisions, even when everything is converging properly and we're only using a few particles. Theoretically, the pressures should eventually cause all the velocities to go back to 0 (I'm assuming - I can't find confirmation of this), which is not happening even in the few particle case.
3. Memory issues. We don't have specific cause to believe this past "more particles = faster explosion", but I think we're both always suspicious of memory issues.

Our other problem, and the one we're really confused by, is that resetting the sim gets different results. Right now if we run the sphere sim twice then the first time it gets accurate results (then explodes) and the second time we get slightly less accurate results (it seems almost viscous, despite our having not implemented viscosity, and the motion is a bit off) but it also takes slightly longer to blow up. Even when we use only one particle, velocities of the sim come out different in the reset run. We don't know what the issue could be... We reset absolutely everything when "reset" is called. This will require a lot more debugging.

Since we know we need to try to implement level sets now, we've decided to start dividing up our labor (up until now it's been "let's both try and figure out what's going wrong"). I'm going to try to debug our current code over this weekend, and hopefully figure things out by Monday (I'm not entirely optimistic). Meanwhile, Christine has agreed to start looking at level sets and maybe start an implementation by that time as well. We'll see how it goes!

-Jason

P.S. If anyone reading this has any idea what the nature of our problems might be, please let us know!

And so it came to pass! (aka Finally!)

Wow. This feels like it's been a long time coming.

First of all, credit goes to Christine for not only being the one to realize we were setting up our A-Matrix wrong, but for essentially rewriting the linear algebra code from our smoke sims on a fundamental level to make things work (even if we ultimately don't use it). Also thanks to Joe, for confirming the theory I'd had (and dismissed) that we should be able to use the linear algebra code from the smoke sims if we just set all the values in rows of non-liquid cells to 0. With that in mind, I was able to go back into the code and pull this together:

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

 

You'll probably notice (of course) that not long after it hits the ground, the water... er... explodes, for lack of a better word. We're still working on that - after a certain point our PCG solver stops converging, resulting in insane, impossible pressures getting applied to the velocities and making the sim go crazy. We'll hopefully work out that bug soon.

Still, the main code clearly behaves as it's supposed to (up to a point), so the hardest part is (hopefully) behind us!

Here's a list of things we still need to do:

• Fix our "does not converge" error so that the liquid stops behaving erratically.
• Figure out the reason why resetting the simulation leads to more does not converge errors, and a difference in fluid behavior all around (less accurate on each "reset").
• Allow for dynamic cell sizes. After a quick test, I've discovered that somewhere in our code we stopped being able to handle it if the cell size is not 1.
• Level sets. We received feedback from our alpha (generally positive despite lack of working fluid simulation - thanks, Joe!) that said we really need level sets for our final project. So as soon as the bugs are ironed out of this one, that's likely the first thing we'll be tackling.

I'll update soon with more videos with cool stuff like larger cell sizes and different ways of initializing water (rectangular prisms, larger spheres, and a continuous water flow we call the "faucet") once we iron out a few of these errors.

Thanks for everything!

More debug progress!

So, after debugging and debugging for days, Jason and I have finally found the (hopefully) real root of our problems... we were setting up the linear system that needs to be solved to make the fluid cells divergence free completely wrong. We didn't adjust the setup from the setup of the smoke system and we've realized after some help from this paper that we need to completely alter our function setUpAMatrix(). We've figured the dimensions of our square matrix should actually be the number of cells that contain liquid, and there doesn't actually need to be a row and column for every cell in the MAC Grid as with the smoke simulation. So, we're going to have to change the implementation for our sparse matrix and pcg solver.

On a side note, while working on our Alpha Review we've realized our previous 3 step approach was completely out of order (we thought steps that came later came earlier and vice versa) so we are re-organizing our whole game plan. It's going to be a long night/couple of weeks but at least now we've figured out the main issue.

Fixed a few bugs

After a couple days of debugging, yesterday we had a mini breakthrough and realized that we had been advecting velocities/projecting with the wrong faces! And our bounds checking was a bit off as well. The particles now fall to the ground ( but the velocities explode once they get there...). Progress!

What I've Been Doing For Two Days

I'm no good at blogging, so here's a quick breakdown:

• Implemented a new graphical display. I started out by coloring cells in blue that contained liquid particles, but that display method got buggy fast (and was admittedly pretty ugly). I ended up switching out the cell method with just drawing all our particles as points (in semi-transparent blue). I experimented with rendering points as spheres, but it had the same relative effect and (for some reason) it was hard for me to get the spheres to show up in their proper positions (I left that code commented out in case we ever choose to switch back to a particle implementation). I find it easier to debug and figure out what's going wrong when there's some kind of visual involved, so that's been helpful so far.
•  I rewrote advect velocities and projection so that they no longer compute velocities for any cells that don't contain particles. For a while this yielded decent (though flawed) results. Once I finished, we had our three sample particles drawing at the correct point in space before slowly drifting apart from each other in the x-direction - behavior that we actually expected since we haven't yet implemented velocity extrapolation (as we found in the Batty notes)
• I implemented velocity extrapolation, but realized after it failed that I calculated per cell instead of per face, meaning the velocities of each point were off by about one position in each direction and, in some cases, were not even being calculated. Unfortunately I didn't have time to debug this before handing it back to Christine, since I have more work I need to get done soon...
• I debugged a lot of our existing code. There was a lot of debugging to do.

Liquid cells rendered as Tetris blocks

Liquid particles rendered as particles.

My hopes are that we have a VERY basic liquid sim working in at LEAST two dimensions by alpha time. As we've done more reading and actually started programming, it's become clear to both of us (I think) that what we are aiming to do won't exactly be doable the way we meant to achieve it. There are certain things we'll likely be leaving out of our initial intended implementation (level sets come to mind), while adding more things for realistic liquid simulation (viscosity, surface tension, etc). There's obviously still a lot we can do - interaction with solids, continuous water sources, free bodies of water particles, etc. - but for now I think we're going to focus on getting this smoke sim simulating water proper.

First Steps

Sooo we decided we needed to change how we were doing things a little bit! After more reading (we read through Dr. Christopher Batty's notes found at http://www.cs.columbia.edu/%7Ebatty/teaching/general/Fluids2.pdf and looked over his base code for a liquid sim ) we realized we needed to implement marker particles before we did anything else (like level sets...). So this weekend I added a vector<vec3> that holds the locations of the particles that will mark the location of the liquid and functionality that advects their positions according to the velocity field of the grid.   I also added two vectors of booleans for tagging that hold whether a given cell is empty/not empty and solid/not solid. When the positions of the particles are advected, the cell that the given particle is in is tagged as "not empty". I've also added a function for initializing the particles' positions and for right now we are just manually placing them. For the future I'm concerned that the bounds checking that I'm doing when we advect the particles is too simple (it's just check their locations against the dimensions of the grid*cell size) because it's not generalizable to other shaped containers. I hit some strange value initialization issues last night that I think might be a scoping mistake, but I handed it off to Jason (who is traveling back home as we speak)!

Happy Holidays! Animation played a major role in my religious holiday education so here's some tidbits for you:

The Adventure Begins!

Final Project time for Physics based animation! We're extending our smoke simulation from Assignment 2 to do a water simulation with a semi-langrangian approach, because we think water's pretty cool. Here's our rough timeline:

• This Weekend: Get familiar with the base code (Jason's) and strip it of the smoke specific-parts
• By Saturday April 7th: Have our individual parts completed (Jason is doing velocity extrapolation and surface tension, I (Christine) am doing level sets). 
• Monday April 9th: Combine our parts to make a working 2D water simulation
• Friday April 13th : Mid-Review Day. We are going to do our best to have our sim in 3D by this day, but it may take the weekend after.
• Monday April 16th: It will definitely be in 3D by this day!
• May 7th: Final Project due!

We will spend the weeks between April 16th and May 7th making it awesome and more interesting, but the breakdown of those goals are TBD at a later time, depending on where the project takes us. Right now we are considering implementing viscosity for simulating thicker fluids and also creating different types of sources for the liquids (pouring water , dropping water volumes, etc.)

Here are some videos that have inspired us (we could watch these things for hours!) :

Here we go!