Development Sneak Peek #4

Sneak Peek

Some of you were asking for a new Dev Sneak Peek, and it’s finally here πŸ˜‰

We have all been quite busy since the last post in the series, here’s a brief summary of what you have seen:

While all of that happened, we’ve been continuing to work on the next major release, and regularly posting updates in the developer subforum. Some of these updates mention features that are already available for you to play with, so those might not be new to you, but we thought you’d like to see what’s under the hood anyway.

Remember that this post contains just a sample of what the BeamNG team has been working on. Most of it is taken straight from our Developer Section, so if you want to find out about these tidbits before anyone else, you may want to subscribe to that subforum.


What you see here will **NOT** necessarily reach the next update or the final version If it does, it is **NOT** representative of what it may look like More work happens behind the curtains - this is **only** a random selection!

Here’s some signs:

A few more:

Hot-loading for Mesh is fixed too

Currently working on small improvements for the spawn algorithm of External camera. Here’s some debug visualizations of two of its worst enemies:

One of them is curved tunnels:

Red lines are the reasons why specific spawn configurations were discarded.
Blue lines are those discarded spawn configurations: each blue line represents the predicted camera path during its panning movement. If the camera was static, it would be just a point, rather than a line.
The black line represents the chosen spawn point. Green sphere is the original position, white is its current position, red will be the final position, if everything goes according to the basic predictions we performed at the beginning of the take.

Sneak peek, work in progress πŸ™‚

This is a statistical profiler, and is one of the tools a developer can use to optimize software:

It sneakily gathers stats about what the program is internally doing at intervals, for a period of time. If this profiler thingie caught doing the same thing (in the same function of code) 90% of the times it has taken a look, then it would mean we are probably spending 90% of the time there.

More samples means more reliable stats. In this case, the profiler has taken 62.000 samples while I was recording a replay of an ETK K-series doing burnouts and donuts.

Once you know what the cpu time is used for, you have a better idea of where it might be worth to spend your time optimizing. As you analyze and rework the chosen code, you run the profiler again to verify the results are indeed what you expect (they not always are).

In this case, the changes resulted in roughly a 0.6% increase in framerate for that specific replay recording scenario in my computer.

So, in the first days of the repository our CDN provider Akamai really helped us push the load - so everyone can have fast ingame downloads πŸ™‚

The peak bandwidth at one point was 1939 MBit/s πŸ™‚

Since its release, we had 387 thousand downloads with it πŸ™‚

Hilltop villa:

The last days we have been working on implementing an expression based system for variables in jbeam.

To recap, that’s how variables in jbeam are currently used:

Define the variable(s):
["$wastegateStart", "range", "psi", "Turbocharger", 8, 6, 36, "Wastegate Start", "Pressure at which the wastegate begins to open"]["$wastegateLimit", "range", "psi", "Turbocharger", 10, 8, 38, "Wastegate Limit", "Pressure at which the wastegate is fully opened"],

And then use it to adjust whatever you need to adjust:


Now that system has enabled us to offer lots of tuning options, from tire to pressure, over turbo and engine settings to things like spring rates.

However, all the time the system was quite limited, you could just assign a single variable to a single data point.

With the expression based extension of this, we aim to allow for simpler, yet more powerful tuning options.
The goal is to essentially allow the creator to use math inside these variables to allow for finer control and easier tuning.

Let’s take a look at the example from above simplified with expressions:

["$wastegateStart", "range", "psi", "Turbocharger", 8, 6, 36, "Wastegate Start", "Pressure at which the wastegate begins to open"]


"wastegateLimit":"$=$wastegateStart + 2"

As you can see, you can now avoid having two different variables and just use a fixed offset.

One could also allow to tune the start value + the offset and use it like so:

"wastegateLimit":"$=$wastegateStart + $wastegateRange"

We also plan to allow the use of certain math related functions like:

  • min
  • max
  • abs
  • sin
  • cos
  • tan
  • sign
  • round
  • square
  • etc

We haven’t finished working on this yet, so details may or may not change/disappear/appear. But in any case, this is a much needed extension of the jbeam variable system, made to allow for much greater customization while keeping stuff more simple to use. πŸ™‚

Just a tiny cryptic teaser πŸ™‚
As always, no promises on if and how that actually makes it into a final release but we are experimenting with something like this.

Improved ‘Caustics’ being displayed at any depth at full strength.
Now fades out the deeper you go.

We also disabled the underwater bobbing/distortion effect, as it was kind of nauseating.

I implemented longer grass for the more wild areas

Working on lots of invisible changes on the render code, but i have on my ToDo some little things too…

Added a new material option for invert backface normals for simplify geometry of some opaque objects.

A future update will include small improvements in the handling of audio devices.

The first change will be the ability to just use whatever the selected Windows audio device is. It’s checked each time you start, and remembered for the rest of the session:

You can of course still force the use of an specific audio device, if you want to always go through one specific output (if you want to actively ignore your Windows configuration).

The second change is the ability to remember previously plugged devices:

For example, if you had decided to use a USB headset for the game, and have now unplugged it, will temporarily use the Windows default as fallback. But it will remember your old choice and use it again next time you run the game with that USB headset plugged in.

Repo is back on - 2.9 GBit/s max peak, 17.5 M hits and 26.8 TB mods delivered in two days.

Improved the grass throughout the entire island.

Giving the torque/power related apps a bit more attention:

There has been some confusion around what each value means so I tried to make that more obvious πŸ™‚


Busy street

What you see here will **NOT** necessarily reach the next update or the final version If it does, it is **NOT** representative of what it may look like More work happens behind the curtains - this is **only** a random selection!
Sneak Peek

BeamNG Major Updates v0.25 - Spark Your Passion v0.25 release highlights
Festive Update v0.24.1 Released v0.24.1 release highlights
The 2021 Winter Release – v0.24 v0.24 release highlights
The 2021 Summer Release – v0.23 v0.23 release highlights
The 2021 Spring Release – v0.22 v0.22 release notes
The 2020 Winter Release – BeamNG v0.21 v0.21 release notes
The 2020 Summer Release – BeamNG v0.20 v0.20 release notes
β€œLa Vie Γ  Toute Vitesse” – v0.19 v0.19 release notes
The 2019 Winter Release – v0.18 v0.18 release notes
Buckle up, heavy traffic ahead: Update 0.17 released v0.17 release notes
Electrifying 0.16 v0.16 release notes
A Small Car on a Big Map – Version 0.15 released v0.15 release notes
Light Runner – Version 0.14 Released v0.14 release notes
The Automation Collaboration – Version 0.13 Released v0.13 release notes
Get Busy – version 0.12 released v0.12 release notes
Alpha version 0.11 – The Coast is Clear v0.11 release notes
Sounds like version 0.10 is out! v0.10 release notes
Hopping into 0.9 v0.9 release notes
Version 0.8 rolling in … v0.8 release notes
Alpha version 0.7 released :) v0.7 release notes