Live data from Hacker News

Simulating fluids, fire, and smoke in real-time

andrewkchan.dev

131–140 of 174 posts

Re: Simulating fluids, fire, and smoke in real-time

#131
post #112

Earlier quoted context omitted.

Maybe you're not the right person to ask, but I'll go anyway: I would like to learn the basics of CFD not because I expect to do much CFD in life, but because I believe the stuff I would have to learn in order to be able to understand CFD are very useful in other domains. The problem is my analysis is very weak. My knowledge about linear algebra, differential equations, numerical methods, and so on is approximately l…

Try this book: https://www.sciencedirect.com/book/9780750665940/numerical-c... Or, via an amazon link: https://www.amazon.com/Numerical-Computation-Internal-Extern...

This does look really good at a first glance. It seems like it uses mathematics that I'm not fully comfortable with yet -- but also takes a slow and intuitive enough approach that I may be able to infer the missing knowledge with some effort. I'll give it a shot! Big thanks.

Re: Simulating fluids, fire, and smoke in real-time

#132
post #117
post #112

Earlier quoted context omitted.

Maybe you're not the right person to ask, but I'll go anyway: I would like to learn the basics of CFD not because I expect to do much CFD in life, but because I believe the stuff I would have to learn in order to be able to understand CFD are very useful in other domains. The problem is my analysis is very weak. My knowledge about linear algebra, differential equations, numerical methods, and so on is approximately l…

You'll be able to understand the equations I guess. The hard part is the numerical analysis: how do you prove your computations will: 1/ reach a solution (badly managed computations will diverge and never reach any solution) 2/ reach a solution that is close to reality ? For me that's the hard part (which I still don't get). You could start with Saint Venant equations, although they look complicated they're actually…

Understand the equations, yes. However, I'm sufficiently out of practise that it takes me a lot of effort to. So I guess you could say I'm not fluent to be able to grasp the meaning of these things as fast as I think I would need to in order to properly understand them.

Re: Simulating fluids, fire, and smoke in real-time

#133

Earlier quoted context omitted.

> Something I’ve never understood, if these effects are to run in a game, isn’t the GPU already busy? Short answer: No, it's not "already busy". GPU's are so powerful now that you can do physics, fancy render passes, fluid sims, "Game AI" unit pathing, and more, at 100+ FPS. Long answer: You have a "frame budget" which is the amount of time between rendering the super fast "slide show" of frames at 60+ FPS. This give…

> No one is using the iGPU for anything. It's completely ignored because it's usually completely useless compared to your main discrete GPU. Modern iGPUs are actually quite powerful is my understanding. I think the reason no one does this is that the software model isn’t actually there/standardized/able to work cross vendor since the iGPU and the discrete card are going to be different vendors typically. There’s also…

It still annoys me how badly AMD botched their Fusion/HSA concept, leading igpus to be completely ignored in most cases.

Re: Simulating fluids, fire, and smoke in real-time

#134

Earlier quoted context omitted.

Rayteacing doesn't simulate light, it simulates a very primitive idea of light. There's no diffraction, no interference patterns. You can't simulate the double-slit experiment in a game engine, unless you explicitly program it. Our universe has a surprising amount of detail. We can't even simulate the simplest molecular interactions fully. Even a collision of two hydrogen atoms is too hard - time resolution and space…

I wanted to make a dry joke about renderers supporting the double slit experiment, but in a sense you beat me to it.

There sure has been a lot of slits simulated in Blender.

Re: Simulating fluids, fire, and smoke in real-time

#135

They mention simulating fire and smoke for games, and doing fluid simulations on the GPU. Something I’ve never understood, if these effects are to run in a game, isn’t the GPU already busy? It seems like running a CFD problem and rendering at the same time is a lot. Can this stuff run on an iGPU while the dGPU is doing more rendering-related tasks? Or are iGPUs just too weak, better to fall all the way down to the CP…

> Something I’ve never understood, if these effects are to run in a game, isn’t the GPU already busy? Short answer: No, it's not "already busy". GPU's are so powerful now that you can do physics, fancy render passes, fluid sims, "Game AI" unit pathing, and more, at 100+ FPS. Long answer: You have a "frame budget" which is the amount of time between rendering the super fast "slide show" of frames at 60+ FPS. This give…

I actually have my desktop AMD iGPU enabled despite using a discrete Nvidia card. I use the iGPU to do AI noise reduction for my mic in voice and video calls. I'm not sure if this is really an ideal setup, having both GPUs enabled with both driver packages installed (as compared to just running Nvidias noise reduction on the dGPU, I guess,) but it seems to all work with no issue. The onboard HDMI can even be used at the same time as the discrete cards monitor ports.

Re: Simulating fluids, fire, and smoke in real-time

#136
post #102

Earlier quoted context omitted.

I think the curl noise paper is from 2007: https://www.cs.ubc.ca/~rbridson/docs/bridson-siggraph2007-cu... I've used the basic idea from that paper to make a surprisingly decent program to create gas-giant planet textures: https://github.com/smcameron/gaseous-giganticus

Hey that paper references me. ;) I published basic curl noise a few years before that in a Siggraph course with Joe Kniss. Bridson’s very cool paper makes curl noise much more controllable by adding the ability to insert and design boundary conditions, in order words, you can “paint” the noise field and put objects into the noise field and have particles advect around them. Mine and Joe’s version was a turbulence fie…

> the simplex noise code for a minute and it looks gnarly, maybe more expensive than Perlin even?

In 2014 when I wrote it, 3D Perlin noise was still patent encumbered. Luckily at the same time I was working on it, reddit user KdotJPG posted a Java implementation of his Open Simplex noise algorithm on r/proceduralgeneration (different than Ken Perlin's Simplex noise), and I ported that to C. But yeah, I think Perlin is a little faster to compute. I think the patent expired just last year.

Also Jan Wedekind recently implemented something pretty similar to gaseous-giganticus, except instead of doing it on the CPU like I did, managed to get it onto the GPU, described here: https://www.wedesoft.de/software/2023/03/20/procedural-globa...

Re: Simulating fluids, fire, and smoke in real-time

#137
post #48

Earlier quoted context omitted.

> Guess the requirements in computer graphics are more inclined towards making something that looks right instead of getting the physics right. The first rule of real-time computer graphics has essentially always been "Cheat as much as you can get away with (and usually, even if you can't)." Also, it doesn't even have to look right , it just has to look cool! =)

Why not cheat? I'm not looking for realism in games, I'm looking for escapism and to have fun.

The reason not to cheat is that visual artifacts and bugs can snap you out of immersion. Think of realizing that you don't appear in a mirror or that throwing a torch into a dark corner doesn't light it up. Even without "bugs" people tend to find more beautiful and accurate things more immersive. So if you want escapism, graphics that match the physics that you are used to day-to-day can help you forget that you are in a simulation.

The reason to cheat is that we currently don't have the hardware or software techniques to physically simulate a virtual world in real-time.

Re: Simulating fluids, fire, and smoke in real-time

#138
post #50

Earlier quoted context omitted.

Heck, the Wii had Fluidity around the same time period (2010), and that's a lot weaker than the PS3. Fluidity was pretty neat—you played as a volume of water, changing states as you moved through a level that looked like a classic science textbook: https://youtu.be/j7IooyXp3Pc?si=E79rCrq2mdyZSKoF&t=120

Well, technically yes. Both use the same technique: Smoothed Particle Hydrodynamics. But the PS3 was able to fill the whole screen with these particles. Hundreds of them. The game Fluidity seems to have approx. 20.

> The game Fluidity seems to have approx. 20.

It had more than 20, but... not by much.

Post reply on HN