No GPU Mode(headless mode) - no collision /no road

General
1

Hi!

We´re trying to set up multiple instances in parallel on a High-Performance-Cluster with the goal of model validation and reinforcement learning.

So basically a specific vehicle model drives the same rout over and over autonomously.
In the basic headless mode this works so far, but still requires a computation node with graphics. These are less common on our cluster.

So the solutions should be the headless mode with the gfx null flag, see here:

Disabling the GFX came with multiple problems, the most basic one is the not rendering of the street, so the vehicle drives directly on the height map. (Driving behaviour on hills is important for us). But you cant physically drive on the height map, due to the resolutions and therefore steps in the “road”.

After some reading and testing Claude and we came to following summary:

The architectural root cause

BeamNG’s Game Engine — which is the closed-source C++ core responsible for 3D rendering — has a primary update loop that runs every graphics frame. This is separate from the physics core running at 2000 Hz.

That matters enormously: when -gfx null is active, there are no rendering frames. The physics tick still runs, but any asset-loading or scene-registration work that happens during the game engine’s frame loop is either not fired or deferred indefinitely. Collision mesh registration for world objects passes through this path.

In Torque 3D (BeamNG’s base engine), the GFXNullDevice is explicitly documented as being intended for dedicated servers that process simulation events without rendering — not for full world physics with collision geometry.

Also Flowgraph does not work.

First question: Do you agree with the statement above?

If so: I can not see any real usecase for the gfx null option, can you imagine any?

Witch brings me to my final question: how to solve the basic problem:

  • Parallization of BeamNG for usecase
  • no gpu on a typical High Performance Cluster
  • No driving vehicles/physics without the GFX steps in the engine

Thank you,
will keep you updated, if we find anything in the meantime!

2

Right now we´re testing this suggestion, but it seems to be rather a workaround, then solution.

Alternatives

To run without a visible window on Linux but still render the UI, you can use the X Virtual Framebuffer (Xvfb):

sudo apt-get install xvfb # install Xvfb
xvfb-run --auto-servernum BinLinux/BeamNG.tech.x64 # put other command-line arguments here, -headless is not needed
3

Hi Lukas,

Thanks for the detailed testing.

Headless is not the problem. When you say basic headless works, that is expected. Headless means no window/UI, not no GPU. Even without a monitor, BeamNG.tech still needs a graphics backend for roads, terrain/collision prep, cameras, and many other systems. Needing a node with a GPU in headless mode is normal.

What broke things was -gfx null — a separate no-GPU mode. Road rebuild and terrain preparation often do not complete there, so you end up on the raw heightfield. That matches what you saw.

1. Do we agree with your statement?
Partially yes. Physics runs, but map-faithful driving still depends on the render/scene pipeline. Flowgraph failing with -gfx null is also expected: many nodes call render APIs directly (Engine.Render.*) and assume a fully initialized world — not because of a Flowgraph-specific guard.

2. Any real use case for -gfx null?
Yes, but narrow: BeamNGpy connectivity checks, basic vehicle physics, and simple scripting where road fidelity does not matter. It might be not suitable for RL, model validation on real maps, or Flowgraph.

3. Parallelization on a typical HPC (mostly CPU nodes)?
** Use -headless on GPU nodes (no monitor needed), one BeamNG instance per job via BeamNGpy, and avoid -gfx null / docker-compose-nogpu.yml. If headless misbehaves on a node, try the Xvfb Docker entrypoint — it still uses the GPU.

We would be glad to hear what you find if you test GPU headless on your cluster.

Please let me know if you have any further questions or require additional assistance.

Best regards,

Abdulrahman Saeed
Junior Research Software Engineer
BeamNG.tech Support Team