Interesting. I have 64GB of RAM and yet this page managed to kill the tab entirely.
[deleted]
Simulating fluids, fire, and smoke in real-time
91–100 of 174 posts
Re: Simulating fluids, fire, and smoke in real-time
#92Earlier quoted context omitted.
> 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…
I agree the incentives aren't there. Also agree that it is possible to use the integrated GPU for light tasks, but only light tasks. In the high performance scenarios where there is all three (discrete GPU, integrated GPU, and CPU) and we try and use the integrated GPU alongside the CPU, it often causes thermal throttling on the shared die between iGPU and CPU. This slows the CPU down from executing well, keeping up…
That’s probably a better point as to why it’s not invested in although most games are not CPU bound so thermal throttling wouldn’t apply then as much. I think it’s multiple factors combined.
The render pipelines you refer to are all offline non-realtime rendering though for movies/animation/etc right? Somewhat different UX and problem space than realtime gaming.
Re: Simulating fluids, fire, and smoke in real-time
#93I wrote a super simple flame simulation a long time ago as a toy in C after reading an article somewhere.
You just set each pixel’s brightness to be the average brightness of the immediately adjacent pixels. Calculate from bottom to top.
Add a few “hot” pixels moving back and forth along the bottom and boom, instant fire.
Looks very cool for a tiny amount of code and no calculus. :)
Re: Simulating fluids, fire, and smoke in real-time
#94Earlier quoted context omitted.
“Everything is smoke and mirrors in computer graphics - especially the smoke and mirrors!”
This was the big realization for me when I got into graphics - everything on the screen is a lie, and the gestalt is an even bigger lie. It feels similar to how I would imagine it feels to be a well-informed illusionist - the fun isn’t spoiled for me when seeing how the sausage is made - I just appreciate it on more levels.
Had the same realization that game engines were closer to theater stages than reality after a year of study. The term “scene” should have tipped me off to that fact sooner.
Re: Simulating fluids, fire, and smoke in real-time
#95Earlier quoted context omitted.
Not being a graphics person, is this what hardware ray tracing is, or is that something different?
Even the ray tracing / path tracing is half-fake these days cause it's faster to upscale and interpolate frames with neural nets. But yeah in theory you can simulate light realistically
It’s still a model at the end of the day. Material properties like roughness are approximated with numerical values instead of being physical features.
Also light is REALLY complicated when you get close to a surface. A light simulation that properly handles refraction, diffraction, elastic and inelastic scattering, and anisotropic material properties would be very difficult to build and run. It’s much easier to use material values found from experimental results.
Re: Simulating fluids, fire, and smoke in real-time
#96Earlier quoted context omitted.
“Everything is smoke and mirrors in computer graphics - especially the smoke and mirrors!”
This was the big realization for me when I got into graphics - everything on the screen is a lie, and the gestalt is an even bigger lie. It feels similar to how I would imagine it feels to be a well-informed illusionist - the fun isn’t spoiled for me when seeing how the sausage is made - I just appreciate it on more levels.
My favorite example of the lie-concealed-within-the-lie is the ‘Half-Life Alyx Bottles’ thing.
Like, watch this video: https://www.youtube.com/watch?v=9XWxsJKpYYI
This is a whole story about how the liquids in the bottles ‘isn’t really there’ and how it’s not a ‘real physics simulation’ - all just completely ignoring that none of this is real.
There is a sense in which the bottles in half-life Alyx are ‘fake’ - that they sort of have a magic painting on the outside of them that makes them look like they’re full of liquid and that they’re transparent. But there’s also a sense in which the bottles are real and the world outside them is fake. And another sense in which it’s all just tricks to decide what pixels should be what color 90 times a second.
Re: Simulating fluids, fire, and smoke in real-time
#97I wrote a super simple flame simulation a long time ago as a toy in C after reading an article somewhere. You just set each pixel’s brightness to be the average brightness of the immediately adjacent pixels. Calculate from bottom to top. Add a few “hot” pixels moving back and forth along the bottom and boom, instant fire. Looks very cool for a tiny amount of code and no calculus. :)
Could you share the repo?
Re: Simulating fluids, fire, and smoke in real-time
#98They 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…
Welp. It used to be PhysX math would run on a dedicated gpu of choice. I remember assigning or realising this during the Red Faction game with forever destructing walls. Almost Minecraft, but with rocket launchers on mars
I'm fairly certain red faction didn't use Nvidia physX at all.
Re: Simulating fluids, fire, and smoke in real-time
#99Looks amazing!
Re: Simulating fluids, fire, and smoke in real-time
#100I wrote a super simple flame simulation a long time ago as a toy in C after reading an article somewhere. You just set each pixel’s brightness to be the average brightness of the immediately adjacent pixels. Calculate from bottom to top. Add a few “hot” pixels moving back and forth along the bottom and boom, instant fire. Looks very cool for a tiny amount of code and no calculus. :)
> no calculus
"set each pixel’s brightness to be the average brightness of the immediately adjacent pixels" sounds like a convolution ;)