You'll find it in the N-Panel. With your cursor in the 3D viewport, press N to show the panel. There should be a section for BeamNG. Edit: It seems you haven't enabled it in your user preferences. Go to File>UserPreferences. Then in the Addons tab, search for beamNG and enable the checkbox beside it. Then save your user settings and go back to the 3D viewport. I didn't detail this part, because it's similar to how any Blender Addon is enabled. https://docs.blender.org/manual/en/dev/preferences/addons.html
Perhaps you made an error installing it to the addons folder. Or you had the addons tab opened before you copied and did not refresh the tab after you copied. I'll go over the steps of copying it into the addons folder. First you extract the zip folder You should get a beamng folder with some python (.py) files inside it Copy the beamng folder into your addons folder Open the addons tab in blender's user preferences or refresh it if already opened Search for BeamNG and enable it Save user settings
Different beam types except L-Beams now supported in the export. I'm staying away from the undocumented properties for now. I'm now experimenting with different import approaches. Will keep posting on my progress.
L-Beams are probably not used much, I think those were used only for tires and game generates those for tires automatically. Also I think there was performance penalty with L-beams, or something why they were not used much. I'm really looking forward of this, also any question you might come up with, feel free to ask, I don't know even nearly everything, but I can dig up something
I believe they are also used in leaf springs on a lot of the car in game though... not at home to check, but L-Beams are still pretty useful... I think.
Your still young memory works so much better than my old one, yes, this I found from Barstow rear suspension: //leaf spring {"beamType":"|LBEAM"}, {"beamSpring":106000,"beamDamp":1000}, {"beamPrecompression":0.935}, ["ax2r","rx1r",{"id3:":"axsr"}], ["ax2l","rx1l",{"id3:":"axsl"}], ["ax2r","lf1r",{"id3:":"axsr"}], ["ax2l","lf1l",{"id3:":"axsl"}], {"beamPrecompression":1},
They sure are an odd bunch, the L-Beams. I don't see a way to represent them conveniently in Blender's data structures yet. Manually managing a third node for each L-Beam manually seems like the only option. Perhaps as my understanding of jbeam grows, I'll see a better way to manage L-Beams. Thanks for the clarifications.
This is nodes part of that earlier Barstow rear leaf spring setup, not sure if it helps any further, but you can see node positions. Code: "nodes": [ ["id", "posX", "posY", "posZ"], //live axle rear suspension {"frictionCoef":0.5}, {"nodeMaterial":"|NM_METAL"}, {"selfCollision":false} {"collision":false} {"nodeWeight":4.25}, {"group":"barstow_axle_R"}, ["ax2r", -0.61, 1.40, 0.43], ["ax2l", 0.61, 1.40, 0.43], ["ax3r", -0.68, 1.25, 0.18,{"group":["barstow_axle_R","barstow_driveshaft"]}], ["ax3l", 0.68, 1.25, 0.18,{"group":["barstow_axle_R","barstow_driveshaft"]}], ["ax1r", -0.68, 1.55, 0.18,{"group":["barstow_axle_R","barstow_driveshaft"]}], ["ax1l", 0.68, 1.55, 0.18,{"group":["barstow_axle_R","barstow_driveshaft"]}], {"nodeWeight":18}, {"collision":true} ["ax1", 0.0, 1.49, 0.17{"selfCollision":true}], ["ax3", 0.0, 1.12, 0.29,{"group":["barstow_axle_R","barstow_driveshaft"]}], {"nodeWeight":12}, ["ax2", 0.0, 1.44, 0.43], //damper mounting nodes {"nodeWeight":5.0}, {"selfCollision":true} ["axshr", -0.45, 1.40, 0.14,{"group":["barstow_axle_R","barstow_shock_R","barstow_leaf_R"]}], ["axshl", 0.45, 1.40, 0.14,{"group":["barstow_axle_R","barstow_shock_R","barstow_leaf_R"]}], //spring mounting nodes ["axsr", -0.59, 1.40, 0.18,{"group":["barstow_axle_R","barstow_leaf_R"]}], ["axsl", 0.59, 1.40, 0.18,{"group":["barstow_axle_R","barstow_leaf_R"]}], {"selfCollision":false} //leaf nodes {"nodeWeight":5.0}, ["rx1r",-0.52, 0.78, 0.18{"group":["barstow_floor","barstow_leaf_R"]}], ["rx1l", 0.52, 0.78, 0.18{"group":["barstow_floor","barstow_leaf_R"]}], ["rx2r",-0.49, 1.93, 0.37{"group":["barstow_floor","barstow_leaf_R"]}], ["rx2l", 0.49, 1.93, 0.37{"group":["barstow_floor","barstow_leaf_R"]}], ["rx2rr",-0.55, 1.93, 0.37{"group":["barstow_floor","barstow_leaf_R"]}], ["rx2ll", 0.55, 1.93, 0.37{"group":["barstow_floor","barstow_leaf_R"]}], //damper top {"nodeWeight":5.0}, ["rs1r",-0.32, 1.25, 0.43{"group":["barstow_floor","barstow_shock_R"]}], ["rs1l", 0.32, 1.25, 0.43{"group":["barstow_floor","barstow_shock_R"]}], {"group":""}, ], I'm considering that I could get you a BeamNG license from Steam, which might help you bit further, but it might not be before next month.
That will surely come in handy when I eventually tackle L-Beams. I appreciate your help really. For the time being though, I'd like to get this farther along before getting a BeamNG license. The wiki reference is quite detailed enough even if incomplete. When I reach the limits of that, I'd be happy to get a BeamNG license especially to test the undocumented properties. Thanks for your support
More than likely you are going to have a rough time implementing any sort of L-Beam representation in Blender. This is because an L-Beam (as it appears you have already discovered) is nothing more than a resistance to movement for 3 nodes out of their current positions. When you throw some beams into the mix, it can be thought of as nothing more than a springed hinge basically. If it is even possible... since there are no Beams to represent them... Could an L-Beam be represented by either changing the color or changing the size of the 3 vertices (nodes) that the L-Beam is comprised of? If not then we would just have to keep track of them manually which, if I am honest, isn't the worst thing in the world.
Using vertex colors is a good idea. However, I'm not sure if it's possible to have one node be a part of multiple L-Beams. Since one vertex can't have multiple vertex colors, this will block this method from working. Also, does the order of the nodes in an L-Beam matter? Vertex colors wouldn't be able to represent that alone.
Um... Yeah... vertex order would matter... let me see if I can draw up something terrible in paint real quick... Edit: Alright, I am back. That will probably need blown up to read it... As for one node being in multiple L-Beams... Yes... I suppose it could happen... I don't think I have ever seen it done though. You would be making something rather strange and unconventional if you did have to do that I suppose, so I don't think I would worry about that too much (unless there is the potential it could cause crashing... then definitely worry about it). If they are making something so complicated that they are interweaving L-Beams and what not, then I think that just coloring them all the same should be enough for them as they already have this all planned out in their head anyways. Edit 2: Actually I just totally thought of why I would use multiple L-Beams on the same nodes... just to hold an axle with leaf spring suspension straight. That would be totally doable. So I guess it could be totally used... but again... if you are doing this... you should be able to keep track of them in your own head even if the nodes have changed colors. Granted... when talking about importing... sometimes you may be importing someone else's vehicle and in that instance, the lack of color variety would be difficult to understand... Perhaps, if the L-Beams are read in, when you select an L-Beam, it selects those 3 vertices in Blender and blender just highlights them? That would be about the simplest way of figuring it out I can think of.
That's a very detailed explanation, thanks. The trouble with L-Beams in blender runs deeper though. Data has to be attached to a data structure such as a vertex or an edge, or an object. L-Beams would ideally be attached to edges (beams), so 2 linked edges would reference the same internal beamID for example. But over the course of model editing, as edges get duplicated, extruded, split, etc. This data will get copied as well, leaving potentially hundreds of beams with the same beamID. A perhaps more flexible way to handle this is by making L-Beams separate objects linked with constraints. Even as objects get duplicated, this won't become an issue. But I'd like to know, is it common to have, say dozens of L-Beams in a single jbeam? Because the more there are, the harder it would become for the user to manage. But if not, then it could be a lot more convenient to have them as separate objects.
That makes perfect sense and I totally understand why that would be a huge issue. Not usually... At most... there may end up being 4 to 10 of them over an entire vehicle... or at least the standard vehicles in the game anyways. Usually 2 per axle if it has a solid axle with leaf spring suspension. 2 for the simulated leaf springs, and, if you really want to go the extra mile, 2 or 4 (I don't think most actually do this but I will include it as you "Could" do this) for holding the axle straight if you really want to simulate that leaf spring properly. So for a leaf sprung vehicle, the minimum would be 2 per axle (if they even chose to use them at all). So I would say that they are used pretty sparingly... You really have to use your imagination to come up with a use for them sometimes... like right now I am working on a mod that is going to have a military style whip antenna... Naturally I do want it to "whip" around when driving, so a good use for L-Beams (if it actually works, I haven't tried it yet ) would be to make springs between the nodes on the antenna to hold the nodes 180° from each other and act like a real antenna.... but that will probably be my only use of L-Beams on the entire vehicle. Edit: I feel like I should say this just in case we aren't all on the same page... when I say 2 to 6 per axle... usually an axle is its own JBeam. So that would be one file... I feel like you might know that already, but I just want to make sure.
I didn't know that actually, thanks for adding it I'm not very well acquainted with vehicle engineering or related fields, so I can't intuitively imagine all those structures yet. I'll get there eventually hopefully I'll keep trying to find other methods, but for now, it seems representing them as separate objects would work best.
Alright, well, knowing that, when I get time, I definitely think I am going to make you up a simple truck... it will use multiple JBeams, L-Beams, the works... just for trying to help with this importer... I will make the parts themselves simple, but the overall vehicle a bit more complicated just exclusively for use in your importer/exporter. This way we can all be looking at the same thing that doesn't have 10,000 lines of code across 15 different files
