Possible to increase simulation time steps?

I'm not sure if this is the proper place to post this, but is there a way to increase the accuracy of the simulation? Not that I don't think it's accurate enough, I just enjoy pushing things to the limit. I heard it runs at 2000hz, even if I have to run the game in slow motion I'd love to see the effects of upping that figure.

 

It’s not really gonna work that way since the game engine is designed to run at a certain speed. The way to make the crashes more accurate is to up the density of the collision body’s (JBeam). Which I think should be done, since they aren’t very accurate or dense. Small dents are impossible, they gotta be like three times as thick.

 

Would be awesome to see that. I feel like the node and beam model would have to be subsampled or something like that. Not sure how it works.

 

some sort of dynamic JBeam Subsampling would be cool, but would only be available to people with a more powerful computer. Also, how would fracturing work?

 

Way beyond my knowledge. Was hoping to just increase a value in somesort of text file lol.

 

okay I don’t mean like, down to the atom dense, I just mean instead of 5 node widths across maybe you do 10.

 

Okay I’m just saying as an experiment why are you people like this

 

Because you're basically asking people to do stuff that would take years to make just to satisfy your curiosity. There are reasons why this is not doable and even if it was it's not worth it.

 

bruh goes into defence mode so quick

 

The simulation time step at the moment is hardcoded I believe. I think I heard that the devs did play around with different speeds, but ultimately, 2000Hz proved to be the best balance between performance and realism. (don't quote me on that, I just seem to remember reading that somewhere on here before)

RoR used the same 2000Hz time step, and honestly, I am not sure why pricorde originally settled on 2000Hz. If I had to take a guess its because, at the time (around 2005-2006) peek computers were getting into the 2.0 to 2.4GHz range on their processors. Plus, anything below that simulation step, and things have to be built so darn heavy that they usually just ended up exploding if they were made any lighter. Some of the machines were very heavy in the early RoR days because computers just weren't up to the task of hitting that 2000Hz calculation speed.

Naturally, originally, when it came time to make Beam, the dev team just started with what they already knew worked... but if I recall correctly, I swear that they made mention that they tried other frequencies. Technically the higher the frequency, the more stable the structure would end up being (at a major cost to performance). This 2000Hz is why making things really light (think carbon fiber for instance) is so darn difficult to make with the high node density's that the devs like to use to get all the detail that they already do. The higher the node density, the lower the node weight, and the more likely for the structure to become unstable.

If you have ever had anything become unstable in Beam (or RoR) and explode on you for seemingly no reason, it actually does come down to that 2000Hz calculation speed. If you make a node light enough, and a spring rate connecting it high enough, the node becomes capable of cycling at a frequency FASTER than the 2000Hz calculation cycles can keep up with. So basically the spring rate is so high, and the node mass is so low, that it can cycle from one extreme to the other in less time then the game has an ability to run the single calculation. This can cause the node to become "out of position" to where it ends up being somewhere where it shouldn't... so then the game calculates the spring, damp, mass forces that that out of position location would cause (which are much higher then it should be experiencing), which then causes the next cycle to have it WAY out of position on the next cycle... and this just keeps getting worse and worse until things blow themselves to bits.

This actually works for the collision triangles too. The higher the frequencies of calculations, the more likely the node is to "not" penetrate the collision triangle... and thus less crash welding.

Unfortunately... to start stepping up the calculation frequency would probably make for a pretty hard hit on performance... and my bet is that it wouldn't be a linier performance hit... but an exponential one. So 2000Hz was settled on as it just gives the best accuracy for the FPS... that would be my guess anyways.