[00:02:48][Adding acceleration and taking it into account to compute new positions]
[00:06:27][Bouncing particles off the ground]
[00:09:56][Modeling loss of energy]
[00:14:00][We want our fountain to be more fountain-like]
[00:19:54][Writing special-purpose code to achieve the desired behavior]
[00:29:30][Considering the interactions among particles instead of simulating particles in isolation]
[00:30:41][Two raw categories of physics simulations: Eulerian and Lagrangian methods]
[00:31:25][Lagrangian: Simulation of the motion of particles through space]
[00:32:49][Eulerian: Simulation of density and mean velocity of particles at specific locations in space]
[00:36:01][Lagrangian methods are bad at handling density]
[00:36:40][Eulerian methods don't keep track of the properties of individual particles]
[00:37:46][We'll resort to a mixed Eulerian-Lagrangian method]
[00:38:45][We could use the density gradient from an Eulerian representation to compute the horizontal push of particles in the Lagrangian representation]
[00:42:57][Let's implement it]
[00:50:57][Drawing the density field]
[01:00:03][Dispersing particles taking into account cell density]
[01:03:25][Discussion of possible improvements to the simulation]
[01:04:00][Taking advantage of the density gradient to achieve better results]
[01:08:00][We still don't use the mean velocity of particles inside each cell]
[01:09:18][@andsz_][I suppose adding some friction to dP.x might help]
[01:10:41][@braincruser][Try reducing the size of the individual cells]
[01:13:23][@quikligames][The back of the head would make a better particle than the side of the head]
[01:16:24][@pseudonym73][If you're going to alter the GridScale, you probably need to scale Dc by it too.]
[01:17:02][@ezioauditorerevs][Did you ever add a way to tell the music to shut off or did you just disabled it?]
[01:17:22][@culver_fly][What would happen if the particles were spawned between two cells? Would that cause an effect where everything would just not bounce off each other anymore?]
[01:17:54][@mr4thdimention][On API design: You recently emphasized "Write the usage code first" and then the implementation later. While compression oriented programming is about writing code first and then compressing it, pulling code into functions where necessary, allowing the API to evolve out of that process. They seem like two contradictory methods. Are they? How do you decide when you're using one or the other?]
[01:22:58][@starchypancakes][Would it be possible to split the fluid computation across two frames. Like use the first frame to accumulate velocity and momentum changes and the second one to resolve them?]
[01:23:42][@ezioauditorerevs][Does the size of the grid relative to each particle matter much?]
[01:24:30][@culver_fly][(Referring to Q at 01:17:22) Say you're deciding whether to bounce the particles off based on the density now, then if the particles were spawned between 2 cells, wouldn't the density be halved and not bounce off anymore?]
[01:26:22][@spaceghost2345][Would simulated annealing work for this issue?]
[01:26:36][@noxy_key][Doesn't writing usage code first imply simplicity in API calls? Doesn't this box you in when trying to create persistent things on the stack? All complex initializations for persistent objects have to be done somewhere. If done on the stack, how do you persist complex data structs without using static?]
[01:27:46][@braincruser][Current simulation is in pixel space?]
