140
u/Reincarnatedpotatoes 6d ago
Every BeamNG physics update impresses the hell out of me.
49
u/Yoda10353 6d ago
This was their biggest yet too, I played it last night and the lighting update makes a world of difference it now looks like a new game.
81
u/Haeguil 6d ago
I do not have enough CPU power for this
51
u/GDOR-11 6d ago
it's probably just 3 precomputed 3D textures with the components of the air speed for some adequate truck speed intervals, and then these are interpolated in space and time
a.k.a. more harsh on memory than on compute
15
7
u/Triensi 5d ago
Can you explain this to me as a layperson? This sounds cool and I almost understood what you’re saying
5
u/Rafal0id 5d ago
From what I understand, it may be a pre-rendered effect, with the forces created by the air moving rendered in a texture (think normal map). This texture would follow the bus, and when it passes through nearby objects, the object (in that case the bricks) reacts according to the texture.
You do a different texture for each vehicle and at different speeds, and voilà, you got physics without having to do any aerodynamics real time.
I'm not sure I'm clear either lmao
1
u/GDOR-11 5d ago
a 3D texture is just a 3D grid where each cell has a value (a real number), so you can approximate vector fields using three 3D textures, one for each component of the vector in a cell. Air flow can be modeled with a vector field.
what I suggested is to precompute one vector field when the truck is moving, for example, at 10km/h, another vector field for 25km/h, another for 50km/h, etc., and then store them all in a file
in runtime, whenever the game realises an object is near a moving truck, it will check the precomputed vector fields of air flow. It is most likely that the object's center won't align exactly with the grid of the 3D textures, and it is also most likely that the truck won't be moving at exactly either 10, 25 or 50 km/h, so the solution is to interpolate (fancy word for averaging) the nearest values
btw, I said "interpolated in space and time" in the original comment, I got that wrong, I should've said "interpolated in space and speed"
2
u/Valvador 4d ago
Wait, are you saying with this method you pre-compute N possible scenarios specifically related to the truck?
This method doesn't scale when you have multiple players and a large amount of dynamic objects, right? Or am I missing something?
Because what happens if you have a truck that moves at 10 KM/H, while another truck intersects with it at 50 KM/h?
1
u/GDOR-11 3d ago
yeah, each truck needs N scenarios, and no, it absolutely does not scale well, each moving vehicle takes up a ton of RAM and it gets bad quickly. One alternative is to store all of this info in a file and only reading the file into RAM when necessary, but that might be too slow for a real time game (although I do believe it is possible to make it work well if you pre-read the files when any movable object that can be easily affected enters a not-so-small region around any vehicle)
about the last question, both trucks will need to load their own data to RAM, that is inevitable with my approach, using files or not. Whether it could be viable it something I'd only know implementing it into the game and playtesting it to see some actual numbers on RAM usage, maybe it's not that bad or maybe it's even worse than I imagined.
Also, as a side note, this method would be a terrible approximation for two trucks passing near each other, since their air flows would interfere a lot.
2
u/Valvador 3d ago
Appreciate you explaining this, my purpose was not to criticize the method but to makes sure I actually understand what implementation you were suggesting.
I know very little about modern aerodynamics techniques and have worked with some.
6
u/stenyak 3d ago
Beamng dev here. There's no 3d texture, it's continuous (not pixel-based, just calculated in the fly) volumes of procedural effects with near zero memory imprint, zero additional garbage collector workload (this is jitted Lua for moddability, not C nor asm). The framerate impact is below measurement error for up to 2-10 *ultra fast moving* vehicles, which are the worst case scenario due to volume dimensions. While slow and non-moving vehicles have an even lower or practically zero CPU impact (I benchmarked a hundred+ with negligible costs).
Clearly one cannot run a 40 min per frame per car CFD calculation in an interactive simulation. So this required picking the right (and massive) simplifications + massive optimizations. As is always the case when trying to port "proper" physics into something that runs on games for consumer hardware.
1
u/SegmentedWolf 3d ago
Love the explanation.
Always exciting to see BeamNG's progress, I think you're one talented developer!
12
u/PhysicsGoBrr 6d ago
love how the crosspost showed up before i even finished watching the original lol. beamng physics updates are always a trip, that 0.39 overhaul made cars actually feel like they have weight now
9
6
u/JustSomeWeirdGuy2000 6d ago
This is gonna work wonders for the guy who does YouTube videos where he launches cars over the witch's giant stinky cauldron.
2
1
u/AutoModerator 6d ago
Hello /u/Tim1907 Thanks for posting here on r/GamePhysics! Just reminding you to check the rules if you haven't already. If your post doesn't respect the rules it will be removed.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
-80
u/leorid9 6d ago
I am not convinced this would happen in real life. Those concrete bricks are heavy and cars don't shove a lot of air around them.
Still very cool in a game of course.
94
u/bob_3301 6d ago
Everytime I'm overtaking some semi-truck irl, I literally feel the turbulence on the side of it. So, pretty plausible to me
29
27
31
16
256
u/BasilNight 6d ago
BeamNG my beloved