Development Sneak Peek #4

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 BeamNG.drive 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:

"wastegateStart":"$wastegateStart"
"wastegateLimit":"$wastegateLimit"

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:

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

Usage:

"wastegateStart":"$wastegateStart"
"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:

"wastegateStart":"$wastegateStart"
"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 BeamNG.drive, and remembered for the rest of the session:

You can of course still force the use of an specific audio device, if you want BeamNG.drive 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, BeamNG.drive 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!