Vehicle loading changes

Hi everyone

We are undertaking quite some bigger changes within the game engine right now to be able to move forward on a lot of interesting topics. I wanted to share this with you a bit and I hope it's not too boring to read

Lemme start trying to explain a bit how the game engine is working right now
Warning: will get technical now ^^

Maybe grab a coffee and lets get started:

---

So our GameEngine (GE) [we haven't found a better name so far ] is running one Lua (specifically we use LuaJIT) Virtual machine inside that is dealing with things like:

• Settings
• Gameplay
• generally, features on top of the game engine core (i.e. camera paths)
• Editors: Flowgraph, World editor
• Scene Management
• Scene (level) loading

Our GameEngine is written in C++ and is originally forked from Torque3D some 7 years(?) ago. Since then we revamped a lot of things and there are not many things left that we did not touch (performance work, removing horrible network code that made life horrible, render improvements, Lua, so much more ...). Today, it is consisting of around 384 thousand lines of code within roughly 1000 c++ source files. In visual studio 2019 it currently looks like this:

As you can see, it is doing the heavy lifting when it comes to things where we do need the speed of C/C++. It is busy doing:

• Rendering
• Storing the scenetree and what's going on on-screen
• Classes you can drop into your scene, like timeOfDay, Skies, water, TerrainBlocks, etc
• Filesystem, Networking (Mods, online API, etc)
• Physics integration
• User interfaces (currently CEF, ImGui and the old Torque3D GUI)
• A lot more i forgot to add to this list here

So, i want to explain the Lua changes that are upcoming:


Our GE has one Lua running (folder is lua/ge) and the physics core one per vehicle (folder is lua/vehicle).

So the vehicle spawning in the latest released version is working by having the GE side telling the physics to spawn a new car. The physics will then create new threads and a new Lua VM where the Jbeam loading code is executed in to load the files, assemble the vehicle and 'bake' the final car

This has several drawbacks that we saw growing bigger and bigger over the years. For example, the communication with the GE lua is very slow and is based on sending strings to each other. So getting data from the vehicle to be used in the GE is a slow ping-pong process of sending messages around. Loading 3D meshes to be used for the physics was a complicated issue as the GE needs to expose all the interfaces to do that. Due to many reasons like this, we will be moving the loading code for vehicles from the physics core into the GE itself. This way, we can optimize, parallelize and separate the tasks for each component better. The physics Lua VM will only care about the runtime things and the GE will completely send the physics a pre-baked vehicle it is supposed to load and work with. It can do the 3D meshes on its own - which is a huge relief as it reduces the overall complexity a lot.

First step some weeks ago was to clean up the jbeam (our JSON flavor) loading. It improved from being one file with 2000 lines of code into a nice structure where it's clear on what's going on:

After that was done, we slowly moved code to run from the vehicle side over to the GE side. That was a very slow and buggy process and we had to fix many problems (i.e. converting wheels math from float3 to our vec3 math library or the serialization breaking with infinite number values).

So, i hope i briefly rushed over the basics of this, lets talk a bit about performance. We use the tool Optick for profiling our game. It looks like this:


In the top half are the render frames displayed. Every bar is one frame of the game. 60 FPS means 60 frames per second. The vertical height of that bar means how long the frame took to complete. Ideally you want to distribute the workload of loading a level or a car over multiple frames equally rather than having spikes, which result in stutters or the appearance that the game is hanging. In above screenshot you can see gridmap is loading for 2 second in one frame, which is far from optimal.
The area below is the detail view of what happened inside the frames: from top to bottom are the things that are calling each other to do stuff. For example 'spawn' is calling 'loadVehicle' etc.

Lets have a closer look on how a cached (.cdae loaded) vehicle looks like in loading:

On the left side it starts with gathering all the jbeam files off the filesystem and parsing them, which takes around 223 ms in this example). Then it proceeds to go throught he jbeam sections, processing the 3D meshes, etc. It then sends the data over to the vehicle side where it continues with "spawnVehicleOhysics". It then spawns the physics object and finishes the 3D meshes in "spawnObject: post".

Writing this took a lot longer than i expected, i'll need to continue another day. Also would be cool to see how many people are interested in this, so i know if i should continue in that detail

Hope you enjoyed the little sneak peek

>> Continued with post #2 here. <<

Questions/Comments/etc?