Final Mesh Splitting

Brief JBeam Overview

JBeam is BeamNG’s “language” for building cars.

It is based on the concept of defining physical points in space based on coordinates (the nodes) that are linked together with beams which have physical properties like spring, damping, deform strength and break strength (these are the beams form which the game gets its name).

It goes much deeper than that, but in essence this is the basic concept behind our vehicles and is important to have a rough idea of in order to make 3D models for it.

To visually represent the vehicles, we place meshes over the top of these and bind each mesh to a specific group (or groups) of nodes that represent that part. When the beams deform and the shape of the structure changes, the mesh is deformed to follow the nodes it is bound to.

Mesh Conventions

Mesh Splitting Conventions

Generally, any mesh that will form a vehicle part that is detachable or removable in-game will need to be a separate object.

For example, bumpers, hoods, doors, engines, subframes, and so on, must detach, therefore they are separate to the body. Some parts like badging and lettering are not detachable but can be exchanged or removed and also have to be separate.

Some meshes may be required to dynamically swap materials in-game, for example, glass and lights for visual damage. We define groups of beams in a particular area, and if any of them are deformed, the group is “triggered” and the material for the defined meshes is swapped.

To do this, they need to have only one material to the mesh, so they have to be a separate mesh even though they might not be removable or detachable. In the case of glass, we use a different material for the outside than the inside, so the faces of the glass facing outward are a separate object to the faces facing inward.

Both of these objects will be switched to the same legran_glass_dmg material when their deform group is triggered, but since they need different materials in their un-damaged state (interior glass material is much clearer and less reflective) they have to be separate objects.


Another example is the headlights of most vehicles:

The headlight frame is part of the body material, and does not contain any materials that need to be swapped for damage purposes.

The headlight glass contains only the vehicles "glass" material, so when the headlight is broken in-game it can be swapped to the glass damage texture

The headlight itself is a bit more complicated. It has multiple materials, one for each light function (high beam, low beam, left turn signal, etc.; this is explained more in the material naming section below) but all of these materials are mapped to the same "lights" texture, so when the deform group is triggered, all of these materials are swapped for the lights damage material.

Meshes that use the deformation system to move, such as suspension arms, steering tie rods and suspension struts need to be separate also. Generally, we separate any symmetrical parts left to right for more freedom when it comes to binding these meshes to node groups when implementing the vehicle into the game.

Try not to over-split objects. For example, the various parts, pipes, etc., in a vehicles engine bay can all be combined together into "vehiclename_enginebay". This makes adding and keeping track of objects much easier when it comes to implementing the vehicle into the game.

Mesh Naming Conventions

Mesh names are all in the same case, words separated by underscores. All letters are underscores except for position identifiers (explained shortly). Don’t use any special characters other than underscores as many of these do not export properly.

For any vehicle, every object name begins with the internal name of the vehicle, followed by the name of the part and a position identifier if needed. For example, "wendover_door_FR"

Generally, we stick to American dialect for part names: hood, trunk, fender, muffler, etc., instead of bonnet, boot, wing, silencer

For any part that may have a front, rear, left or right version we use an identifier in the object name. These are always in capitals to make them easier to read at a glance.

Generally, these are:

  • F = Front
  • R = Rear
  • FR = Front Right
  • FL = Front Left
  • RR = Rear Right
  • RL = Rear Left

Some examples would be sunburst_fender_FR, hatch_sideglass_RR or pickup_bumper_F.


You might need to deviate from this in some case, for example, you may need to use RRL for Rear Rear Left on a truck that has 3 axles (semi_brakedrum_RRL), or use just R and L for left and right if applicable (for example, the doors of a two-door car).

For parts that have similar variations intended to fill the same position, such as different options for a bumper, we use a, b, c and d, etc., to identify them, such as "wendover_fascia_F_a" and "wendover_fascia_F_b". For more unique options, like a different body style, engine or suspension configuration we use more descriptive part names such as "legran_body_wagon", "vivace_engine_i5" or "miramar_axle_R_wide"

In some cases, you might need to use more than one part name, a good example would be trim pieces that are fitted all around a vehicle. Order the names with the most relevant first, so they are easily found when the mesh is imported.

For example:

  • "pickup_trim_fender_FR_a"
  • "pickup_trim_fender_FL_a"
  • "pickup_trim_door_FR_a"
  • "pickup_trim_door_FL_a"
  • "pickup_trim_bed_a"

All things considered, this is not a completely set-in-stone system. If you find yourself stopped thinking about how exactly to fit a certain object into the described naming system, then it most likely doesn’t fit and you can just come up with your own name as long as it mostly resembles the system we use.

Mesh Sorting Conventions

While not critical to JBeam specifically, it does help to sort objects into relevant collections to ease exporting and testing. This is important because after final mesh splitting, there are a lot of parts.

Organize things where being able to hide all of a certain set of objects at once would be helpful. For example, if a vehicle has multiple engine options each with their own set of addon parts like intakes and exhausts, those should be individually grouped.

If a car has a set of alternate facelift panels, those should also be grouped separately of other panels. This is mostly up to preference, but at least some organization is expected.

Last modified: April 16, 2026

Any further questions?

Join our discord
Our documentation is currently incomplete and undergoing active development. If you have any questions or feedback, please visit this forum thread.