Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Fix the Physics : use relative reference frames

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

Thread Status:
This last post in this thread was made more than 31 days old.
  1. ID10T_Error Trainee Engineer

    Messages:
    24
    If an object exceeds a 'defined maximum speed' then you may limit its collision detection 'dead time' by reducing the maximum iteration of time you allow to pass WITHOUT calling the basic distance collision initiator/momentum re-positioning functions for the 'over-speed' object. This effectively clamps the maximum distance an object can move without rechecking collisions/’physical location’ while preserving the integrity of the base collision handler, unless excess speeds lead to an overflow in another surrounding function. I hope you add/make this change and allow people to go over-speed, let them learn the hard way about the sudden stop problem.



    Also -> Making Collision Detection Lazy

    If an object is moving at 100m/s and another is moving at 100m/s and the object's distance from each other(I will detail the worst case scenario distance calculation to a basic level next) is 1000m the objects are effectively 5 seconds apart, which means I can sit on my ass for the next 4.99 seconds and do Other_Important_Queued_Jobs() before I go back to checking for collisions in regard to the implied objects, if speeds drop this is fine as the time will increase and this will be corrected at the event marker, if an object increases speed it must be recalculated or percentage scaled for the new answers as to when we have to get off our asses again.

    This kind of logic can save the need to do something entirely, I hope it is already well in use in space engineers but I do not code to such a high level, i’ll use goto if I have to. Please point out to me the current method of collision detection in space engineers, all objects vs each other initially distance based check?

    In any case the logic goes that by calculating the time of the event horizon worst case we can get lazy about when we test again the distance between objects, before we even test for direct collision between two objects, which we might skip because of the next test.

    Also I need to mention, we haven't even checked to see if they were headed towards or away from each other, line intersection at point given 2 sources and 2 destinations, doesn't sound cheap cpu wise. This doesn’t matter too much but we would know more if we tested the intersection ‘angle’ and scaled the speeds accordingly, so we might see the worst case intersection test in all its accuracy. Seems a bit to expensive to do for a ‘when do we gota get out of bed?’ check but if the 2 objects were massive cpu wise then it might be a good payoff loadwise? The extra snooze time might be just what we need to do the remaining physics queue before its deadline for 1:1 operation.

    An object measured from its centre including its axis maximum deviation vs another object's centre - the maximum deviation distance wise from its centre. So something loosely like Distance=(obj1.x+obj1.maxwidth)-(obj2.x+obj2.maxwidth), not accounting for negative planes etc. Just addition and subtraction but it's not 'sorted' and by sorted I mean you usually subtract the small number from the big number not the big number from the small number etc.

    If an object is not moving, has not had any collisions and has no active 'force'/'momentum' generation blocks(which should also idle nicely on their own without applying any forces during idle.) there is no need to apply the object's momentum to its location because there is no momentum there is no need to do any collision checks because it will collide with anything, something may however still test positive for a collision with it, also we may stop checking this object until such time as a collision or active force block reactivates the grid from idle.

    This doesn't rest objects in a gravity well tho, that must be done by measuring the forces put through a grid, its location and if it is staying what some definition of 'still' might be, 0.001m/s maybe and the values coming from any collision detection are close to the same average from last check scaled to the same 'timeframe', the object might be considered dependently at rest, which is to say its idle but only so long as this other interfering grid is sitting on it with these values stays the same someone touches it or a thruster on it etc all idle bets here are off. Maybe there is no interfering grid and the object has come to average() at a point upon a voxel surface vs gravity. Dunno, don’t think i’ll really be able to coherently read source, polymorphic object orientation vs gravity, I already know i’m in over my head.

    Does the game enqueue events? Can the game put off a job for a period of time until when its needed/appropriate to recalculate? Do my refineries really recalculate each 'frame' or 'tick' when they could be do doing absolutely nothing for the next 999ms as per a 'recalculation' or is that more because i'm observing them?

    Copied and pasted from -> http://forum.keenswh.com/threads/ga...ambling-with-a-serious-but-happy-dem.7383143/
     
  2. Kamikaze Wombat Trainee Engineer

    Messages:
    3
    ID10T, Some of what you posted may work to help server lag issues alongside the relative reference frames idea (don't know enough about how it works to tell you) but it definitely would not replace the need for it. Most of the things this is intended to solve are not caused by the server falling behind in processing but instead by limitations in the way the physics engine works.
     
    Last edited: Apr 25, 2016
  3. Smoking Squirrel Trainee Engineer

    Messages:
    12
    well i wasn't gonna kick the dead horse but other people already have so

    from what I've gathered from reading the 14 pages here:
    -RRF's will let us appear to move faster in relation to other objects
    -RRF's can be calculated in many different ways (though, standing on the surface seems to be the obvious one.. if I jump in the air and the room I'm in accelerates away, air resistance can basically be ignored and I'm staying where I am)
    -RRF's will not fix objects zooming through eachother (like in KSP) by themselves (OP proposed a solution, and numerous pages ensue arguing about said system)
    -RRF's may or may not increase or decrease server CPU overhead.. nobody's really responded with statistical evidence or hard data (unless i accidentally glazed over it)
    -RRF's are gonna ruin our sense of scale
    -but muh planets you're goin' too fast man and its totally spinning

    so, i can't really give my two cents on the "how will we calculate which RRF you belong to" or "it's gonna hog too much CPU time" counterpoints but, as far as not fixing the fact that we'll zoom through eachother... do we really need to? (I just know some snarky person is gonna quote only that line and respond with "Yes." lol)

    considering this collisions clipping conundrum from a gameplay vs realism aspect:
    space, realistically, is vast and largely empty. the odds of colliding with something are almost nil.. even if you're flying directly into an asteroid belt.
    gameplay wise, why not just say to hell with it and not worry about it? plenty of realism has already been gutted and left to die for gameplay reasons and I see no reason why this can't be one of them. (more on asteroids later)

    "but what about hitting asteroids and stuff in SE space?"-- if asteroids were dispersed realistically, collisions would be so unlikely that there's going to be something in the way that you don't even have to precision calculate it. in fact, realistically it should be so unlikely you could literally just leave it to a random events handler and call it a day and noone would even notice, unless you told them. the problem with this idea only exists due to how space engineers models the placement of asteroids, they're literally everywhere for no reason like anti-ship mines- do they really need to be, since they're going for solar-system scale now? but that's another suggestion entirely. however, if we had proper asteroid FIELDS then it would be an even simpler solution: Simply slow your ship down when you approach asteroid fields and navigate through. Flying into that field too fast? Just say "well shit you hit something cause you were going way too fast to physically maneuver out of the way of something, anyway."

    "but what about ramming people?"-- ramming somebody going 1km/s faster than them isn't even going to be viable in the first place without precision piloting and tracking, which we don't have and is another suggestion entirely, and it's hard enough as-is even at our friendly 100m/s.. It's something that's nigh impossible to do in KSP too, all glitching aside (saying this because everyone and their moms references KSP here apparently). If you want to ram somebody you're going to have to slow down. that's just a piloting fact, let alone a physics engine fact. why make everybody scratch their heads for two years straight on a forum post on the off chance that some guy's gonna fly something with a 20 meter cross section, going 2km/s, into your creation on accident (or even on purpose, really)? (obviously the answer why is realism, age old debate i know)

    "but planets!"-- planets don't even rotate as-is..while brickedkeyboard DID want proper n-body modeleing with planets that spin and orbit and you have to perform escape burns, i would bet money that the vast majority (over 80% probably) of SE players would not want to open some orbital mechanics calculator with maneuvers and all like KSP just to go to the moon. what's wrong with what we have now? just leave the sun/skybox rotating for gameplay simplicity. the only thing you should worry about when approaching a planet is your speed. going too fast? you're going to burn up in the atmosphere or crash.

    and what's this about our sense of scale lol is this a bad joke? it has to be. 100m/s is by no means remotely "in scale" in relation to the size of objects and the distances to traverse them. especially when you consider that we're flying from the earth to the moon in like 20 minutes. Using scale as an argumentative point here is like saying "Well RRF's is a shitty acronym and it ruins my sense of joy" The only "scale" space engineers has every been about is the size of the stuff you're building. the only scale argument applicable here is 'I like the perceived scale therefor please don't change it'

    well, those are my thoughts/opinions on rrf's and how they would be implemented. i think a lot of people try too hard to make it super-accurate and realistic and then they're left wondering why it's suddenly a lot of math and collision detection. truly in my opinion the debate should be "at what point do we care if a ship hits something else or not" which could easily just be a function of the ship's size.
     
  4. ID10T_Error Trainee Engineer

    Messages:
    24
    Look your biggest issue with entities 'jumping' from position to position, 'tick' by 'tick' relates a lot to the ping you have vs the network jitter also vs the servers 'time lapsed since last calc' vs your clients. The only way your going to 'correct'/'stabilize' this is for all these variables to remain 'constant' or another term might be 'even' between 'ticks'. Another method might include calculating the objects % movmemnt relating to other objects and averaging the next frame against objects that matched 100% or by taking the amount that matched and partially averaging based on %wise similarity, so as to ensure the position of the entity ends up being the same relative to the objects it was 'with' at the time.
     
  5. SpecFrigateBLK3 Senior Engineer

    Messages:
    1,133
    This seems like the best implementation of relative reference frames, in my admittedly barely educated opinion.
     
    • Like Like x 1
  6. ID10T_Error Trainee Engineer

    Messages:
    24
    The solution I have given I believe to be 'cpu intensive', initially maybe the 'check' could run once every second or 2 which would then group the objects, the group would then be processed as such for the purpose of applying momentum, a decision must be made on the % similarity to enter or create the 'group' and the same decision must be made in reverse for the 'leaving' of the group. This should allow an 'overloaded' 'momentum function' to take over from the normal one incase of groupid. The devs could tell me if I have things wrong but maybe their using havoc to do the momentum so no actual control over it? I dunno I haven't read the sources.

    Thanks SpecFrigateBLK3, I believe you have the correct attitude about the problem :)

    Also prolly should contain a distance check for creation/joining a group and for seperation->leave.
     
    Last edited: Apr 28, 2016
  7. zorgkirill Apprentice Engineer

    Messages:
    196
    bump
     
    • Agree Agree x 1
  8. zdzier Apprentice Engineer

    Messages:
    133
    if you put reference frame to player, wont that mean you gonna have to move an entire world instead? Inst that a bad solution? Cant you just switch to x64 and tweak floating point positioning?
     
  9. CCampbell Trainee Engineer

    Messages:
    28

    I would not claim to be able to code what bricks and happyjack talking about but I certainly understand it and if you weren't so ignorant you would understand too by this point from the hundred times they've written it in plain English... and provided numerous examples in lamen terms.. They're both highly intelligent should be celebrated. After all, this day in age parents are raising more and more people like you and blaming it on today's society.

    Nobody likes a know-it-all because the nobody's don't get it.... Get it? That's the fucking point. Tell me the story again about how we tripped and fell into space one day.... Fuckin Troll
     
  10. Dicarus Apprentice Engineer

    Messages:
    136
    I like the idea, but I'm not certain it can be implemented at this point.
     
    • Agree Agree x 1
  11. SpecFrigateBLK3 Senior Engineer

    Messages:
    1,133
    Perhaps, but the issue can be looked at in the future by the appropriate folk. Perhaps something has been brought up that otherwise wouldn't.
     
  12. CCampbell Trainee Engineer

    Messages:
    28
    Thing is I don't think they do as much reading on the forums as they claim they do.

    And the fact they are preparing the game to leave alpha is even more evidence of they commitment to leave the game in its current form.
     
  13. SpecFrigateBLK3 Senior Engineer

    Messages:
    1,133
    First off, source?
    Second, they may already be working on it.
     
  14. zorgkirill Apprentice Engineer

    Messages:
    196
    Does anybody know, if the topic subject was implemented?
     
  15. Aracus Senior Engineer

    Messages:
    1,931
    It makes sense, give it another year! ;)
     
  16. Greyson_XMG Apprentice Engineer

    Messages:
    132
    I have offered this solution ( like the OP ) expressed in different language.

    WHAT COULD THIS ENABLE?

    1. No real speed limitations. All Velocities are relative. Relative to what? Big ships are relative to the nearest relevant planetary body. Sun/Planet/Moon. Small ships add big ships to the list. People relative to the nearest whatever.

    2. Planets that orbit a star.
    3. Planets that spin on their axis.
    4. Moons and asteroids that orbit stars and planets.
    5. Spaceships that can orbit just about anything.
    6. Long distance space travel begins to mimic reality.
    7. FTL could be handled in many different ways.

    YES, This might entail a major code overhaul, but the benefit to the game will be IMMEASURABLE.

    Worth it in the long run, even if it is a rocky road.
     
  17. GrindyGears Senior Engineer

    Messages:
    1,787
    Regardless of what frame of reference you are heading towards, doesn't change the fact that at speed you will still have collision issues.... Like at all... People keep propagating this idea as the master fix to all problems, but it really doesn't solve all of them, speed limits is not one of them.

    Having massively dynamic voxels like that is crippling to even super computers.... We're talking about millions of voxels here, constantly updating and moving. Sure the ship may be moving relative to something so it would seem like few updates, but people seem to forget that the planet has to "rotate, or orbit" relative to a point, likely 0,0,0 which would turn your game to a slide show.

    Long distance space travel is boring, and tedious. The distances are long enough we generally rate it in a unit of months...

    As for FTL: your argument that it could be made better is built on the faulty assumption that this would actually infact fix everything in the game.

    A major code overhaul is an understatement. To make something like this, you'd have to have been building the whole game, right from the base code for it. To actually integrate it now, would be like telling them to throw out the three years of development and start a new game.

    The gains don't exist, they're an infinite number divided by 0, I guess in that regard they're immeasurable.

    I really am trying to burst your bubble here, I very much doubt this idea would fix everything for the ludicrous amount of work it would be to implement it.
     
    • Disagree Disagree x 2
    • Agree Agree x 1
  18. zorgkirill Apprentice Engineer

    Messages:
    196
    Three years of bugs development and polishing useless things...
     
    • Agree Agree x 1
    • Disagree Disagree x 1
    • Funny Funny x 1
  19. Me 10 Jin Apprentice Engineer

    Messages:
    463
    Not "millions", it's "trillions" of voxels; and I don't think anyone is seriously suggesting tracking physics for each individual voxel. Relative reference is all about moving space around static objects until something interesting is about to happen. The math is sound, implementing it in SE might not be.
     
  20. GrindyGears Senior Engineer

    Messages:
    1,787
    I respectively disagree, people seem to think that by some magic code buzzword ala RRF's the game doesn't have to make the trillions of calculations as you corrected me.

    in one way or another you have to track the position of the voxels and data for each and every body that moves in the game, even if it's out of render distance, somewhere, somehow the collision data needs to be kept track of, so whenever you leave one magic frame to enter another, you literally will have to update trillions of bits of data to sync up the positions of a single planet, with a moon orbiting it. Even if you have the planet as a static reference, moving the moon around the planet is a MASSIVE overhead on CPU and probably GPU, I'm pretty sure we're arguing the same points here so lets leave it at that

    Things like this are dangerous, people not thinking an idea all the way through, or just propagating something like this spreading the idea preaching to the masses and any time they hear something they don't want to they just plug there ears and continue on with the preaching.

    Ironically, I'd support the idea of RRF's specifically for sub-grids, as it may make things a little more stable, but with that being said, I realize it's a massive undertaking to do so, and given the complexity at which I typically build, i doubt it would actually help me all that much...
     
  21. Greyson_XMG Apprentice Engineer

    Messages:
    132

    'All those voxels moving arround...'

    I don't think you get it at all.

    THEY ARE NOT MOVING. The whole planet would move/spin with a single small computation. The whole kitty kabootle moves as a single object in its own frame of reference. When you get near it, you become part of that frame of reference. The tricky part is moving/transitioning from one frame of reference to another.

    Get it?

    the frame of references are moving around.. not the voxels themselves.
     
  22. GrindyGears Senior Engineer

    Messages:
    1,787
    and the moon that you want to be orbiting the planet? thats not moving while simultaneously orbiting?

    AND you still have EVERY OTHER BODY MOVING RELATIVE TO WHATEVER FRAME YOU'RE CURRENTLY IN...

    Seriously you can't have your cake and eat it to. what you are proposing can be currently summed up by setting a current planet at 0,0,0 with the planet as a frame of reference having the moon(s) move around it, and other orbiting bodies is still a massive number of calculations.
     
  23. Me 10 Jin Apprentice Engineer

    Messages:
    463
    @GrindyGears the game Astroneer implements destructible voxel planets and moons in orbit around a shiny ball. Like I said, the math is sound, it's not magic.
     
  24. Greyson_XMG Apprentice Engineer

    Messages:
    132
    The math is sound... Now it would take some work, but the reward would be vast.
     
  25. Malware Master Engineer

    Messages:
    9,861
    RRFs solves some problems but creates new ones. Astroneer is much simpler game than SE, it doesn't have the complex motions in space nor the true player-controlled planetary transitions. Yes, moving voxels is easy. That was always easy and was never the problem. The concequences of that motion is the problem.

    RRFs are not the silver bullet that this thread is making them out to be. The reward is nowhere near the cost at this point in time.
     
  26. Aracus Senior Engineer

    Messages:
    1,931
    Maybe in combination with micro-instancing and sharded processing?
     
  27. Malware Master Engineer

    Messages:
    9,861
    Oh, there are probably workable solutions. None perfect, but perhaps the infamous good enough. There isn't much that's impossible in software engineering. More likely than not it's the issues we can't see that will be the big showstopper, that's usually the case with changes as big as this one. But the fact remains that it's simply too costly a job at this point.
     
  28. Aracus Senior Engineer

    Messages:
    1,931
    For a company throwing around millions in prize-money i somehow doubt that.
     
  29. Malware Master Engineer

    Messages:
    9,861
    Doesn't work that way - and millions go away quickly in developer time.

    Not to mention the PR if they destabilized the game even more now.
     
  30. Aracus Senior Engineer

    Messages:
    1,931
    Meh. if they, you know, warned us they would spend X amount of time+after shakes for a feature with huge potential gains for the players, it wouldn't be so bad.
    Its the surprise long term bugs that hurt. Good management of public relations *shrug* it would help.

    And again, if they have those millions to throw away in lumps? why not SPEND them on improving the game potentially immensely?
     
Thread Status:
This last post in this thread was made more than 31 days old.