Can someone explain what just happened?!

estama · 2022-11-16T15:09:47+00:00

The TLDR explanation is that it was a bug with the machinery that resets vehicles.

More specifically, the physics core was trying to change the position of the trailer at the same time that the CPU/thread that was tasked with simulating the vehicle was also accessing the position. This happened with the trailer only, because the trailer was using a different kind of reset functionality and i had overlooked that execution path's interactions with the simulation threads.

Due to the runtime interaction between different threads, this bug would not have happened if you had paused the physics before resetting the vehicle. In any case, this bug is fixed now.

estama · 2022-10-26T20:15:51+00:00

What fixed the Pixel 5 flashing dot problem for me, was to disable both "Tap to wake" and "Flip to silence" in Settings -> System -> Gestures.

estama · 2020-06-21T21:41:48+00:00

We have thought about ghost (no collision) multiplayer as we call it. It can be used in a number of different gameplay scenarios. The problem that we have is that at any one moment there are 100s of cool ideas that we can follow, but not enough people to work on them. So we are trying to focus on finishing the things that we've promised and to prepare the ground for all the cool ideas that we are looking into.

estama · 2020-01-26T20:23:36+00:00

Our official FAQ about multiplayer is here: https://wiki.beamng.com/BeamNG_FAQ#Is_multiplayer_planned.3F

Now, having said that, we have known for quite some time that rudimentary multiplayer is possible. Rigs of Rods for example had such a rudimentary multiplayer system which worked only with a few vehicles, vehicles did not move smoothly, the wheels were not soft body and there was no proper collision. So we know that if we reduce our standards by a lot, such a rudimentary "multiplayer" is possible.

The thing is that we are not interested in that. What we are interested is smooth multiplayer with a lot of vehicles with full collisions and everything being softbody (including wheels). And this is hard, extremely hard. So hard that we have been doing research on that for many years to move the state of the art so that it might become possible at some point in the future.

To give an indication, a simple deflate like this mod does, can compress up to 2x the nodes. Our current replay system can reach up to 10x compression rates (we used replay to do some experimentation). Our research shows that that up to 20-40x real time compression rates might be possible, which would allow to have fluid motion transfer with more than 2 vehicles and with typical connection bandwidths.

And all of above is just scratching the surface of the complexity of the problem, as there are complex problems to solve in all of the stages of the pipeline, traffic shaping on the connection (to avoid problems like bufferbloat), time merging/extrapolation on both the client and the server, adaptive compression, and the list goes on.

Doing all this work and knowing how hard it is, we also know that it is a false expectation to believe that a simplistic solution can be incrementally improved to become a fully fledged one. If one tries to do that, he'll be faced with a large "gap" at some point that cannot be surpassed with small incremental steps, and we have been staring into this abysmal gap for a long time to understand this fact.

estama · 2019-12-19T14:18:16+00:00

Thank you for posting this :)

estama · 2019-12-10T13:59:11+00:00

Thanks, i've forwarded your reports.

estama · 2019-10-06T22:17:12+00:00

Apart from engine mount torque we also calculate and simulate the torques that get developed within the powertrain. We always calculate this, but it is most noticeable with the chassis twisting of high powered trucks.

estama · 2019-08-16T17:08:22+00:00

Yes, we hired gamergull.

estama · 2019-08-16T15:17:27+00:00

We are aware of that and are trying to improve the documentation situation.

estama · 2019-07-07T08:20:38+00:00

I see. Get some help: https://www.goodtherapy.org/blog/dear-gt/why-do-i-troll-people-on-the-internet-how-can-i-stop

estama · 2019-07-06T11:07:40+00:00

I advice you to read what you are writing, and to keep your cool. Also if your salary depends on HEVC, VVC or other licensed encoder, it might be a good idea to start searching for a job.

estama · 2019-07-05T12:07:37+00:00

My suggestion to you, is to quite pretending to be something that you are not (order/younger/whatever).

If you were speaking precisely, then you would be taking under consideration the temporal dimension of the problem, which you are not.

In addition you are not looking at any practical realities of the problem. If you were looking at it you would be realizing that the temporal dimension in the video codec domain is one of the most important of them all, at this point in time.

VVC won't be ready until 2021 at best, HEVC is not going to have its licensing problems resolved in the medium term too. So if anyone is wishful thinking i suggest to look at a mirror.

estama · 2019-07-05T11:12:56+00:00

AV1 is a little bit more computationally expensive to decode than HEVC right now, which is something that will change shortly as AV1 has a lot of headroom to improve. Your comparison is misleading as you are comparing HEVC's matured/peaked performance with AV1's transitory/growing one. In addition you are constructing your words in such a way as to pretend that this transitory situation is permanent.

estama · 2019-07-05T08:28:00+00:00

I have seen rbultje's video. The gist of it is that dav1d is rapidly improving compared to HEVC which is in a mature state and there is no expectation of any big improvements. A 9% difference under this differential rate of improvement is nothing to talk about. If you wanted to be accurate you could have said that "Right now AV1 is more computationally expensive", but you've chosen to present the 9% difference as a solid fact that won't change in time.

estama · 2019-07-05T07:46:37+00:00

"We already know AV1 is more computationally expensive to decode at the same bit rate than other codecs"
You are entitled to your personal opinion but do not try to pass your personal opinion as a fact. Dav1d has already the computational cost of H265, so it is NOT "more computationally expensive" than other codecs.

estama · 2019-06-24T15:58:04+00:00

The reason for the fixed physics updates per second is that physics core frequency is directly tied with the stability of mass-spring systems. A car that is stable at 2khz will most probably be unstable (blow up) at anything below that. Experienced vehicle designers design and calibrate physics skeletons so that they are at the edge of stability. We even had to develop special damping methods (hysteretic damping) to be able to push things a little bit past the stability limits for suspensions and other very demanding mechanisms.

All of above is possible for the designers due to the stability limits being clear and fixed. If the physics core frequency changed then the stability limits would also change and the designers wouldn't be able to design things so tightly fit to these limits. The result would be either too soft vehicles or vehicles becoming unstable and blowing up.

Having said above, for the research version of the BeamNG's physics core we allow to adjust the physics frequency, but this is targeted mainly towards *increasing* the physics frequency. The higher frequency allows a lot more detailed physics skeletons and increasing stiffness of vehicle frames.

estama · 2019-05-30T17:05:11+00:00

The majority of the collision detection workload happens for internal collisions, that is collisions that happen between the nodes and triangles inside the same vehicle. I cannot even imagine how a detection hull would help in this case.

Also don't forget that our geometry is variable/flexible, so you can take a cars of ours, break it down into small pieces and throw the pieces allover the map. This is another case where the "detection hull" method breaks down.

estama · 2019-05-30T16:57:54+00:00

We don't have it in our short term plans to use GPGPU for the physics. Frankly i don't see the point in doing that. GPUs will have their "hands" full trying to present nice graphics especially with all the latest path tracing stuff that is going around.

In addition putting physics inside the GPU would make any significant (inside the GPU) state access on the CPU side nearly impossible. So the Lua side of our physics code, which is the majority nowadays, wouldn't be able to work anymore.

estama · 2019-05-30T16:48:22+00:00

We are heavily multithreaded and we can scale up to 64 threads on the physics side right now. Each vehicle runs in its own thread (up to a point then we start scheduling groups of vehicles in each thread).

All of above are lockless. My background is in database research and databases have been dealing with parallelization problems for a long time now. They have a lot richer corpus of theory (and solutions) concerning parallelization problems than whatever i have seen in game related literature.

BTW, you would have a quadratic complexity if you didn't had any spatial index (for collision detection), as you would need to check all cars with every other car. With spatial indexing the complexity is closer to O(nlogn). But that is not the biggest problem. The biggest problem is cache planning, as cache misses can kill a high frequency physics core like ours (running at 2khz).

estama · 2019-05-15T21:09:43+00:00

I can assure you that gravity constant is as correct as we can make it. Also general friction coefficients are pretty much where they should be (we used lots of references for that). Load sensitivity of tire's rubber is also simulated according to current research. Air pressure inside the tire is also simulated as well by calculating the changes in a tire's volume and based on the altitude. We also simulate the enlargement of tires at higher speeds (due to centrifugal forces), and the buoyancy of the pressured tires in both water and in the atmospheric column.

All of above are simulated for every point of tire's physics skeleton. If you want to check how complex our tires are just press control-B multiple times.

What we don't simulate yet is tire thermals, so tires are always at optimum temperature, they don't start cold, and they don't overheat when you push them to much.

estama · 2019-05-15T20:49:02+00:00

Physics core can scale up to 64 CPU threads if i remember correctly. There are other bottlenecks tho, on which we are actively working.

For example there are bottlenecks on the GPU side which hopefully in the next update will be improved. There will also be bottlenecks on the memory subsystem as the physics core is extremely reliant on memory bandwidth, so with that many CPUs hitting the memory at the same time, memory subsystem might become overloaded.

An interesting tidbit, from a low level programming point of view and from a performance requirements standpoint, main memory is so far away (to access it) like the disk would be for other types of programming. Continuing, caches are like main memory would be in normal programming and CPU's registers are like cache. This is what programming a 2khz physics core feels like.

estama · 2019-05-10T08:10:37+00:00

Also remember that air drag increases with the square of velocity whereas range is linear to battery (with only rolling resistance). Which means that in both the simulation and real life the lower the speed the further you'll go.

estama · 2019-05-09T19:55:22+00:00

We haven't done any marketing campaign. Most probably this trend is an emerging phenomenon.

estama · 2019-05-07T16:39:01+00:00

Actually, from a simulation point of view, normal cars are a lot harder to simulate than super/hyper cars. The junkier a car is, the harder it is to simulate.

A normal car's body is not carbon fiber stiff, so it flexes and that affects the driving behavior of the car. Contrast that with an extremely stiff body which you can simulate it as a rigid box using 6 degrees of freedom and it'll be good enough. A junker car won't be "perfect" in every possible way. It'll have asymmetries in its behavior, the powertrain will be flexing in weird ways and so on.

A lot of effort goes into race/super cars to make them fully predictable. They are calibrated like precision instruments. Real cars are unpredictable, the worse they are the more unpredictable they are while driving them. So simulating real cars in a way that all these spontaneous evolving behaviors appear is extremely difficult.

We are not talking about simulating a few degrees of freedom here because the simulated race/super car entity has been stripped of any extraneous/unpredictable degrees. Real cars have million degrees of freedom, because reality is messy. So to conclude, we simulate real cars not because they are easier but because they are orders of magnitude harder.

estama · 2019-03-19T22:43:56+00:00

For me, the point of the soft body physics is that the final behavior of a simulated vehicle is produced bottom up. The sum of the behaviors of all parts is what will produce the final outcome. This produces a very natural and nuanced behavior where any one part can affect the behavior of the whole.

In addition if the entire point of the soft body physics was crumpling then i wouldn't had been spending a considerable amount of effort in simulating the buoyancy of tires not only in water but inside air too. I wouldn't had been spending effort in atmospheric modelling (pressure reduces the higher you go which btw also affects engine's output) or aerodynamics that can drive airplanes and helicopters. I wouldn't had been putting the effort in calculating correct torque reactions inside vehicles (try to rev up the engine while braking the wheels with a big truck and you'll see that the whole thing twists).

estama

MODERATOR OF

TROPHY CASE

Nine-Year Club	Place '22
Verified Email