Be able to increase/decrease quality of JBeam skeleton

It would be cool if there was the ability to increase or decrease the number of nodes and beams a JBeam skeleton has to increase/decrease the quality of crash physics in the game (through a UI app or option menu) without having to modify the JBeam files to do so. I'm not sure how you would go about doing this, especially decreasing quality. But in terms of increasing quality, below might work for a triangle case:



So I believe you would add nodes at the midpoint between each pair of the original nodes, reconnect and add more beams, and decrease the mass of all the nodes and the stiffness of the beams by a factor of 2 in this case, so that the whole skeleton still has the same mass and properties.

 

I'm sure it is pretty difficult to manually edit the JBeam files by hand. But after all the JBeam files are loaded in memory, so you can use Lua to create algorithms to do the heavy lifting for you. And so the only hard part is finding an algorithm that is able to interpolate the nodes and beams.

And when I was saying "quality of crash physics", I was talking solely about the deformation independent of game performance, so it would definitely improve it. Not everyone has a potato PC so some people could definitely benefit from it.
--- Post updated ---
And I have used an algorithm in the past for generating simple shapes, being able to specify how many nodes I want the shape to be made out of. And this was for when I was trying to create a soft-body physics engine. The algorithm is able to generate a square and a circle. So it isn't interpolating actually, but parts of the algorithm could be used to interpolate a soft body. Obviously it isn't impressive and you wouldn't be able to use the code to interpolate an entire JBeam skeleton already, but the point is that generating nodes and beams from code is possible.

Github repo (Eclipse Java project):
https://github.com/angelo234/Soft-Body-Physics-Simulation

File with the algorithms in the methods: generateCircle() and generateSquare():
https://github.com/angelo234/Soft-B...c/com/angelo/springdampersim/physics/Map.java

 

This just makes no sense at all. First of all, there is no way to "mathematically calculate" where the beams for the new nodes would be to ensure the entire vehicle would be supported properly without structural stress. Second the whole weight distribution would easily get messed up even after making an algorithm to keep the weight itself the same, and in this case all the beam values would have to be readjusted to new weight. Doing this mathematically is not as good as manually and it would deform like an Automation car. Next, have you even thought about engine nodes, camera nodes, rigidifier nodes and such, basically all nodes that CAN'T have anything in between? How would the algorithm know this? Next, deformgroups, they would all get messed up because of the absurd amount of extra beams that would get added. Also, what about breakable beams? If they recieved nodes in the middle, then either only half of the old beam would break afterwards and the node is left hanging mid air, or the whole and then the node just falls off and stretches the mesh. While we're at it, if a beam connects 2 nodes that each belongs to a different group, which group should the new node inbetween be in? Also, there are some areas where nodes shouldn't be for modeling reasons, it would cause spiking, stretching, etc. There is no way the algorithm can know that so it would happen. Also, would suspension recieve new nodes too? With the way it's tuned with extreme precision, changing it would likely make the car explode if anything goes wrong which can always happen. And what about areas where nodes are already really close to each other, like bumper edges, pillars and such? Adding more nodes there would create a mess. Generally there will be hundreds of new unneccessary nodes and THOUSANDS of new beams... How many? First, the nodes. Let's assume an average vehicle has 1500 nodes (counting only from the parts enabled at the same time), seems reasonable to me. Your example shows that each step in the " complexity slider" would increase the amount of nodes by 2, considering all I said the algorithm could somehow be VERY smart and somehow not add nodes in places that are not necessary, and let's assume we're REALLY lucky and it "only" increased the amount of nodes by 1.5. If we multiply that by 1500 we get 2250. That's the first increment step. Then 3375 and it's already getting dangerous, as the max amount of nodes per vehicle that can be generated at the same time is 4000, and it's about as much as the CrashHard 8x8 has... we can't go any further. Next, the beams. How many beams does that add? The optimal way to add beams to a flat node surface is to triangulate the surface and add a rigidifier. So we have a beam for each node on the edge and then beams in the middle, about half the amount of edge nodes, and then an extra beam for each node to rigidifier, so we can assume it's 2.5 the amount of nodes per part. Only if it's a simple flat part like a car panel without any depth to it, in that case we get WAY more. Let's assume, again really optimistically, that the car we are trying to "improve" is only made of flat surfaces like this somehow and has an average amount of beams. How much is it? According to the documentation there are 280729 beams together in all vehicles/trailers/props. Props have way less beams than vehicles so we can leave them out, there are 35 vehicles/trailers so like 8000 beams per vehicle would be reasonable. So moving the slider once would increase the amount of beams 1.5×2.5=3.75 times. So the car would have 30k beams now. That's about 10% of the count of all beams in the game... in 1 car. Second step, we get over 100k beams already, that's almost half the amount of beams in the game... and remember that's THE MOST OPTIMISTIC SCENARIO POSSIBLE, which can't really happen at all, in reality it would probably be 5 times this amount... IMAGINE THE LAG OF THAT. While the first increment step wouldn't be THAT bad, the second would be comparable to the CrashHard 8x8, the laggiest mod ever!!! So conclusion: Not worth writing an ultra complex algorithm where a lot of stuff can and WILL go wrong only to get ultra mega lag and many bugs in return, with a slight increase of realism that would be ruined by spiking anyway because the algorithm can't know how to avoid that.

 

You know what, I accept defeat lol . Yeah I think I should have learned more about how the whole JBeam system works and thought more about it before posting this...