Notifications
Clear all

To all SSC Station occupants

Thank you for the donations over the past year (2024), it is much appreciated. I am still trying to figure out how to migrate the forums to another community software (probably phpbb) but in the meantime I have updated the forum software to the latest version. SSC has been around a while so their is some very long time members here still using the site, thanks for making SSC home and sorry I haven't been as vocal as I should be in the forums I will try to improve my posting frequency.

Thank you again to all of the members that do take the time to donate a little, it helps keep this station functioning on the outer reaches of space.

-D1-

[Sticky] Issue tracker now available

Page 3 / 6
(@fluffyfreak)
Noble Member

Hi,

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?

Andy

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 😀

my fork:

https://github.com/fluffyfreak/pioneer

ReplyQuote
Posted : June 6, 2011 09:00
(@brianetta)
Prominent Member

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.

ReplyQuote
Posted : June 6, 2011 13:32
(@brianetta)
Prominent Member
fluffyfreak wrote:
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 😀

my fork:

https://github.com/fluffyfreak/pioneer

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.

ReplyQuote
Posted : June 6, 2011 13:38
 robn
(@robn)
Noble Member
fluffyfreak wrote:
I recently forked the project so I could start to fixup the MSVC project files (they're committed on my fork by the way)

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.

Quote:
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 😀

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!

ReplyQuote
Topic starter Posted : June 6, 2011 14:01
 robn
(@robn)
Noble Member
Brianetta wrote:
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.

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?)

ReplyQuote
Topic starter Posted : June 6, 2011 14:03
(@s2odan)
Noble Member

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):

http://www.youtube.com/watch?v=XkuPqMhN_vU

Quote:
(eg can the terrain under you change such that you're suddenly inside a mountain?)

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.

ReplyQuote
Posted : June 6, 2011 16:03
 robn
(@robn)
Noble Member

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...

ReplyQuote
Topic starter Posted : June 6, 2011 16:14
(@fluffyfreak)
Noble Member

@s2odan,

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.

@everyone,

Thanks for the warm welcome! 😀

ReplyQuote
Posted : June 6, 2011 22:54
(@ollobrain)
Honorable Member

welcome aboad sounds like a reasonable progress is going to be made

ReplyQuote
Posted : June 7, 2011 01:57
(@s2odan)
Noble Member
fluffyfreak wrote:
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.

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.

Quote:
I'll take a look at it as I have some experience with terrain generation and rendering.

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 🙂

ReplyQuote
Posted : June 7, 2011 05:46
(@s2odan)
Noble Member
Quote:
Is there a way we could arrange that priority be given to generating the terrain immediately under the player?

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.

ReplyQuote
Posted : June 8, 2011 05:28
 robn
(@robn)
Noble Member

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.

ReplyQuote
Topic starter Posted : June 8, 2011 11:47
 tomm
(@tomm)
Estimable Member

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

ReplyQuote
Posted : June 8, 2011 11:49
(@creepystepdad)
Eminent Member

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.

ReplyQuote
Posted : August 21, 2011 18:57
 robn
(@robn)
Noble Member

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!

ReplyQuote
Topic starter Posted : August 21, 2011 20:05
(@brianetta)
Prominent Member

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).

ReplyQuote
Posted : August 22, 2011 02:35
(@creepystepdad)
Eminent Member
robn wrote:
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!

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.

ReplyQuote
Posted : August 22, 2011 09:17
(@marcel)
Noble Member

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.

ReplyQuote
Posted : September 11, 2011 10:58
(@brianetta)
Prominent Member

Thanks, Marcel. The issue has been re-opened, as promised.

ReplyQuote
Posted : September 11, 2011 14:39
 SubV
(@subv)
New Member

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.

ReplyQuote
Posted : January 6, 2012 11:05
 robn
(@robn)
Noble Member
SubV wrote:
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.

Reported in #856. Fixed in latest nightly and in alpha 18 (releasing next week).

ReplyQuote
Topic starter Posted : January 6, 2012 12:34
(@whisper979)
Trusted Member

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.

ReplyQuote
Posted : March 8, 2012 05:23
(@luomu)
Estimable Member
whisper979 wrote:
or the game loads but my ship won't move in any way

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.

ReplyQuote
Posted : March 8, 2012 06:10
(@whisper979)
Trusted Member
Luomu wrote:
The game is paused when the game loads, make sure you haven't missed that.

*hangs head in shame*

I hope that's not my issue 😳

ReplyQuote
Posted : March 8, 2012 09:05
(@whisper979)
Trusted Member

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!

ReplyQuote
Posted : March 10, 2012 16:26
Page 3 / 6