[Sticky] Issue tracker now available
I recently forked the project so I could start to fixup the MSVC project files (they're committed on my fork by the way) when I noticed that the terrain was "jumping" when I moved the camera around.
I was on the surface of a large planet (I will post later with the name & location, I don't have it on this PC) in the external camera view. If you rotate the camera around the ship in this view all of the terrain jumps up and down whilst the ship stays still. This looks like a floating point precision problem reaching different results for rendering the terrain dependent on the camera view position.
Is this a known issue?
PS: also the game is fantastic, I really hope that by working on my fork I can add something useful and meaningful to an already great project 😀
The terrain generator is iterative. The ground outside jumps up and down until the generator's last iteration is done, and the ground is rendered at its highest resolution. I think this can also mean that the spot where your ship is landed might sometimes not actually be on the ground any more, especially in canyons, although I haven't tested that in great detail yet.
Definitely! We buy in completely to the GitHub fork ethic. If you have something in your forked repository that is complete, and you'd like it to be considered for inclusion (or just for testing) then feel free to make a pull request of it. This will automatically create an issue on the tracker, and we'll all be able to see, review, test and discuss your contribution right there.
Thank you so much. I've been trying to get them updated myself but I might as well be on another planet when it comes to MSVC. I will merge shortly.
I've started tracking your fork so I'll keep an eye on what you're doing. If you're intending to get serious about Pioneer dev please familiarise yourself with the Development Model. Welcome!
Yes, the terrain height can change under you, for better or worse. I too have not tested in detail and don't yet fully understand the issues (eg can the terrain under you change such that you're suddenly inside a mountain?)
Ah this is a different issue I believe, I call it Jitter, but Im not sure of the 'proper' name for it 🙂 If you land on said planet it should go away and as far as I know will only appear if you are moving relative to said planet. I know, I'm terrible at explaining stuff 🙂 Here's a video showing it in action as well as another bug related to the Earth terrain which I really should fix (those potholes you can see over the landscape increase with height and it looks wrong up-close):
Thats the nature of the fractals. If you were to make a save landed in a valley or by a cliff face or some sharp terrain piece, when you load up the game your ship would be inside the planet until it can finish loading enough iterations of the terrain for the shape to resemble what it was. 🙂 The opposite for if you land on a spire, you will be high up in the air until the spire is calculated.
There are some situations too where if you fly down to a feature from orbit with too-high detail settings then its possible you could land on a flattish area and end up inside the spire of a mountain once loading has finished, but that would require a slow cpu and the very-very high detail setting.
There might be some ways of alleviating this, and in-fact I have already tried a few methods for building the terrains and one of those may have already helped alleviate this issue simply by keeping the larger mountain shapes at a very low octave number (less iterations required/possible) and using smaller noise to 'fill' it in. But it will never be completely gone.
Is there a way we could arrange that priority be given to generating the terrain immediately under the player? I imagine the memory overhead of tracking the progress of terrain generation over an entire area could be prohibitive. It might work though as I assume that determining the final height for a single point is actually quite fast (relative to generating an entire large area).
I really must learn how the terrain engine works to be able to contribute more usefully to these kind of discussions...
Yes that's exactly the issue I've seen 🙂 I don't think it is the terrain regenerating the patch as you are sat on the ground. I'll take a look at it as I have some experience with terrain generation and rendering.
Thanks for the warm welcome! 😀
welcome aboad sounds like a reasonable progress is going to be made
Oh thats a different issue, the one where the patches update/generate and you are inside the ground or high in the air... This issue in the vid (which you experienced) is not fractal based, but some engine/rendering issue.
I too at first thought it was a floating point precission thing but now Im not so sure. (Although the 'jitter' is highly indicative of that) So maybe thats the best place to start if we both came to that conclusion.. But I have a sneaking suspicion in the back of my mind that I have been here before 🙂 Good luck commander 🙂
Hey, sorry I thought I replied to this. Short of having dynamically changing values which control the terrain loading I don't know how that could be done.
In Geosphere.cpp at the top are the values I am referring to.
Hmm yes I think if : #define GEOPATCH_SUBDIVIDE_AT_CAMDIST 5.0 could be a dynamic value set to about 0.1 on load and scale upwards to 5.0, then it would do something like this. But I'm pretty sure that if you change any of those settings there that the whole terrain would simply have to be rebuilt from scratch, just like if you changed detail levels which defeats the purpose of that 🙁
Basically what that value means is how far away from the ship/camera the land will be before we load up the next level of quality. So a really low number like 0.1 would mean that we strongly concentrate on loading up what is right next to us, and the quality falls off very quickly with range from camera.
Yeah, I don't imagine for a moment that it would be a simple tweak. I'll put it away somewhere near the back of my head for later pondering.
You can play with lower detail level, but basically the terrain fractals should have a CPU budget. Some of the terrain fractals are probably using way too many octaves of perlin noise. Maybe not all of them are necessary to create the same effect
Has anyone else had trouble landing large ships? So far I have tried to land two large ships on autopilot, and both times they decided to kill themselves.
Yes, actually. I'm finding they struggle on massive planets, usually descending too fast. I haven't tested thoroughly though. Please open an issue for this so with a ship and planet that you can reproduce this at. We can then get on with some serious testing and determine a course of action. Thanks!
Some ships might not have the thrust to mass ration needed to land safely on all planets. Some might not have enough to take off at all. These things are possible; they have to obey our laws of physics, after all.
Perhaps the autopilot can do some checking first. If you ask it to land at a surface starport, it could check the mass and radius of the planet to determine the surface gravity, and then loudly inform the player if that gravity force exceeds that of the ventral thruster (the one underneath, that does the landing and takeoff).
Oh, so it's reality that's the problem. Damn you, reality! 👿
I'll try to give concrete examples of ship and planet combo soon if still needed. Thanks.
Brianetta, I went to close issue #46 a few days ago and noticed that you already did. Thanks for that and all you do. I haven't encountered the problem for a few alphas, until now. Unfortunately alpha 14 crashed with the message;
Error: space station model airport_1 does not specify valid ship_dock_anim positions.
I assumed it was caused by the system clock vs. game clock issue, but now I'm not sure. I was flying from Eugene to Gates on autopilot in real time. I'm not sure How long it ran before the game crashed. I went and did some chores and found the red screen when I returned. GitHub says I don't have permission to reopen the issue.
Thanks, Marcel. The issue has been re-opened, as promised.
The autopilot, when used on Natrix ship isn't working properly (PSS a17). It keeps crashing me, especially when I try to dock with space station.
I'll open an issue if needed.
Reported in #856. Fixed in latest nightly and in alpha 18 (releasing next week).
I hope this is the right place to post this. I am using alpha 19. I have never been able to save a game. Actually, that's not true. I can save all I want but when I load a game, the game either crashes or the game loads but my ship won't move in any way. What information do you need about my OS or system? I really don't have a problem with not being able to load a saved game because I find Pioneer entertaining even when I have to start from scratch every time. I thought that I should report it though in case this is an issue with the game on certain hardware/os combinations.
The game is paused when the game loads, make sure you haven't missed that. Also, saves between alpha releases aren't guaranteed to be compatible, so this can account for some crashes.
*hangs head in shame*
I hope that's not my issue 😳
With Alpha 19 and 20. If you start a new game and fly directly to Enki Catena, then use auto-pilot to land, you will crash on the spaceport every time. I love this game! Keep up the good work!