Re: Real-Time Vehicle Editor UI overview - Part 2Alright I can finally give you some concrete overview of vehicle edition. This video contains only the features that are fully functional. Many others are already in progress. Just be patient. What is already functional: open & save (save as) vehicles select vehicle file & vehicle part from grids add vehicle files & vehicles parts in grids modify vehicle part information modify vehicle part global settings (beam scales for example, I still need to make that unique and propagate the modification to all vehicle parts) modify & add / remove slots + define the parent slot define the ref nodes if applies by selecting existing nodes reviewing nodes in a grid + adding / modifying / deleting directly from the grid defining / modifying node properties The next video will include the game control. I didn't include it into this one because it's not complete yet. Will allow you to start or close the game and execute a few commands on it (like pressing escape to close menu or resetting car & LUA). Plus it will allow you to switch to debug mode to see nodes etc...
Re: Real-Time Vehicle Editor Still working on this. Having some hard time trying to figure out the whole syntax: what is allowed and what is not, what must be present and in which conditions. I really need to be able to open and save everything before being able to really play with the UI because I can't presently do real-time tests. I just can't "compile" a vehicle entirely without a single issue yet. For example the wiki stands that you must close any "group" you started but I don't see why you should. For example in beams you start a "breakGroup" then put some beams. If you reach the end of the beams section why would you need a "breakGroup:""" to end it ? It will not refer to anymore beams so it would be important IF you were to add more beams but if not I think it's useless. Please correct me if I'm wrong. Another big question I have is: should I care about the sections that contain properties without any object ? For instance a "hubWheels" section would define a "propulsed" property but no "hubWheel" element. In that case my guess was I could simply drop the whole section. Would that be wrong ? Thanks to anybody replying to this .
Re: Real-Time Vehicle Editor I'm under the assumption that the "hubWheel" is part of the mesh and doesn't get defined in the JBeam. You should see what happens if you remove the section as opposed to having it in there. But either way, I would leave it in. If the developers put it in, it must be right.
Re: Real-Time Vehicle Editor Thanks for your reply. You see I need to extract the data in a logical way. I build classes out of that and once you save I have to compile new jbeam files in the way I think is best and can be done with the info I have. so the question here was not about knowing if I should remove a section I would prefer to. It's because my logic is based on the fact that the beams section must contain at least one beam to have a reason to exist and same for some others including hubWheels. In the editor if the user removes all the beams or adds some when there weren't the output data must either contain a section or not contain one. So there are rules I need to rely on to get everything working right. I just need to define those rules... As an example after reading the beams for example I have a 'Beams' object which contains a list of beams but also different lists of properties indexed on a beam index. So that if I store a property 'selfCollision' for example for beam 0 it will remain in use for the next beams till the next 'selfCollision' property in that list. If that property in the file was defined after all the beams it cannot be linked to a beam index and thus will not be saved. This kind of logic allows me to provide an easier way for users to play with data inside of the editor. - - - Updated - - - Real-time interaction demonstrationAs promised this video shows how to start the game within the editor and how to interact with it. As an example here I simply opened the pickup and deleted a node from the front-right wheel. Then when pressing the Update button from the game control you can see the vehicle is updated immediately. The Update button actually saves all the files and then sends an input to the game to reload the vehicle in place (Ctrl+R). More to come... If you read my previous message I can tell you that I can now save everything right. Some sections do require properties without elements (aka JObjects without JArrays in children). It was crucial for the video I just made as I need to update the whole vehicle jbeam data before reloading it in-game.
Re: Real-Time Vehicle Editor This is absolutely epic!!! The amount of years I have waited for this in RoR was ridiculous! However I am much happier to see it for this game now! That being said, I do realize that this is an 'editor', however, I think that there is one more feature that this editor needs before it is perfect. I don't know if it was suggested before, or if it was planned, I'll admit, I only lightly skimmed the thread, but I think that an editing window in similarity to the RoR editorizor that we had way back in the day would be epic and completely top the cake on this one. That 3 window top, front, side, format that allows you to physically select a given node and then proceed to move it to a desired location by just dragging it there would be the easiest way of manipulating these vehicles. That along with the instantaneous feedback from the game just adds to this epice awesome cake we got going on here. If you do do this (has fingers crossed) then there were only 2 things that I could see that need added to the features that were already in the editorizor. The first namely being able to start from scratch and not having to load a file with a node in it first... many a great creation was lost that way... And also being able to select multiple nodes at once and be able to move and scale them on the fly like the in game editor for RoR used to have all the way back in RoR 0.29... I still use that because I like it that much. Other than that, I can't really think of much else to make this any better than it already is! You have some epic work going on here!!! Don't stop!!!
Re: Real-Time Vehicle Editor I've really been looking forward to seeing how the editor would work in game, I've got to say this looks just about perfect! The UI looks really simple and well laid out, I love how all the sections of the jbeam are separated and easy to see. I started a mod awhile ago that I stopped working on because of how annoying it is to edit N/B structure out of notepad, your editor is going to be such a huge help to the modding community! Really awesome work Greg thank you. Edit- Will there be a way to create new nodes in the editor as well as editing and deletion? I didn't see any way to add a new node in the video, so just wanted to check.
Re: Real-Time Vehicle Editor Are you talking about some in-game editor ? Because this is not what it is sorry. This has an in-editor game instance which is the contrary. I couldn't yet make an editor using Torque or LUA. That would be different and maybe for later. BUT I can and will probably provide some controls that will make it easier to move nodes etc... But you will always have to press that Update button (or a keyboard shortcut) to see the changes in-game. Otherwise it could be too much resource consuming. I could enable it for big machines though but that would still lag you out I think because each time you update you actually re-save the jbeams and reload the vehicle in-game. If BeamNG guys provide a command other than 'Reload in place (Ctrl+R)' that instead of reloading a whole vehicle allows you to specify what to reload it could become easier. But as I said I can make some mouse-controlled 2D controls with some axes that will help you visualize a little better how you're moving things. As for Starting from scratch you can actually already do that. You just need to open the left window with the vehicle files and parts (which is empty by default) and you can start adding new rows as you want to creates files and then parts in those files. Then as always you can open a part and configure it and start adding nodes / beams and other stuff. - - - Updated - - - As for the files and parts you can already add new nodes / beams and soon other stuff. You just need to click the last row of the grid (with the *) and it will create a temporary row that you can configure like others. When you click the button that will be in place of the delete button (blank instead of having a cross) it will validate the new row). That's it. Works for new files, new parts, new nodes and new beams currently. Planned to be usable for other stuff too. If you see any better approach to creating or modifying stuff please let me know. I still have to deal with hubWheels, hydros, engine stuff, differentials, and the others I forgot. Cameras are already in progress. External camera works fine. You'll see that in the next video. And maybe it wil be the last one before the first alpha-release. Thanks for your support .
Re: Real-Time Vehicle Editor I wasn't talking about an ingame editor, but more something like this http://www.rigsofrods.com/threads/8...am-Editorizer-Tutorial-1?highlight=editorizer check out that thread to see what I was getting at... really it is just a simple environment that allows you to easily create and manipulate N/B structures. It also allows for you to create wheels, hydraulics, and define different types of nodes. It was a great little tool back in the day, but now it is severely dated and missing many, MANY features required to make a proper mod without having some serious know how... not to say we cant learn it. Anyways, I was basically asking if you planned on adding an environment like this to this spectacular editor, and not as an 'in game' portion of the actual game either. Back in RoR 0.36 I believe it was (correct me if I'm wrong) they had a true in game editor... like it would pause the game where ever you want and allow you to add nodes and beams on the fly. Cool feature and all but when you take into account the forces in the vehicle that where already there, then add them to the new unstained structure and you just had a recipe for disaster. I was more looking for the editorizer environment to be added into your editor so that we could quickly build a vehicle, save it (thanks for that by the way), load up the in game window that you have working so nicely, get into your vehicle, then let the editor really come into its own by allowing us to tweak properties and test them on the fly. So in other words... I was just looking for this feature for large structural changes and not so much instantaneous in game editing with it... that is for the fine tuning. This will be the savior of many creations... as simple of a feature as it is... it is something that I was always plagued with in the editorizer. Anyways, it sounds like progress is rather great and will be looking forward to every update
Re: Real-Time Vehicle Editor Ok thanks I see it more clearly now. I won't start saying that I will make that kind of editing possible and anyways it's not gonna be in first releases for sure. But I did some 3D programming in the past and with enough of time I can tell you that I could make that (even the 3D view). But I'm really not gonna be into such things right now. For that we'll have to see how it goes. Could you please describe what "different types of nodes" means for you ? Maybe give me a few "concrete" examples ? I'm desperately seeking information related to how people create vehicles and how they think when they do it. What they would do first and how and why. And what's next and what should depend on what etc... It's based on my own sight of view that I decide that users should do it this or that way. But that could totallly be wrong. So you (users) are going to start using the tool and tell yourself that it's not very user friendly after all (like for the nodes and beams here). I would feel so much better if some could let me know more about the different things to do and why they are important or not etc... For nodes and beams I get it of course. But there are plenty of other things for which I ignore the real use of. For example I could say: how do you create wheels ? What does your structure need ? How do you choose how to build that structure ? PS: I put your link in favourites
Re: Real-Time Vehicle Editor I apologize if there are misspellings in this post... I am quite possibly the worst speller in the history of foreverness... and not even spell check can help sometimes so bear with me... and if you don't get what I am talking about just ask cause this took me forever to write and I probably got lost myself. Either way, with or without it, this editor is gonna be nothing short of epic, so kudos to you! I would love to... Now back in the day with RoR the nodes had several different types that could do different things on the vehicles. For instance some nodes could be set up as: contactor contactor nodes are for if you didn't want them to come into contact with anything (mostly used for behind the scenes physics trickery, but can be used to raise FPS I have been told) hook hook nodes allowed you to latch onto other hook nodes... useful for crating 5th wheels and tow hitches. bouy bouy nodes have buoyancy on water, this was used mostly for making floating things before the special coding for boats came out. exhaust Exhaust nodes were exactly that... exhaust's. Exhaust particles would be released from this node in the opposite direction of the exhaust reference node which is usually placed in the direction that the exhaust is coming from. no particle No particle is also just as it sounds... when it would come into contact with the ground or surrounding objects, no particle effects would be generated. (I personally have never used them) spark Spark nodes are pretty simple... they spark when they come into contact with pavement... kind of like metal. Fixed Fixed nodes are nodes that when they are spawned into the world... they will never move. They are 'fixed' in place. Useful for making cranes on docks, bridges, buildings... pretty much anything that doesn't move. but can still flex. slide slide nodes could slide along a beam or set of beams in a rail group. These were most commonly used in tracked vehicles like tanks and what not, however the possibility's are practically endless for their applications. You can use them for sliding doors on vans, McPherson strut suspension, extending entity's (ladders and what not), windshield whippers, speed sensitive wings, and Lifter (guy on the old RoR forums known for his mechanical wonders) claimed that he managed to used them along with his triggers to make a mechanical ABS I do believe I remember him saying. Of course there were more, however, I am not gonna go through them all and for a reason. I am not very familiar with this new Jbeam file system. I don't know all the different types of nodes that have been implemented yet. I do know that slide nodes (if not here already) will be implemented in the future. I also know that while the nodes may not have different types like I listed above, you are able to select the different types of materials that they are made out of. I would, again, help with that more, however the wiki page stating what is what has not been created yet... although there is a link to it if anyone wants to shed some knowledge on us all. http://wiki.beamng.com/index.php?title=Options&action=edit&redlink=1 So when that information is discovered, that will be BeamNG's differing types of nodes. Again, I would love to... Now, as you know, everyone's process is going to be different. So I will post my process, then I encourage everyone else to do the same... and we can add together the similarity's and see if we can get a process going here... almost like a step by step list. Model Build the whole vehicle in Blender or your favorite 3D modeling program making sure all parts are separate so that they can be exported seperatly. Create Base Chassis Back in RoR we had a little tool that you could use in Blender to create a N/B structure right alongside (basically inside) your mesh of your vehicle so that all parts would be the same size and would fit. Test Chassis in Game Now that you have the basic structure down, stick it in the game... does it explode? Yes? Needs some changes... No? Well great! Moving right along then! Add Chassis Mesh's Take the mesh of the chassis that you made in blender and add that onto your N/B chassis. Test in Game Check that you have it lined up EXACTLY! If not keep changing the mesh coordinates till you get it right. Add Suspension and Steering Components Biuld all the suspension being shocks, a-arms, axles, trailing arms, swing axles, leaf springs, steering system, tie rods, anti roll bars... the lot really. Test in Game Again... just make sure nothing really explodes. Add Wheels (was always tricky in RoR so this was its own step for me) Add the wheels to your suspension... not really hard in itself, just 2 node numbers really. The settings however to get realistic wheel weights was a PAIN to get right Test in Game Again... make sure nothing explodes, if it does repeat last step. Build on All Fenders (DO NOT ATTACH) I like to then go and build all of my fenders into there proper places on the vehicle making sure to line them up with the mesh exactly. Then building all their little sub structures accordingly. Test in Game (test for fenders structural rigidity and flexibility) Mess around with the fenders, make sure that they don't collapse and are structurally sound on their own. (again, preferably without exploding) This was much easier to do in RoR seeing as we could grab onto the structures nodes and swing it around with our mouse to get a nice feel for it. Connect all Fenders Properly Is rather self explanatory. Add all Fender Mesh's Take all the different meshes for your fenders and add them to their corresponding N/B structure. Test in Game Again, make sure that they are EXACTLY aligned because you want your work to be good. Otherwise go change the mesh coordinates and try again. Fine Tune Handling and Deformation Properties(Much in Game Testing) This is the part that really takes a lot of restarting of the game. Basically you set up your vehicle and test it. Then you go and change some properties in the set beam defaults and the suspension and test it again. Repeat until you have your vehicle dialed in perfectly. No slacking. Add Finishing Touches Basically add in all the fun stuff like the lights, animations for shifting, animations for turn signals, opening door handles (depending on how far you want to go) so on and so forth. That is how I do it... granted like I said... with RoR, you had to do a TON of restarts which takes time... that is part of the reason that I still haven't finished crafting my Bugatti for RoR yet, because those restarts do take time... I bet over the life of that car I have restarted about 10,000 times... may be more. Also, that is my biulding process for RoR... now that we can have different part groups in this game for interchangeable parts I would imagine that I would modify my process slightly to include them into the mix along with when I attach everything, to make them use those new deform groups as well. I hope this helps even just a little bit. Your welcome
Re: Real-Time Vehicle Editor Thaks a lot for the time you took to reply here. That will definitely help. Concerning the nodes I guess those RoR things will not make much sense anymore here. But as you said there is the node material still. I think 'types' would more apply to beams now as beams actually have to define a type (normal, bounded, anisotropic, support, pressured, hydro or broken, see Beams). As for your building process I suppose it's not all Gabester does as I saw many more things in his vehicles but it's really nice to have a sight on someone who does it. There are actually plenty of different groups (sections) and for some there is some description on the wiki but it's not really that clear to me what goes with what etc. Here's roughly what I know in short: general properties (authors & name + parent slot and global scales) slots (available slots for potential child parts) refNodes (only in the main file to define an origin if I got it right) external camera (the orbit camera that provides the external view) internal cameras (that are fixed to some nodes and can react based on some configuration) props (I'm guessing you refer your model meshes with the names you defined in the .dae there and apply some modifiers to them eventually) glowMap (for light materials switching etc..) nodes (the nodes...) beams (the links between nodes) hydros (hydraulic-like stuff, basically for steering currently as I could read, later for opening / closing... well any 2-position things that could be set on or off) hybWheels (to define the wheels, I saw sometimes 'propulsed' is defined in the suspension, I guess it's to define the property for any potential part that would be put as child with the part configurator, so you got to change the whole suspension if you want to switch to 4WD etc...) flexbodies (as it is a link between a 'mesh' and some 'groups' I'm assuming the mesh is from the DAE and the groups and the parts ?) differentials (differentials...) engine (there is a lot of potential information in the 'engine' section, some parts would contain some and some others would contain other, I guess it's partly meant for hierarchy matters, if some parts are replaced or break, but maybe not just that) engineTorque (well ok, torque per rpm for some meaningful values) triangles ?? ropables ?? ties ?? Btw you talked about a Blender tool that used to create your base structure. There is one here already too => MayaToJbeam-Visual-Jbeam-Editor-near-zero-typing (for Maya though). For the moment I'm having a weird material problem that seems to affect damaged objects. They pretty much all turn into broken glass as you can see from the screenshot. So I must have missed something in my saving process (or maybe even the reading). I guess it's coming to either flexbodies or beams with 'deformGroups'. I need to fix that before going further with the UI. Anyways thanks a lot abain for your reply.
Re: Real-Time Vehicle Editor To answer some questions: Triangles is the collision triangles for intervehicle collisions. The nodes must be ordered counter-clockwise for it to face in the correct (outwards) direction. Ties and ropables do nothing at the moment. As for how I've set up propulsed values: I do it this way so that removing the brakes, or the differential, or driveshaft, will cause the wheels to be unpowered and/or not have brakes. You could contain the brake torque and propulsion information within the wheel parts but that means you can't change the car's drive layout or swap in different brakes without swapping the entire wheel. It's not mandatory to put these values in separate parts, but I do it for this reason. It works because of how the slots are ordered - the brakes and differentials always load before the wheel. Same with hubcaps. And again, I reset propulsed, brake torque, and parking torque to 0 after the wheel definitions so that any following wheels will need to have brakes and differentials loaded before them to receive power and brakes.
Re: Real-Time Vehicle Editor Thanks a lot Gabester. You also helped me see clearer on those things. Now I know why sections can contain properties without any element. It's all a matter of hierarchy after all. Properties will be passed to the children parts as 'defaults' (or first properties). Btw I fixed my material problem. It was kind of related to these matters actually. I was not resetting the 'deformGroup' properties in 'flexbodies'. Now it's all good. As a concrete example for others wondering what I'm talking about: THIS Code: {"deformGroup":"pickup_doorglass_R_break", "deformMaterialBase":"pickup_glass", "deformMaterialDamaged":"pickup_glass_dmg"} ["pickup_doorglass_R", ["pickup_door_R"]], is not equal to THIS Code: {"deformGroup":"pickup_doorglass_R_break", "deformMaterialBase":"pickup_glass", "deformMaterialDamaged":"pickup_glass_dmg"} ["pickup_doorglass_R", ["pickup_door_R"]], {"deformGroup":""} even if your 'flexbodies' goup ends after that line. If the deform groups (or other grouping properties like that) are not closed like that they will (as I understood) still apply to the next child part in the hierarchy. Even worse and I don't know why it works like that but having 'deformGroup' not closed on the doors ONLY would apply them to other parts not related like hood and wheels... So knowing that I guess it will keep applying to ANY part defined later (alphabetically in other files) unless they define a 'deformGroup' themselves to therefore invalidate this one. Maybe the engine should work differently about that ? Maybe it should only apply to the hierarchy and not everything no matter its indentation level ? But now I do understand the statement "It's important to reset certain attributes when they're no longer needed, like "breakGroup" or "group". This can be done by setting the value to an empty string, like this: {"breakGroup":""}" that you can find here. - - - Updated - - - PS: just found a typo in "moonhawk_innerfenders.jbeam" > "moonhawk_innerfender_FL": Code: "nodes": [ ["id", "posX", "posY", "posZ"], {"group":"moonhawk_innerfender_FL"}, {"selfCollision":false} {"collision":true} {"nodeWeight":1.4}, {"FLictionCoef":0.7}, 'FLictionCoef' should read 'frictionCoef' I guess . Just so you know...
Re: Real-Time Vehicle Editor The way our vehicle spawning works is that it merges all parts in their appropriate hierarchy and then sends the finished compiled vehicle to the physics on the C++ side. All sections get merged. This is why you have to reset values after defining them, or set them inline. Yep, nice catch; a case of overzealous find-and-replace Fixed it for the next update. It shouldn't have made any difference since the previous part has the same frictionCoef but it's silly to have FLictionCoef in there
Re: Real-Time Vehicle Editor Can't really say yet. But I can tell you that now I have no longer problem with opening and saving the full data of vehicles. So it's just about UI now. But that takes time too... I'd like to have at least the ability to create / edit the whole contents of a vehicle before releasing. Also I need to make sure everything works well on a side if you modify another one etc... Takes a lot of testing time. So please be patient.
Re: Real-Time Vehicle Editor if you could make the data easier to read because at the current point when I do editing files I feel like jumping out my window because the numbers REALLY confuse the hell outta me...I mean if thats at all possible...but if not I will struggle on..
Re: Real-Time Vehicle Editor That's my main goal. But to get that to the best I can I will need a lot of feedback. In the first versions you will probably think that it's not so far from what you see in the text files. But I'm trying to group things in a logical manner as much as possible. Which is why I need to know what is logical for a vehicle creator. When you'll put your hands on the first version I'll be glad if you tell me what you dislike in the way things are working (and always fell free to also tell me what you like ). Having read Gabester's comments I fell like the app should provide a global overview of the vehicle more than a per file / part view. But that would be pretty tricky because the user must always remain able to place what he wants in the file he wants and the section he wants. Also I tried to make some user-friendly controls. I didn't simply use the WinForms default controls as they are. I already spent a lot of time on making custom adaptive controls and worked a lot on data bindings too. Also the popup windows that I use for example to allow to quickly select a node or anything from a list is one of the things that should serve the most useful purposes (links between data, for example selecting a node from a list instead of having to manually enter the ID). And this particular example is what I'll need the most feedback for because I'm not quite sure about all possible links yet. So if in the app you encounter some values that you have to set by hand and would like it in a popup-list that will be easy to adapt. I still have a few things to complete / fix and then I think I can just create the remaining section related controls (like one for hydros, one for triangles, ... most others are already ready). Then if it's all bound and working properly I should be able to release a first version. That version will not be complete and not the best solution I can come up with. Again the next one will only depend on feedback... I hope you guys see what I mean here and hope you understand that it takes time (and that this is not my whole life either).
Re: Real-Time Vehicle Editor why dont you work along side the Dev team behind the game and get their input into this project I mean that would be a big benefit to your project?
