1. The forum will be closing soon permanently. Please read the announcement here

Note: User registration has been closed. We do not accept any new accounts.

# Fix the Physics : use relative reference frames

Discussion in 'Suggestions and Feedback' started by BrickedKeyboard, Apr 8, 2014.

This last post in this thread was made more than 31 days old.
1. ### AracusSenior Engineer

Messages:
1,931
Wouldnt adding a force multiplier relative to what your "speed" is when calculating collisions solve that?

Messages:
1,015
wat

3. ### AracusSenior Engineer

Messages:
1,931
In a scenario when we are using RRF to cheat the speedlimit, say we are going a km/s and collide with a ship, since we aren't really going faster than the engine can track we register the collision event. Then Instead of using the straight speedfactor which might bug the system? We just add a force multiplier factor to the collision calculation and base that on whichever "simulated" speed you were going at

4. ### extraammoSenior Engineer

Messages:
1,015
The problem is that the collision isn't detected properly. Not as much how it is handled when detected.

5. ### MaegilSenior Engineer

Messages:
1,633
Sorry for asking, but how hard is it for you to read the OP? The subject is also discussed elsewhere in the thread, you could consider doing us all a favour and read it, or at least skim it so you'll have an idea of what has been discussed.

• Agree x 2
6. ### AracusSenior Engineer

Messages:
1,931
Heh, its the shieldthread all over again with the discussion restarting because new people in the thread are stupid-lazy and stubborn with tl;dr.

7. ### extraammoSenior Engineer

Messages:
1,015
I've read the OP, I've read it over a year ago when it was first posted. The reason for this thread (solving buggy behavior at high speed) has already been solved. Yes people have addressed that collision is an issue. I'm stating that it is the only issue in the way of higher speeds and that all this push for RRF is misguided and useless.

You are so quick to jump on me when I state collision issues that you are missing the part about how your signature pushes for a fix to a problem that doesn't exist.

8. ### MaegilSenior Engineer

Messages:
1,633
If the problem does not exist, then be so kind as to install the lightspeed mod, make a satellite with extensible solar panels, put it into orbit, and extend the panels... Oops, you can't, a few updates back Keen blocked all rotors and pistons when the speed is over 100m/s so they won't explode... Nope, not a problem at all.

• Like x 1
9. ### extraammoSenior Engineer

Messages:
1,015
So... RRF wouldn't fix that so my point stands.
The reason why pistons and rotors have trouble at highs speeds isn't because the physics are buggy at those speeds, it's because those speeds are near the speed limit.

If you have a ship going at the max speed limit and you make it rotate, one side of the ship will be actually moving faster than the limit. If you have a rotor or piston connected to a part of a ship that is moving faster than the speed limit, the heads of the rotor or piston can't keep up since they are separate grids. To solve this, the made the grids fuse together at high speed. I don't think it was the best solution though.

• Disagree x 2

Messages:
1,633

11. ### extraammoSenior Engineer

Messages:
1,015
Okay, you misunderstand what I meant. RRF wouldn't fix what Keen was trying to fix by freezing the pistons and rotors at high speed. The fact is, we could raise the speed limit quite a bit right now if it wasn't for collision tunneling. RRF would only be helpful for very VERY large speeds which aren't really as important as having the speed range up to maybe 10 km/s. The ISS speed is 7.667 km/s.

• Disagree x 1

Messages:
198
Remove that damned banana!!!
Freezing is not fix, it is a stub really.

• Agree x 1
• Funny x 1
13. ### MaegilSenior Engineer

Messages:
1,633
I think you really underestimate the effect of speed on Havok. Let me put it this way:
First of all, understand that there isn't any speed limit except that put in place by Keen, and modified/abolished by mods (actually, according to this light speed mod there's a 1,000,000m/s hard limit, but that's a large enough number for all practical purposes).
Secondly, you confuse cause and consequence: stuff explodes because Havok spazzes out at high speeds, and to prevent that Keen first put the limits in place; people complained.
Thirdly, when Keen allowed for mods to break the limit people started to complain about exploding pistons and rotors again (or at least more than before), so instead of actually fixing the problem Keen locked the gear down; now people complain about the locked sub-grids, but Keen sees it as a lesser problem so they think they can get away with it.

Admittedly tunnelling is a problem at high speeds, but that is unrelated to the floating point spazzing, it has to do with the increase of the distance covered between timesteps: if a ship can move more than its length in each timestep, it's perfectly possible to be on one side of an obstacle in one step, and clear off the other in the next without triggering a collision. Still, you must understand that this only happens at much higher speeds: if you had a 10m ship and 60 steps per second, the ship would have to be moving at over 600m/s to have a chance of tunneling through a sheet of paper, or over 1200m/s to be sure of missing; to make sure two 25m ships would miss each other head-on, you'd have to have them at least at something like 9000m/s in combined speeds. It would happen to any ship at high enough speed, even those without any rotors or pistons, and regardless of RRFs.

Last edited: Jan 14, 2016
• Agree x 1
14. ### MaegilSenior Engineer

Messages:
1,633
Took me a minute to stop laughing enough to reply...and I'm still giggling.
All right, the banana is gone.

• Funny x 2

Messages:
1,787
Your game updates at 60 updates per second (UPS) let's say you are going 1km/s you travel 16.6m/tick in that time if you collided with something, you could potentially clip through that distance. The huge error there is your ship is now partially inside of whatever you collide with which causes crazy spazing issues.

What you are spouting is fundamentally wrong and not how the game works. Rrfs don't really fix these problems, you still are going to collide with something the same way and it will still destroy your ship.

End of story.

• Agree x 1
16. ### MaegilSenior Engineer

Messages:
1,633
May I recommend that you read what I actually wrote? I never made the claim that RRFs solve the tunnelling problem. Much on the contrary, I explained why is it that RRFs would do nothing for or against it other than allowing such speeds to be reached in the first place.

Last edited: Jan 15, 2016
17. ### SenorZorrosMaster Engineer

Messages:
7,063
one question, why don't they simply scan for tunneling? it shouldn't be that hard. simply draw a line with a magnitude equal to the velocity, look if something hits and if it does use the high-speed code, which is more or less simply removing an equal mass from both sides while slowing down*, until either one of the objects is completely destroyed, there is no collision anymore or the speed is brought down to a relative 208 ms^-2 after which the default engine kicks in. it may be a bit rough but generally no one should really mind that the ship is more or less destroyed than it should be.

• Agree x 2
18. ### extraammoSenior Engineer

Messages:
1,015
Contraptions moving at high speeds don't cause floating point errors. All that matters for floating point errors is displacement from 0,0,0. VRAGE already creates local physics zones, called clusters, that keep the displacement low enough to avoid the affects of floating point errors.

I recognize that Keen's approach to stopping exploding at the speed limit is not a good one. I was explaining why things explode near the speed limit and how, if the speed limit was removed, this wouldn't be the case.

Bugginess with pistons and rotors is because Havoc sucks when joints connect extreme mass ratios together. RRF won't fix this.

Unity physics has these problems as well so I'm waiting on this https://forum.unity3d.com/threads/ap...for-robust-joints-and-powerful-motors.259889/ before I can finish my game.

• Agree x 1
19. ### MaegilSenior Engineer

Messages:
1,633
I've already told you that you're mistaking cause for effect: contraptions moving at high speeds don't cause floating point errors; it's the other way around, floating point errors cause the parts to overlap with the main grid and explode.

There are two types of floating point errors: from distance, and from speed. Those clusters were not designed to correct floating point errors due to speed, but to avoid those related to the distance from the origin and to reduce the required memory. Before them, the game would kill you outright if you got too far from the origin to prevent out-of-range errors from the 32-bit architecture, and you could have at most IIRC seven asteroids; even 64 bits would still have distance limits.
Now with the the clusters you can travel from one to another without ever getting far enough for the distance-related floating point errors to come up. Moreover, due to optimizations, they are dynamically sized to allow the memory requirements be low enough for the weaker computers - activate the debug mode, and look at the lines defining large cubes; the cluster cubes' volumes are quite small on the planets, but very large in space.
Even if RRFs were to be implemented and we went back to a maximum of seven asteroids and no planets, the clusters would have to remain: the ship may be anchored at the RRF's origin, but the RRF itself could still move out of the maximum distance if there was no chunking.

Poorly balanced subgrids being being subjected to huge torques and torn off at high-G manoeuvres isn't a bug, it works as intended. I can't remember who, but another forum member once did a study on the behaviour of pistons and rotors, and concluded that often the problem was structural, not due to bugs. So, no, RRFs aren't some snake oil capable of curing all illnesses, and wouldn't help at all against poor planning and lack of balance; RRFs would only fix the speed-induced floating point problems causing explosions from grid overlaps.

20. ### YtramXApprentice Engineer

Messages:
238
That quote from BrickedKeyboard does NOT resolve the question about high speed collisions. Just because a collision is detected doesn't mean we've solved the problem. What then? We could probably have a secondary physics engine that will detect the intersection of two RRFs moving at high speed, but eventually they have to merge. If they merge when at high velocity and opposing directions, how can we hope to account for this?

RRFs are a great idea, and I'd love to figure out how to make them work. They fix a great deal of items that annoy the crap out of me like not being able to move around a moving ship. The collision question is not answered though, and that's enough of an issue that makes RRFs unfeasible. I'd rather deal with the game in its current state than have some janky collision mechanic that uses handwavium to explain why my ship is reduced to its component atoms when an extremity of my ship was struck by another ship.

21. ### extraammoSenior Engineer

Messages:
1,015
Please explain how velocity causes floating point errors. Unless the magnitude of velocity is greater than the current displacement, there is no corruption to the displacement once the velocity gets added. Have you done any projectile programming before?

22. ### PfoApprentice Engineer

Messages:
237
A line isn't good enough, but their is a proven technique in physics engines called Continuous Collisions that can sweep a collision shape along the displacement vector and find the precise time the collider needs to check for collisions to find it. It is very expensive in terms of computations, in frames where a swept shape collides it can double (and sometimes worse) the amount of calculations the physics engine needs to do. Consider that, and see what happens when large grids collide today in terms of simulation speed. It would however allow for a much higher speed limit with no loss of precise collisions.

23. ### PfoApprentice Engineer

Messages:
237
That's incorrect. Attached objects use these very complicated things called constraints, and they use extremely complicated mathematics, but the gist of them is they allow for one or more degrees of freedom and they keep objects together. They do this by calculating forces, so when object A moves and is attached to object B it's plugged into these constraints to calculate the forces to keep object B attached. These are the calculations which are suffering from the floating point errors, and it does not matter where you place the frame of reference: the magnitude of the forces will be the same, and the potential for floating point explosion remains. I've seen it before with every physics engine that exists. And @extraammo is correct, in games where you see these things working they very carefully balance masses and watch the center of mass and design it to work well not much unlike how you would in the real world. Sometimes they cheat, and deliberately make the joints never break or cause the objects attached via constraint to not cause damage to each other. Space Engineers does not do the latter, but if you look at guides for people who use rotors and pistons to great effect they always keep these facts in mind.

24. ### zorgkirillApprentice Engineer

Messages:
196
Due to ridiculous DS speed-cap bug... UP!)

Messages:
196
keeeeeeeeeen

26. ### Greyson_XMGApprentice Engineer

Messages:
132
Ok... I need to read all of this.

27. ### Kamikaze WombatTrainee Engineer

Messages:
3
I have an idea which may solve some of the issues that I see are remaining to be resolved for this to be workable and I would like to hear people's opinions on it.

What if we setup something like hyper drive in star wars or warp drive in star trek, where to go faster than 104 you enter hyperspace and while in hyperspace you completely ignore objects in space and just fly along. Make it drop out when you enter a gravity well just like in either of those universes to at least avoid people doing things like hyper drive into a planet. Could maybe even make gravity generators drop a ship out of hyperspace.

This should solve calculating whether there will be a collison when at high speed, what happens when there actually is a collison, and how people could be able to fight while moving at 5km/s. Also solves the issue of two fast moving separate frames meeting because unless they both drop out of hyperspace it won't matter.

Calculating when to drop out for a gravity well of a planet would be really easy if no maneuvering is allowed while in hyperspace, not sure otherwise (not enough physics knowledge.)

Might be cool if there was some mechanism to allow a fleet to enter hyperspace together and therefore end up in the same frame moving across space. Something like any ship moving faster than 90m/s within x meters of initiating ship (or inside a bubble projected from ship's hyper drive?) can enter with the first ship if their drive is powered on. I think ships should keep whatever speed relative to each other they had before entering hyperspace, so something moving at a random direction relative to the initiating ship will quickly fly out of the hyperspace bubble and drop out. Stations should probably be ignored.

Upon further consideration, I think the hyper drive should be a relatively power hungry item preventing it from easily being installed on small ships. Perhaps the initiating ship should not be able to maneuver while in hyperspace to simplify other ships staying in the bubble with it.

28. ### SpecFrigateBLK3Senior Engineer

Messages:
1,133
Hoo boy.

As I understand things from managing to read all thirteen pages, relative reference frames would focus calculation for close objects onto the client. This would enable players to walk around their ships.
The best way, it seems to me, is to lock the origin for each client's reference frame to the center of mass of the ship either last spawned at or last sat in.

Separate clients would need a way to quickly cross-check between and send movement data without the recently added middle step of the server determining position and sending it back. Or it may be impossible to sync clients like that, but it could be implemented in cases where there is only one player aboard a ship.
Landing gear ought to lock masses together in a single reference frame centered around the center of mass of all involved grids.
Additional autopilot functionality like flying in formation could facilitate a common frame around disconnected grids if no acceleration is applied. The moment the lead ship has any change in vector would inevitably desync the reference frame. This is also the case with any difference in velocity. Grid vectors would have to be absolutely identical.
EDIT: unless player input could affect the ship while formation autopilot mode is active, creating a sort of relative dampening effect.

29. ### Corundum GuyApprentice Engineer

Messages:
105
So two ships flying faster than 104 would ghost through each other? One ship flying faster than 104 could ghost through a station or slow moving ship? I can certainly see how that would reduce physics calculations, but for a game as big on collisions and physics as SE, that seems a bit odd. And if this ability is tied to a drive block that only some bigger ships can use, the beneficial effect of reducing calculations may be limited. Just my thoughts.

30. ### Kamikaze WombatTrainee Engineer

Messages:
3
The idea is when you engage hyperspace you jump straight to something like 5km/s and then just kinda ignore other ships. They won't be able to see you either until you drop out of hyperspace, which would again drop you back to whatever speed and direction you were going when you entered hyperspace.