That's super impressive looking! I would have never thought to make something like that for Beam! Also, I have the super simple truck done... just need to eliminate a couple of errors before I load it up on here... by the way... anyone expecting an actual mod from this thing, prepare to be disappointed... it is literally just for importing and exporting demonstrations... there will be no flashy bits... it's practically just a box on wheels.
I decided to make one jbeam fully from scratch with this plugin. There is my mistake? It seems like beams not connected to each other. Code: { "carwagon_body": { "information": { "authors": "", "name": "Untitled", "value": 0.0 }, "slotType": "carwagon_body", "slots": [ [ "type", "default", "description" ] ], "dragCoef": 10.0, "scalebeamSpring": 10.0, "scalebeamDamp": 10.0, "scalebeamDeform": 10.0, "scalebeamStrength": 10.0, "refNodes": [], "cameraExternal": { "distance": 10.0, "distanceMin": 10.0, "offset": { "x": 0.0, "y": 0.0, "z": 0.0 }, "fov": 65.0 }, "flexbodies": [ [ "mesh", "[group]:", "nonFlexMaterials" ], [ "BeamNG_Nodes", [ "beamng_frame", "BeamNG_Lowerarm_F", "BeamNG_Upperarm_F" ] ], [ "BeamNG_Beams", [ "beamng_frame", "BeamNG_Lowerarm_F", "BeamNG_Upperarm_F" ] ], [ "BeamNG_XBeams", [ "beamng_frame", "BeamNG_Lowerarm_F", "BeamNG_Upperarm_F" ] ] ], "nodes": [ [ "id", "posX", "posY", "posZ" ], { "nodeWeight": 15.0 }, { "collision": true }, { "selfCollision": false }, { "frictionCoef": 1.0 }, { "nodeMaterial": "|NM_METAL" }, { "fixed": false }, { "surfaceCoef": 0.10000000149011612 }, { "volumeCoef": 0.10000000149011612 }, { "group": "Default NodeGroup" }, [ "0", 1.0800000429153442, 3.325000047683716, 0.8663820028305054 "group": "" } ], "beams": [ [ "id1:", "id2:" ], { "beamSpring": 45000000 }, { "beamDamp": 2000 }, { "beamDeform": 200 }, { "beamStrength": 20000 }, { "beamPrecompression": 1.0 }, { "beamType": "NORMALTYPE" }, { "group": "Default BeamGroup" }, [ "36", "37" If i dont put any beam specs it lloks like this Code: "group": "" } ], "beams": [ [ "id1:", "id2:" ], { "beamSpring": 0.0 }, { "beamDamp": 0.0 }, { "beamDeform": 0.0 }, { "beamStrength": 0.0 }, { "beamPrecompression": 1.0 }, { "beamType": "NORMALTYPE" }, { "group": "Default BeamGroup" }, [ "36", "37" 1st code 1st video 2nd code 2nd video
So I have the truck built... Like I said before, this is just for demonstration purposes. There isn't much here, but at least we can all know what we are talking about by just looking at this truck and not getting too confused because there just isn't much here. Importing and exporting will probably be easier with this as well seeing as it is so simple. Edit: Also feel like I should mention... this thing has 4 L-Beams... 2 per axle being used as the leaf springs. Like I said, I tried to keep it relatively simple, so I think 4 L-Beams (seeing as those are what you had concerns about) should be a good starting point. I also included an interchangeable rear axle (with rear steering... that's the only difference) which should reliably simulate a single car with multiple parts. A lot of times these extra parts will end up having the same node names as other parts, so figuring out how to deal with that may also prove to be a challenge in and of itself. Spitballing here real quick... rather than importing the ENTIRE set of JBeams to be modified, it might be useful to be able to import the whole lot, and then pick and choose which parts should be editable (for instance, if I wanted to modify one of the rear axles of this truck, I could choose to only import 1 of the 2 available to make modification easier) Not sure how much work it would take to create something like that, but I could help come up with the logic behind it (I don't know the actual code type that blender uses... and probably don't even know whatever programing language it is... but I understand how if, then, else, while, do loops and how to use them for logic all works)
I'm impressed!!! I had no idea the addon was even usable yet! In my head, it's all just theoretical. Thanks a lot for sharing It's really encouraging to see. @atv_123, Good idea, simpler is better for testing. Thanks for that. I'll begin dissecting it right away. Yes, I agree the import should allow for modifying specific parts rather than the entire machine. I've been working on that lately. @zagdima, Could I take a look at the full jbeam files generated by the addon? Maybe I'll be able to figure out what went wrong from there. To make things easier to handle, please create an issue on the bitbucket repository. https://bitbucket.org/Khalibloo/beamng.drive-blender-addon/issues?status=new&status=open Manged to clear up a couple of hours daily for this project. The hardest task is juggling all the different bits of data and where they live in blender. When I restructure it for the import, I have to do the same for the export. It's a slow-and-steady affair but totally worth it to see the addon being used. Additionally, a very generous user donated a BeamNG license to me. I'll finally be able to see the other side of the magic as well. Got a lot to learn.
Glad I am able to help. Also, the good news about that simple truck is that not only can I answer any questions you may have about it, but it's so simple just about anyone that has done JBeam modifications for Beam should be able to read and make sense of it. That way, if I am not here for some reason to answer a question, just about anyone can pick up the torch and read the part you need help with to answer the question. Also... to possibly help with your exporter, I also included (and forgot to mention) with that file a .blend file of the truck I created in blender. I used the much older blender exporter (just because I had that installed already) to make this thing as quickly as I did (I hate to admit it, but there is only about 10 minutes of work in that truck) That is why the nodes are named as they are... not because I wanted them named some specific way, but because that's just how the exporter named them.
Quick question. I can't find it even after reading through a dozen or so jbeam files... Say a jbeam has 2 or more node groups (or beam groups or coltri groups) with different values of properties. Like collision, selfCollision, nodeWeight, nodeMaterial and so on. How would those be declared? Would one simply redeclare the properties like so? Code: {"selfCollision": true}, {"nodeWeight": 1.0}, {"group": "group 1"}, ...node1, node2, etc {"selfCollision": false}, {"nodeWeight": 0.4}, {"group": "group 2"}, ...node3, node4, etc If that's how it's done, then am I right to assume that any property that is not redeclared is taken from the previous group's declaration of that property?
Yeah, until there is new declaration or emptying declaration by declaring for example {"group": ""}, then previous setting is valid as long as node definitions are not closed. Now, there is two ways of declaring groups, one is how you have written, but also it can be declared on same line with node definition like this: ["a41", -0.278288, 0.554826, 1.28002{ "group":"No_Group", "selfCollision":false}], Another bit that can be tricky are headers, like this: "nodes": [ ["id", "posX", "posY", "posZ"], That defines an array in which data must be given, no missing inputs allowed, but in theory you can have this or even some other data elements: "nodes": [ ["id", "posY", "posX", "posZ"], With props definition it is common to see bit different headers, can't remember anyone actually changing that for nodes, but it is good to know that header is not there for human readability, but for defining an array data slots. I'm not sure which are all possible values for header, but maybe for simplicity's sake, it would be better to just limit supported node array to that most common one. Also any line that comes after previous overwrites previous one, if data is same, so if there is a node2 and next line defines again node2, last one will overwrite first one. There might be more to it, but my limited understanding is this much. --- Post updated --- Also one thing that can get tricky, you have two files, node2 is defined in file1 and then there is another part of the car, which is loaded from other file after node2 is defined, this node2 definition in later loaded file will overwrite first definition. I think that NBeditor places then both of the nodes with same name on the screen in two positions, unless my memory lies to me horrible. This happens usually if there are different suspension options, so different parts might position suspension connection points a little.
That's actually more correct than you know... It will literally keep the last property defined right up until there are new properties defined even if it is across JBeams. For instance... while making that truck, I defined the shocks in the front axle as one of the last lines of the beam section. That loads before the rear axle, so when the game loaded the rear axle, rather than using the default properties, it just kept on chugging with the properties from the previous file. That basically turned my rear axle into a floppy noodle rather than something solid as they were all now shocks rather than beams. This is why it is always a REALLY good idea to redefine the Beam Properties at the beginning of every Beam section. I wouldn't doubt that the nodes section works the exact same way as well... I haven't had any issues with them yet, but I don't doubt that they would work the same way. Perhaps for safety sake, it could automatically define a new set of those parameters for each group we create... then we can either just leave them as they are, or define them as we wish. Granted, that's more for the in blender builder and exporter and not so much the importer as I am sure that not all groups will have these parameters defined for them before importing.
Thank you for all the info It helped a lot @fufsgfen, that additional bit about the headers and also the part on group declarations couldn't have come at a better time. I was hard-coding the positions of the headers (ie. 0 for node IDs, 1 for x position, etc). Now I can take that into account and make the import a bit more flexible. @atv_123, yes, sounds safer to redeclare every property at the start of a new group during export. The import is actually where I'll need to account for files that do not follow the safe recommendation. The export has already just been modified to redeclare everything. I'll push the update in a few hours. A quick tip. Before we get to a point where we can consider an update system for the addon, for those who wish to be informed of new updates as they happen, Bitbucket has a "watch" feature that alerts you to new commits. As always, keep in mind that it may be buggy and always test with files you have copies of.
For me it just says "Import JBEAM" --- Post updated --- and then when i try to import it it just give me a "TRACEBACK" error (starting to get angry here)
Importing jbeam is buggy, what you need to do is make skeleton from edges and vertices in Blender, then add those to this addon by selecting jbeam mesh you created, then clicking skeleton, then you need to assign groups and set values, finally you export it all by clicking file. You can import jbeam, but it is complicated, you would need to edit file according to error you are getting, it gives line number and it might need more commas or something to that spot, then try again, get new error, edit again, until jbeam imports, but that is not needed when building jbeam from scratch. Then attachment of your part to car that is what you need to do in Notepad++, you need to use debug mode in game and see node names, then make beams between your part and car nodes to make it stay on place.
Have you selected a mesh and scrolled to bottom of N panel? Also you must not be in edit mode, then after you hit skeleton, you can enter to edit mode.
