I know this is not a new suggestion. I found a thread from years ago about this, but of course this forum won't let you bump it, and I'd like to start a new discussion on this. I think all of us could agree more traffic vehicles would be nice. My understanding is that with the current vehicle physics that's not possible, given the complexity of all the vehicle components & their forces interacting with each other which requires a CPU core to run a single vehicle. So why not create a simplified driving model just for traffic AI? It wouldn't apply to chase or fleeing AI, just traffic AI. We don't need traffic AI to run through the same complex physics model as the normal vehicle. Traffic just needs to move believably and countless other games have done that. They can keep their j-beams so crashes with them are realistic, but the driving itself should use a much more simplified model. And to avoid the situation where the simplified model wouldn't be programmed to deal with damage, just have the AI turn off after a crash, just like in real life a driver would usually stay put after a crash. I think this would be a reasonable approach to have BeamNG with denser traffic and still good performance.
I was thinking about this too, how awesome it would be if BeamNG had dense traffic which doesn't kill your performance. The approach I thought is that the cars would have no soft-body physics until you crash into them. It'd have a lot less performace impact with it and the cars could have a sort of LOD to them once they get further from the camera. Also as this being AI traffic it'd be great to see cars parked on the sides, cars parking and leaving the parking spot, being aware of the surroundings stopping on traffic lights and stop signs. When playing games like GTA V I think to myself how amazing it'd be if the traffic on GTA V was in BeamNG.
Something like that but the j-beams would have to be already created and they would be dormant until a crash happens. We wouldn't want to be switching vehicle models at the moment of a crash as that would cause lag. It would be a change in the physics model, where until a crash happens the simplified physics model would be driving the vehicle and this model would take a lot of shortcuts to simulate vehicle motion to minimize the load on the CPU.
What if driving without Jbeam was possible somehow? I mean, when driving normally in traffic, the car almost behaves like a rigidbody, aside from the wheels and suspension. That is until you do some extreme stuff with it, which traffic doesn't do. Maybe simplified Jbeam for suspension and rigidbody simulation for the rest, if this game engine can do this?
or at least disable things like the laggy traction control and aerodynamics. maybe engine thermals and other stuff like that.
Of course it's possible to drive without j-beams (other games do it) but if you want realistic behavior at crash time without having lag, the j-beams would have to be already in place. But if they're dormant until the crash it would be like driving without them. Basically the simplified physics would ignore them as far as calculations go, but they would be pre-loaded for a possible crash.
What about bigger compromise? A lot of games have simplified traffic cars for better performance. So why not create simplified versions of them? I don't talking about every single possible variant. Just one or two models of every car. I can run twice as much cars made in Automation than vanilla Beam vehicles. Having detailed traffic cars if nice, but for my 4 core processor it's a little too much.
The issue is that people will inevitably want to crash into said traffic cars, and if they still have this "lite" physics model, they're gonna crash like crap (like automation cars), and then inevitably people will complain. One might propose having multiple physics models for cars, one for far away and one for up close, but the game would wind up lagging every time it switches models due to having to essentially reload the vehicle, defeating the entire purpose. Traffic cars already use simplified physics if I remember correctly, with aerodynamics and self collision disabled until being hit by a player, but I'm not 100% sure if this is still the case.
Aerodynamics yes, self-collision is not being disabled anymore, idk why but you can test it and confirm.
No, basically there could be a switch for simple collisions with AI traffic. And no the traffic cars have no simplified collisions because the performance impact is exact the same.
Pathfinding for traffic cars seems to be another bottleneck in my observation. On bigger maps such as East Coast, just having 3 AI cars bogs me down even though I have 4 physical CPU cores (8 logical). But on the smaller Utah, running 3 AI cars doesn't impact my frame rate.
they'd have to make a new jbeam for every car to have simpler physics and be able to deform. sounds like too much work when ***apparently*** most people can afford and run a $50016 core processor now these days and they have no problems.
Did you even read any of the messages? We are not talking about simplified Jbeam because that would make no sense, but about alternative rigidbody simulation that would be way "lighter" to run.
That's a very needed feature indeed! I would also suggest that AI cars spawned with less parts which are barely visible (e.g. interior ones)
Ok... first, let me start off with this is not a bad idea, as of course everyone wants to be able to run more cars for traffic. That's just kind of a given. Now, onto why something like this hasn't been done. Firstly, some are suggesting using a rigid body system, and while that has potential to work, essentially you just end up having the Dev team program another physics engine into beam as beam just isn't meant to run with a ridged body physics system. Then their is the fun of making the two play nicely with each other with totally different collision systems... is it hard? Probably. Second, vehicles don't require their own core, but do require their own thread. This is because due to the way that the math is done, all the mathematics of a particular vehicle rely on the answer to the math that came one step before. This type of mathematics doesn't work well when it comes to parallel computing as each core just sits waiting for the answer from another core... this leads to a lot of waisted cycles, and thus why vehicles are run on their own thread. On the plus side, as long as your computer has the power to run 1 vehicle on 1 thread, then it has the power to pretty much run as many vehicles as your computer has free threads. This isn't necessarily 1:1 as most times the OS has to take up at least 1 thread along with the rest of the game engine/UI has to take up another, then probably Steam or other background programs taking up a third. So more than likely your computer will handle 2 or 3 less cars than your actual processor has threads. Third, not only is processing power increasing still at a fairly large rate, but the Dev's have actually managed to reduce the impact of the physics engine SUBSTANCIALLY. Heck, just from December of 2019 to July of 2021 (the two times I ran the Banana test on my computer) performance went up by 26%. That is HUGE! Now remember... that is on the identical computer with identical hardware from the last time I ran it. If I would have been a normal person and upgraded my computer somewhere in the middle there, I would have (obviously) seen a MUCH bigger boost because not only did the code evolve, but the hardware as well. What's my point... My point is is that remember, while we are all here playing this game, the game is still technically a beta. So things are dynamic and constantly changing all the time. This also means that if the devs wanted, they could decide that they want the minimum specs to be capable of running 100+ cars tomorrow, and thus would need something along the lines of an AMD Epyc with 128 threads to run it. Now that would be kinda stupid and they would never do that... but they could totally do that. The ideal thing to do for them would be to look at their roadmap and whenever they plan to be finally done as a full release, and then attempt to predict what the computer market will look like then. Perhaps by then 4 threads per core on CPU's would actually be the norm? Perhaps 12 cores then will look like what Dual Cores look like now? By that point, not only will they have still made some more speed ups to the physics engine, but they will have MUCH more processing power to play with. By then 64 cars will no longer be a struggle to the average user like it is to us today. I run a 10 year old rig and get about 5fps with 64 cars right now... with a properly modern PC (somewhat overkill for right now) I would imagine that one should be capable of getting close to almost 60fps with 64 cars, and in another few years, I would imagine your bog standard tower, or even just higher end laptop should be able to handle 64 cars at 60+ fps. So... now that I have laid that out... where I am getting at is I don't think that things should be implemented just to make old hardware keep up right now just to be rescinded in the future because it was never meant to be a permanent feature anyways. If Beam were to be fully released in like... a month? Then yes, I agree that they should do something to help lower end hardware run more cars... however, I dunno about you, but I don't think Beam is going to get a full release any time soon. There for... while things can be done to help get more cars on the road with less overhead, I don't think simplifying the physics engine is the way to do it right now. By adding in work around features just to help some users get by, they end up using resources on features that won't even be needed in a few years due to increased average user CPU performance, or potentially just game improvements overall that they are currently already working on anyways (because they always are). If they just focus on what they have been doing, game performance may just improve to a point where these work around features just wont even be needed anyways. As stated the AI does seem to take up substantial amounts of performance, so rather than focusing on the physics, I think reducing CPU usage on AI or figuring out a way to offload that job to the GPU (unless it already does) would be a much better avenue for improvement.
I get what you're saying. BeamNG is in fact still alpha, not even beta. And we users don't know exactly what the main bottleneck with traffic cars is at the moment. Is it the physics simulation as I assumed in my original post, or the pathfinding that I mentioned later? Devs would obviously have a better idea, especially after some testing. Mainly I started this thread just to let the devs know that there's popular demand for this. I'm sure they want to know what the community wants. Do I expect them to drop everything and start working on this yesterday? Of course not.
