0.5,like it is in Spring
EDIT: both rails and wheels are 0.5 elasticity
Your rails are rigid, meaning they have corners and edges in them. Having 0.5 elasticity means that every time you collide with an edge like this you eat ~50% of the energy projected in the direction of the normal.
The only reason this didn’t happen in spring is because spring treated the rails like a stiff noodle, where the spring would re-project momentum even with a super low elasticity. So yes, if you have rigid edges that the train is colliding with all the time, yes you will be losing momentum/energy.
EDIT:
If you have any stabilizers underneath rails/trains that make sure the vehicle stays on the track you have to make sure that has an elasticity of 1 with a high elasticity weight, and a friction of 0 with a high friction weight (the friction weight doesn’t matter if you made the rails have a friction of 0).
It was originally a issue to get the rides working without Legacy, but with NWSpacek’s suggestion that part is worked through. (Sortof.) Will PGS be optional? @Khanovich
There are no current plans to make PGS required, however the spring engine may not receive some new physics features (as new ones coming out will require PGS). Basically the spring engine is treated as Deprecated.
If there is ever a plan to remove the option to turn off PGS, you will hear about it as an announcement.
I found an error in the tests I was doing with PGS. I was using a train that did not have the proper gravity applied, so I applied the proper gravity and re-tested. Here are the results:
EDIT: the test parameters included 0-elasticity rails and wheels, except for upstop wheels which have elasticity of 1 and ElasticityWeight of 50.
11.9 seconds seems like a lot. But having a difference in behaviors overall is not surprising.
If you remember this place: HighPressureToLowPressure - Roblox (Try it in Studio, playing the place doesn’t work due to network interaction) where I tested a closed system that simulates an idea gas using spheres to represent molecules.
Running this place in PGS did a fairly good job of conserving energy of this closed system, however with the old spring solver this was not true as the energy of the system would go all over the place. Spring solver stole and then added energy in weird places, especially if the interaction was complicated enough to where the springs weren’t stiff enough for a correct simulation. Trying to do experimental measurements on friction with the spring solver made no sense as the results were never predictable.
With PGS you can slide a block down a 45 degree incline and measure it’s acceleration to try to figure out the coefficient of friction between the two objects experimentally. This was IMPOSSIBLE with spring solver. It makes sense that the two solves behave differently, and if you’re used to tuning to spring it makes sense that you may be annoyed by having to re-learn the ins and outs, but that doesn’t make PGS a worse engine if Spring had a whole bunch of issues that you simply were used to.
Usually spring engines are use for Finite Element Analysis, which is something used in engineering to approximate behaviors of mechanical engineering drawings by simulating forces on them. These applications usually DON’T run in real time because they require MANY MANY Iterations to simulate a fraction of a second. To make the ROBLOX spring solver run in Real-Time, the number of iterations was cut down. With this cut-down you get a less realistic model of the world. But it was a model of the world you are used to work with even if it was wrong.
1 Like
Actually, I’m glad we had this discussion. This part was especially helpful:
I had forgotten that I changed the Elasticity when I first played with PGS, and this reminded me. Additionally, setting the Elasticity also changed the behavior of the trains I have been building for the better. Unfortunately it didn’t completely get rid of unwanted behavior when using block guides, but I didn’t see any of the immediate problems that I used to.