Creating Node/Beam, Jbeam?

Discussion in 'Content Creation' started by Corky3D, Jul 23, 2020.

  1. Corky3D

    Corky3D
    Expand Collapse

    Joined:
    Aug 25, 2018
    Messages:
    6
    Sorry for this to sound really noobish and dumb, but how do you make a node/beam structure for this game? I think BeamNG refers to it as a Jbeam? Reading the wiki it seems as if you have to create all the nodes and beams in a text file format. Maybe I missed where it said it and maybe i'm not using correct words to search for trying to find my answer. I'm not new to 3D modeling or Node/beam also I'm not new to BeamNG, I just never post on forums. I used to mod and content create for Rigs of Rods, there I was used to the Editorizer to create Node/Beam structures that would convert it into a file. So i'm asking is there something like that for BeamNG? Creating Node/Beam through text file just doesn't seem right to me and I'm probably missing it somewhere.

    Just want to note that I use, Notepad ++ and Blender.
     
  2. atv_123

    atv_123
    Expand Collapse

    Joined:
    Aug 5, 2012
    Messages:
    1,710
    Yeah, the wiki is a bit rough. A lot of it is fairly outdated and old.

    As an old RoR veteran myself, I think I can give you the help your looking for and tailor it to the old RoR style.

    Alright, so step one...
    https://www.beamng.com/threads/nodebeam-editor-v-0-37.6103/
    This is a visual editor that your going to want to use... you can either download it there, or you can get start it up out of the in game files as it is included with the game now. Its kinda rough, but if your used to using the Editorizer... you will adapt just fine as that wasn't to polished either.

    Next, you said you have Notepad++ already... good... your gonna need it. Go get this bad boy and install it into your Notepad++... it will help you be able to read the JBeam files massively.
    https://www.beamng.com/threads/v2-notepad-jbeam-syntax-update-10-01-2013.4439/

    Now, one thing that is very important is in RoR everything that defined your truck was all contained in a .truck file. It sounds like you are fairly familiar with that so I will try to use all the RoR terminology. In Beam, 1 vehicle can be spread across TONS of files. This is because in Beam, they try to build the vehicles out of many parts... kinda like lego... Set up a front bumper file, then just copy and rename it... move the nodes around and give it a different mesh... boom new front bumper... and the game will let you just hot swap it onto the truck you meant it for on the fly... it really is quite impressive when, like me, you come from a RoR background where every new part meant an entirely new .truck file.

    At first, not gonna lie, I hated it... in my mind I definitely preferred the .truck file... everything I needed all in one file... plus after 5 years of modding with it, I could literally make a truck from memory without looking anything up... then I came to Beam and I felt like I was just starting over from nothing.

    Good news! You are not starting from nothing! Its just everything looks different. There is a different way or writing the file, but everything is the same underneath.

    So... what all do we need to get a truck going.

    I have included a test truck to show what kinda files these things take... trust me this thing is rough, but its just a sample to demonstrate building a mod. You can even use the files as a start off point if you wish.

    First thing you will need.... name.cs file. This file is important to even have your truck load into the game at all. Without it, the game just doesn't know what file to look in to start loading your mod.

    Next your going to need your first .jbeam file... in this case, the first one that should be loaded is frame.jbeam.

    The reason for this is because of the slot system... this is the first really new thing that threw me for a loop coming from RoR. Slots are basically how you tell the game what the part structure in your vehicle will be like. So when you go under the part selector in game and you can select an engine, axles, doors, hood, lights... all that stuff... thats all done with slots.

    In the frame.jbeam file, line 6, you will see
    Code:
    "slotType":"main",
    This is what tells the game that this is the lowest level file that it should start reading from... in other words... the top of our .truck file... this is ground 0.

    Next you will see this bit...
    Code:
            "slots": [
            ["type", "default", "description"],
            ["body","body","body"],
            ["frontsusp","front susp","Front Suspension"],
            ["faxle","front axle","Front Axle"],
            ["rearsusp","rear susp","Rear Suspension"],
            ["raxle","rear axle","Rear Axle"],
            ["Engine","Engine_6.5_Turbo","Engine"],
    Since we are in the frame file, these things are defining what parts will attach to our frame... if you go look at my file structure, you will notice that there is a .jbeam file for just about everything mentioned here in this section.

    "front susp" ---> front susp.jbeam and so on and so forth...

    Now thats just the way I laid it out here for simplicity's sake so I can find stuff easily. If you take a look at official vehicals or large (really just about any) mods, you will see that they can have multiple items inside each file... I didn't really bother doing that here as there just isn't enough parts to be bothered.

    Anyways, notice how they labeled the first line with ["type", "default", "description"],

    This line is actually really important... not only does it tell you what the section does, but it tells the game (ironically) what this section does. If you omit this line, the game ends up getting rather grumpy because you didn't tell it how to read this section... you will see more lines like this as we carry on.

    anyways... lets take another look at that code... (I'll put it here because I don't feel like scrolling up to look at it and now you don't have to either)
    Code:
            "slots": [
            ["type", "default", "description"],
            ["body","body","body"],
            ["frontsusp","front susp","Front Suspension"],
            ["faxle","front axle","Front Axle"],
            ["rearsusp","rear susp","Rear Suspension"],
            ["raxle","rear axle","Rear Axle"],
            ["Engine","Engine_6.5_Turbo","Engine"],
    Right... so we have 3 different names here... what do they do... well, this made no sense to me at first, but it makes perfect sense now. So lets look at the first name.

    Remember this?
    Code:
    "slotType":"main",
    This little line of code, as suggested by its name, defines the type of slot this is... That first name in the slots category is what you use to call out a particular part type. You can have multiple jbeams with the same slot type, but you can only install one of them at a time. The only example of this I have in here is the rear axle. In the files you will see that I have a normal rear axle, and then I have a rear steer axle. These both have the same slot type as they both mount in roughly the same way... naturally though, you want to make sure you can't accidentally mount both rear axles at the same time, so by making them both the same slotType, they will now both appear in the part picker under the list for Rear Axle... can only select one out of that list right? That's exactly what we want.

    Alright... second name there (again, lets look at the rear axle as thats the only one I did this so that it matters on) is the default part you want to pull up when you load the vehicle. So, for example, I have "rear axle" and "rear steer axle" as my part names (line 2 in any of these .jbeam files). The name I write in this second part is the part name that the game will default to when given no other direction (from like a configuration file or something). Notice here I have "rear axle" as my default? That means that every time I load this truck, it will default to installing the normal rear axle first.

    Ok, now the third thing... that is literally just the name of the part category... in our case the one we have been using was calling in the rear axles, so I called it "Rear Axle". Creative, I know... whatever you type here is what will show up as the name for the dropdown list in the part selector in game... so make sure to name it something that makes sense.

    Alright, next up, reference nodes...
    Code:
        "refNodes":[
                     ["ref:", "back:", "left:", "up:", "leftCorner:", "rightCorner:"]
                     ["frm14", "frm20", "frml12", "frm15", "frml0", "frmr4"]
        ],
    This section basically tells the game where to focus the camera around... this is basically the same idea as the Cameras section in RoR. The only difference is that Beam uses a few more points (as you can see from the header) to make sure that it is positioned accurately. In RoR, you just needed 3 points in an L and it was very easy to set up... in Beam, you have 6 points, and let me tell you, make sure that "ref:", "back:", "left:", "up:" are all at 90 degrees to each other, and that "leftCorner:", "rightCorner:" (they mean left and right "front" corners by the way... important distinction) are symmetrical... I say all this because if you don't do all that, then your camera can end up all wonky or your truck will spawn in at weird orientations and no one likes either of those things...

    Next up, I have the nodes section, and apparently I was a twat and didn't define any node properties, so let me go raid the wiki real quick here....
    Code:
    "nodes": [
         ["id", "posX", "posY", "posZ"],
         {"selfCollision":false},
         {"collision":true},
         //front of frame bottom
         {"frictionCoef":0.5},
         {"nodeMaterial":"|NM_METAL"},
         {"nodeWeight":12.5},
         {"group":"van_framefront"},
         ["fr1r", -0.44, -2.03, 0.48],
         ["fr1", 0.0, -2.03, 0.48],
         ["fr1l", 0.44, -2.03, 0.48],
         ["fr2r", -0.44, -1.74, 0.48],{"group":"van_framefront","van_swaybar_F"],"chemEnergy":200,"burnRate":0.3,"flashPoint":200,"specHeat":0.1,"smokePoint":150,"selfIgnitionCoef":false}],
         ["fr2", 0.0, -1.74, 0.48],
         ...
         ],
    Check out all that gibberish... looks like a mess don't it? Lets run through it line by line so that it actually makes sense...

    First... your header... tells the file how to read the nodes... ["id", "posX", "posY", "posZ"],
    This is identical (pretty much) to nodes2 on RoR, so you should be pretty familiar with that.

    Ok, so next you see {"selfCollision":false},

    Whenever you see something in {} like this, that means it is defining a property of everything that comes after it... so in this instance, {"selfCollision":false}, is defining that every node after if will be unable to collide with the truck that it makes up... it can't collide with itself... its fairly obvious I know... but I figure I should point it out.

    These properties you can just plop down anywhere in a node section... so... in this little code snippet...
    Code:
         ["fr1r", -0.44, -2.03, 0.48],
         ["fr1", 0.0, -2.03, 0.48],
         ["fr1l", 0.44, -2.03, 0.48],
         ["fr2r", -0.44, -1.74, 0.48],
    Lets say I want the first 2 nodes here to not collide with the truck, but I do want the second 2 to self collide... I would just do this...
    Code:
          {"selfCollision":false},
         ["fr1r", -0.44, -2.03, 0.48],
         ["fr1", 0.0, -2.03, 0.48],
          {"selfCollision":true},
         ["fr1l", 0.44, -2.03, 0.48],
         ["fr2r", -0.44, -1.74, 0.48],
    And its as easy as that... yeah, all those node options like n, m, f, x, y, c, l, so on and so forth? We don't do that here... we define them with {}

    Next, {"collision":true}, This is for collision with other vehicles or the ground... thats an important one... you get the concept though... most times this is true unless your defining supporting nodes for something.

    //front of frame bottom
    whenever you see a double // like that, that is just a comment. You could do this in RoR as well, but I always used ; as that was an option too... I don't know what you used, but comments in jbeam's can only be defined with // now so your kinda stuck.

    {"frictionCoef":0.5},
    {"nodeMaterial":"|NM_METAL"},
    {"nodeWeight":12.5},

    Ok, so these are kinda defining your SetNodeDefaults... except, again, you can kinda just chuck them about in a node section where ever you need them most. Anything after each one will switch to that new property.

    Friction is obvious, as is weight... nodeMaterial... well that defines what kind of material the nodes are made out of... this effects collision sounds, particles, skidmarks... basic properties of the node. I believe the 4 options are "|NM_RUBBER", "|NM_METAL", "|NM_PLASTIC", "|NM_GLASS" but there might be Wood as well... don't quote me on that though...

    {"group":"van_framefront"},
    Alright, what the heck is a group

    In flexbodies in RoR, you had to define in the flexbodys section a forset and then a node list... here this is all done in the node section... you built a fender? The nodes here are for the fender? Define it with {"group":"fender"}, (or whatever you want to name it) so that you can call "fender" in your flexbody section.

    Alright... going down a bit further you will find the beams section... (again, I stole this from the wiki because I didn't define much in that truck)
    Code:
    "beams": [
          ["id1:", "id2:"],
          {"breakGroupType":1},
          {"breakGroup":"frame"},
          {"beamSpring":1251000,"beamDamp":250},
          {"beamDeform":16000,"beamStrength":24000},
          ["f1rr","f1r"],
          ["f1r","f1l"],
          ["f1l","f1ll"],
          {"breakGroupType":0},
          {"breakGroup":""},
    ],
    Its kinda business as usual here... also rather than SetBeamDefaults, we use the same {} to define our properties... again... you can just plop then down anywhere on the fly.

    brakeGroups are basically the same thing as they were in RoR, so I will gloss over that...

    One thing you will notice here though... notice the bottom 2 lines...

    {"breakGroupType":0},
    {"breakGroup":""},

    basically they are setting their properties back to 0 or normal states... they do this because (lets say this is the end of the beam section) if they don't, then every beam that comes afterwords in subsequent files... if no more brakeGroupTypes or breakGroups are defined... will all belong to the first ones that are defined. This can happen with nodes as well... So get into the habit of closing each section in each file off with properties that basically set the properties back to their defaults...

    I have accidentally turned some doors on my mods into all springs and wondered what the heck was going on because of this...

    Finally there is the triangles section... literally identical to RoR... there isn't much for me to say here.

    I can give more help on more sections or how to get other things working, just ask, but I have been typing for like 3 hours now and I am tired :p
     

    Attached Files:

    #2 atv_123, Jul 24, 2020
    Last edited: Jul 24, 2020
    • Like Like x 4
  3. Corky3D

    Corky3D
    Expand Collapse

    Joined:
    Aug 25, 2018
    Messages:
    6
    Thank you ATV_123! You answered questions I didn't even ask yet. I couldn't ask for more and really appreciate your help, thank you! That was a giant help!
     
    • Like Like x 1
  4. atv_123

    atv_123
    Expand Collapse

    Joined:
    Aug 5, 2012
    Messages:
    1,710
    Let me know when you run into the Powertrain bits... that will probably need its own type up entirely as the RoR system is mind numbingly simple compared to Beam's...

    Beam's isn't bad or anything... far from it... its just you have to think about how your configuring it in an entirely different way... like ENTIRELY different.

    Remember, Beam's powertrain has to be able to be disassembled/reassembled on the fly, so you kinda have to build it with that in mind.
     
    • Like Like x 1
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice