Trajectory extremely jittery

Hi,

the trajectory in the latest (yesterday) clone of the git repo is quite jittery (see https://youtu.be/uO0imZR3LW4). In the last Beta it wasn't that bad. I'm running under Windows and it was like that on two different PCs. Tell me if you need more information.

I have the same after spending too much time in some systems and probably hitting some strange event.

Teleporting outside and back into the system usually helps.

You are right, didn't realize that, right now I'm mostly in one system working on some form of navigation software... Where is the trajectory code anyway? I was searching for it earlier and couldn't find it...

Trajectory calculation happen in ship/hud.lua.

I think this points to the need for some kind of profiling functionality, which I haven't really looked into. If it resets when you leave the system then I suspect it's caused by the computer-controlled ships or possibly the asteroids behaving erratically. You can comment out the body of the update function in ship/ai.lua to rule them out, and the populate and recycle functions in asteroid.lua to rule them out, assuming the slowdown is repeatable.

It's not really a slowdown, it is just the second half of the projected trajectory going weird

Agreed, no slowdown. The video is just not good quality, was just to show what's happening, quick'n dirty... I'll have a look at this this evening...

P.S.: Awesome Game, i so love the mechanics, the programming, and also the story, even at that early Stage...

Nope, not the ships and not the asteroids. I deactivated both and it didn't change. I also watched the speed of ships and asteroids, but they are pretty calm. It also returns much faster after you restart the game, meaning I quit with CTRL+Q and restart it and it looks normal, until after some seconds it's going back to all wobbly. My suspicion here is accumulated error in combination with the arctan as well as sine and cosine functions. What I don't get is: why does it change over time? I can't see any variable in the source responsible that contains "time in a system" kind of information...

Well, ship.heading effectively contains such information, because it is not kept modulo 360° or 2π and you tend to keep turning in the same direction. Of course, it shouldn't matter when the engines are off…

Maybe trajectory and trajectory_step_size get some weird values?

How long does it take to manifest?

Morning, About 30 to 40 minutes, and after a game restart more like 20 seconds... I'm gonna recheck today the ship's involvement, I didn't change system when I tried. But I don't think that's it, the wobble seems chaotic but it isn't.... it is actually quite recurring, just too fast, what hints at the math functions and accumulation again.

@Surrogard can you share a save with that? If reproducing takes just one minute, it will hopefully help locating the problem…

Here you are. You don't need to move at all, it should start jiggeling after a minute.

bussard.zip

Interesting. At some point I have previously got trajectory instability and even portals were affected. After loading this save, I don't get this problem.

Hmm I just started the savegame with the beta 1 precompiled (Windows EXE) and it shows the same instability...

Hm, true, beta-1 does have the problem.

And the ship heading is not that bad and trajectory step size is reasonable.

The current master version doesn't seem to have the same problem and it is not immediately obvious which of the changes change the situation… And I hope that there will be a physics cleanup which will probably remove the old bugs and add different ones.

But I also have it in a reasonably current checkout of matter.

Do you have a save from there?

This is the same save game, it was from the master checkout and I loaded it in the beta1, it's showing the same symptoms...

Tested it at work: same issue, it immediately starts wiggling in this save. I'm running this at Windows 10 64Bit with the newest 64Bit Löve engine (although the beta 1 precompiled version shows the same)

Home PC: AMD 6 core don't ask me what, 16GB RAM, SSD, 1280x1024 NVidia GeForce 8800GT

Work PC: Intel Core i7, 16GB RAM, SSD, 1920x1080 AMD Radeon HD 5450 or NVidia Quadro FX 580

I hope this is not Lua 5.2 vs LuaJIT issue… Although you probably have at least one test case with LuaJIT anyway

I don't think it's possible to get a non-LuaJIT LÖVE in recent versions unless you compile from scratch.

You can place require "ffi" in main.lua to ensure you're on LuaJIT though.

Hm, physics cleanup changes the scale that makes it easier to get jitter with that saved game. A nice side effect…

So Michael, you still get the jitter?

Well, significant jitter after cleanup (because of rescaling), slight jitter but still more than there should be on the pre-cleanup master.

No idea yet how to locate the root cause…

At the moment the trajectory does a full simulation of all the bodies going forward n seconds every frame.

As far as I can tell planets, stations and portals only feel the effect of gravity from the fixed sun which means that their trajectories don't depend on the player's actions.

local is_gravitated_by = function(from, to)
   if(from == to) then return false
   elseif(to.fixed) then return false
   elseif((to.world or to.portal) and not from.fixed) then return false
   else return true end
end

So the trajectories of the planets, stations and portals only need to be calculated once and cached, these positions could then be used in the ship's trajectory calculation rather than redoing these calculations every frame.

Maybe portals and stations should actually feel the gravity of planets, though…

Maybe portals and stations should actually feel the gravity of planets, though…

They should eventually (I think it would be cool to place a portal in orbit around Jupiter if it had a bunch of other satellites) but until we add that kind of setup we don't need to worry about its gravitational effect.

Milestone changed to %beta-2

Added bug label

Seems like the trajectory auto-adjust is causing problems here. I can get reasonable trajectory stability by manually setting ship.trajectory and ship.trajectory_step_size, but when I rely on the auto-adjusted values it sets them too high to actually give stable results. The auto-adjust also no longer shuts off, so its continual changes to the step size mess up the smooth color bands on the trajectory visualizations.

Hm, I saw it never actually did much, so I tried to fix it shutoff which happened before any reasonable changes… Do you mean autoadjust should be just removed then?

The auto-adjust originally only ran for the first 4 seconds of the game to try to find an acceptable target FPS, then shut itself off, but it doesn't do that any more. I'm working on a patch to restore it.

I think it only did a single adjustment, though, so it could only give one of three possible outcomes

I've changed it in cd3290b to trigger auto-adjust when entering a new system, and to remove the auto-adjust out of ship.updaters once the target FPS has been achieved.

Should this still be a blocker for beta-2? It seems like since the auto-adjust was fixed it's a lot better than it was.

Sorry I couldn't test. I'm in holidays. I'll test today in the evening (although I only have a Thinkpad tablet here)... But generally I don't see this as a version blocker.

I think it's a painful thing, honestly. Even for testing, you can't keep the game running and execute random code.

@Dhavan: Did you try it with the latest checkout?

@codingquark right now I have it such that the trajectory is only calculated when you're either a) in flight mode or b) not running your machine on battery power. I could make it so that going into the console/editor disables the trajectory if it makes it difficult to code. I haven't seen that to be the case in recent versions, but if it is on other peoples' machines then maybe we should.

Just checked with latest checkout (a few minutes ago) and it seems really fine now. Not at all a blocking thing.

Milestone removed

Thanks. I'll leave it open so we can gather more feedback, but it's not a blocker.

Hm, I have accidentally reproduced it (fresh checkout, right after a wipe)

bussard-save-20160808-131142.zip

Milestone changed to %beta-3

Hm, an interesting fact: the trajectory (in the current situation) is calculated from clones. The clones don't have to.star or to.world or to.portal set, so it is sometimes possible to obtain a trajectory for a star (of course, the star is not going to follow it).

If we create a proper mass hierarchy, maybe just the ratio of masses could be used in is_gravitated_by (a.m/b.m<1e-3→ a doesn't really feel the gravity of b).

mentioned in issue #143

mentioned in issue #145

Theory: an AI ship flies into a really close orbit inside the star, whenever it passes close to the star's center the star gets projected trajectory of a noticeable drift from (0,0) [that part per se has been observed], trajectory is calculated for the star moving away from origin, but the trajectory doesn't have much to do with the main motion calculation that assumes that the star is fixed at the origin.

Moving a star usually creates some disturbance in the orbits…

Mentioned in merge request !48 (merged)

I really hope that this should be fixed now… If nobody reproduces it in some period of time, I guess the issue can be closed.

I'm not sure it is the exact same issue, but I just cloned the current repo and it went jittery as soon as I came near the first station...

@Surrogard do you happen to have a save of this situation? What is the exact revision you have cloned, by the way?

By the way, if you go really close to the station (the Kepler-free zone, as I call it) there may be some jitter just because of actual numerical instability of the situation (small changes in coordinate mean large changes in the force angle)

Well I went as near as I had to to get the SSH session open. The checkout is commit f138f946bbc5b13000129fd8db78b1cccf9419c0 I just started the game fresh and went to the first station, no save no nothing, the system (SwagArch) is newly set up, so no earlier saves messing it up.

I tested it again and think the jitter near the station is like you said Michael, not the problem we had before. The jitter after some time seems to be gone, I let it run about 20 minutes and the path is rock solid, I'll let it run some more just to be sure. So if I understand the problem correct we have rounding errors adding up, right? What data types are used here? Doubles? Is there a way to go higher in precision? And if there is: will it prevent the error to show up in the current trajectory length without impacting FPS? Or perhaps here the way is to smooth out the trajectory by calculating the mean average of several calculations and update it less often...

P.S.: here a video of the jitter near the station: https://youtu.be/UxqsuIvbRUU

1. It is by now well-known that the old time-related bug was not so much about time elapsed as about a small ship getting caught in the star's gravity well. I also remember that it was way worse than what you show.

2. The video is 480p on Youtube, right? Well, that's too blurry to see some of the interesting things… The save could be taken after the problem happens so that people could use advanced HUDs to check some hypotheses about your trajectory.

3. I would say that the main reason of your jitter (I get less jitter for a comparable orbit) is that your FPS is not constant enough, so this is not about rounding error accumulation but about time step error accumulation. There are options: switch to the second-order ODE solving method (pretty easy to do, actually: you need to do a half-dt update of type x→a, a→v, v→x and a half-dt update of type v→x, x→a, a→v; I guess you could try implementing it — or remind me closer to the end of the week), switch to a fixed physics timestep (or maybe a specific sliding scale of physics timesteps; some careful refactoring is required), kill trajectory and switch to a Keplerian HUD (that's what I prefer personally in my own saved config; maybe I should actually put my config into spoilers, it has some nice things…).

4. Let it be known to you that your orbit around the station is way tighter than the actual minimum required for a stable orbit inside the SSH range. That's not your fault, though — for all the shininess of the trajectory, it doesn't help you much with entering an optimal orbit around a body…

Fixed by !60 (merged).

Status changed to closed