Author Topic: Shaking Skyboxes  (Read 1806 times)

0 Members and 1 Guest are viewing this topic.

I have noticed that the skyboxes start to shake or vibrate when large/hi-poly ships (not entirely sure but I think it's the latter) are located at positions which are greater than ~150km from the 0,0,0 point of a level. This occurs whenever the player ship moves, either around or while maneuvering. Once the ship stands still the vibrating ceases. This might not effect that many people :D , but it's a bug so I thought I report it.

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
It's not a bug, exactly. What you are seeing is a result of the game engine becoming unstable due to floating point inaccuracy.
Let there be light
Let there be moon
Let there be stars and let there be you
Let there be monsters and let there be pain
Let us begin to feel again
--Devin Townsend, Genesis

 
So that probably means there's nothing that could be done about it. :(

 

Offline m!m

  • 211
At least for the skybox it should be easy to fix this since the actual rendering position of the skybox does not matter.

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
At least for the skybox it should be easy to fix this since the actual rendering position of the skybox does not matter.

I am not sure if the camera orientation stays stable enough for that.
Let there be light
Let there be moon
Let there be stars and let there be you
Let there be monsters and let there be pain
Let us begin to feel again
--Devin Townsend, Genesis

 
Actually while I pushed the engine pretty far, with several hundred (about 220) objects being more than 150km from the mission center, some as far as 2200km away, the issue with the skybox was the only problem I've noticed.

Out of curiousity, do the rendering issues on very big ships also result from this "floating point inaccuracy"?

 

Offline Cyborg17

  • 29
  • A-1 Supar
Could you be more specific?  Are they rendering issues that happen at large distances, and what exactly happens?

 
The model starts to flicker, some parts are rendered, some not. At first it happens to submodels (turrets etc/at about 100km size), then the main model.

It's a known error though, the first time I've seen it was with the planet models in INFR1.

 

Offline m!m

  • 211
I am not sure if the camera orientation stays stable enough for that.
Is the camera orientation dependent on the camera position? Intuitively I would assume that it wouldn't be but I can't check the code right now.

  
Would making all space using floating points work around the problem?  I've heard the idea mentioned once on a Discord chat -- I have no idea if it'd work.

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Would making all space using floating points work around the problem?  I've heard the idea mentioned once on a Discord chat -- I have no idea if it'd work.

Not exactly. This issue exists precisely because we are using floating point variables to store position and orientation data. There are only two real fixes available here:
1. Use double-precision floating point math. This does not fix the underlying issue as much as it papers over it; this also has unfortunate sideeffects as many data structures in the engine now take up literally twice the space. This has performance implications as well: We gain a lot of speed using SSE instructions on some of our math operations, which require that they be done using single-precision floats. Plus, there is rendering performance to consider: While modern GPUs are incredibly fast even in double-precision workloads, they are still much slower than they are when doing single-precision calculations.
2. Always treat the player or camera as the origin point of the global coordinate system. This is a technique that is used by modern streaming game engines like Unreal; since every important action will happen within the zone of highest precision, float inaccuracy will never be an issue. This would require extensive redesign of the physics system to make work in FSO.

TL;DR: Yes, there are ways around these issues. However, implementing them requires a large amount of effort, and so it is unlikely to ever get done.
Let there be light
Let there be moon
Let there be stars and let there be you
Let there be monsters and let there be pain
Let us begin to feel again
--Devin Townsend, Genesis

 
At appears that the skybox issue could be fixed though. When I set a mission in subspace (which- to my limited understanding - acts basically like a skybox as well) I'm not having any problems even when I put my ship 500km off the mission center.

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Does anybody actually need this fixed? What’s the use case here?

 
Well I run into it from time to time. It's not like it's going to be used in every campaign from then on, but it's easier to built, say, multi stage missions the more space is available. If it'd take a coder many hours to fix it, the time would surely be invested better elsewhere; but if a viable solution already exists in the code (of which I have no idea), why not have one issue less? The skybox thing is the first (and most obvious) thing that will go wrong with distance related issues - having that done could bump usable space from ~70 to about 100km.

 

Offline 0rph3u5

  • 211
  • Someone should label the Future: Assembly Required
    • Steam
    • Twitter
(this was wirtten before Nightmare's post)

Considering that LUA script have the potential to normalize in-mission-jumps, checkpoints as well as the normalisation of hull repair in newer mods, increased spatial requirements were bound to come up. Esspecially if you were going for missions where the player would launch from a port and do sub-missions by jumping back and forth, as well as requiring the "port area" to be in a constitent state (so you wouldn't just ship-vanish and ship-create it over and over again).

However I think, this doesn't require the so much to alter the overall mission space avalible but to add tools to effect the illusion of distance. As distance is percieved through reference points (that how you do optical illusions and in-camera effects to shrink or grow objects in film) that wouldn't take much in FS_Open as per se the mission space doesn't have reference points from the player perspective that aren't placed by the FREDer. The only obstacle to effect illusion of distance there would be the distance measure in the HUD, if the any far away objects could still be targeted that is.

Using a custom HUD configuration you can already use $Length Unit Multiplier: and $Speed Unit Multiplier to affect distance measure in the HUD globally.
To more control an illusion of distance here then, could be affected by on a case by case basis or globally by on a "if distance >{any value} then multiply all distance on the HUD by {any factor}" or through "add {value} to distance displayed" ... that way you could actually shrink the absolute distance between "areas" in a multiple in-mission jumps mission without blowing up the spatial requirements.
« Last Edit: September 23, 2019, 10:56:05 am by 0rph3u5 »
"When you work with water, you have to know and respect it. When you labour to subdue it, you have to understand that one day it may rise up and turn all your labours into nothing. For what is water, which seeks to make all things level, which has no taste or colour of its own, but a liquid form of Nothing?" - Graham Swift, Waterland

"As you sought to steal a kingdom for yourself, so must you do again, a thousand times over. For a theft, a true theft, must be practiced to be earned." - The terms of Nysa's curse, Pathfinder: Kingmaker

"...because they are not Dragons."

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
I hear you on the multi-stage mission thing, but in practice, I’m having a hard time imagining ACTUALLY needing more space. Universal Truth 2 seems to run without any noticeable skybox issues, and it’s tough for me to imagine a mission ever requiring more stages and more random crap than it does.

Orpheus, you don’t really need more space to do in-mission jumps, even with a persistent ‘hub’ where you want stuff to keep happening. Everything can happen in the same overlapping space. There should be enough area to move your ‘hub’ far off, past the point of visibility; and lots of tricks to hide it if not.

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Worth noting that not even Elite Dangerous, a game which builds entire solar systems at full scale, actually uses large playable spaces - just a TON of instancing. Even EVE Online only creates physically simulated areas where players exist. There’s no attempt to keep the whole available solar system ‘on grid.’

 

Offline 0rph3u5

  • 211
  • Someone should label the Future: Assembly Required
    • Steam
    • Twitter
Orpheus, you don’t really need more space to do in-mission jumps, even with a persistent ‘hub’ where you want stuff to keep happening. Everything can happen in the same overlapping space. There should be enough area to move your ‘hub’ far off, past the point of visibility; and lots of tricks to hide it if not.

I know, but there is also no compelling reason not to do what I described. :)
"When you work with water, you have to know and respect it. When you labour to subdue it, you have to understand that one day it may rise up and turn all your labours into nothing. For what is water, which seeks to make all things level, which has no taste or colour of its own, but a liquid form of Nothing?" - Graham Swift, Waterland

"As you sought to steal a kingdom for yourself, so must you do again, a thousand times over. For a theft, a true theft, must be practiced to be earned." - The terms of Nysa's curse, Pathfinder: Kingmaker

"...because they are not Dragons."

 
Except maybe shaking skyboxes'n'stuff.

 
Well it was just an idea, not a request; in the end it's the up to the coders if they feel like looking at that part and whether the use/needed time is good or if they're interested at all. :)