Possible solution to the square star seams in skybox

[Bloodsign]

Greetings FDev! I am halfway through a very long excursion towards the galaxy's center, and have encountered the obtrusive square regions of stars that many CMDRs have commented upon in these forums. I personally don't mind them too much, but I can see how some feel that they are immersion breaking. I believe I have a simple solution to this problem that will at least mitigate it a bit.

I'm unsure whether these star squares are 2-dimensional overlays or actual 3D cubes, but my solution should work either way.

Simply replace the star squares or star cubes currently in use with circles or spheres. I do not mean that the round replacement structures should fit inside the current square/cubic ones, but rather that they should entirely cover the square/cubic structures. In other words, the 4 or 8 points that make up the corners of the current squares or cubes would coincide with the new circles/spheres.

Notice that this will result in some seemingly arc-shaped overlaps like narrow lunes of an orange, as opposed to the current foursquare system where there is no sectional overlap whatsoever. However, a curved overlap will be much less noticeable than hard, straight, right angle skybox seams.

To help visualize my solution, if my description is unclear:. Draw four dots in a square on a piece of paper; this is the current system. Now draw a circle that intersects all four of those points; that is my proposed change.

Unless you have some incredibly bizarre rendering system in place for the skybox, this should be an easy change to make.

^ Notice the figure in the lower right hand corner. Due to the overlapping regions of circular-shaped structures, there will need to be a dense core of stars, surrounded by a less dense periphery. When two circles/spheres overlap, there will therefore be a gradient in these overlap regions.

 

[Ian Doncaster]

The problem is, the squares are not primarily a rendering issue, but a reflection of there actually being giant cubes of B-class stars wandering the galaxy.

To make them spherical or otherwise less hard-edged would require a complete rewrite of the galaxy generation algorithm to put the stars in a different place - and on that major a level, this would require a full reset of the game map outside of a small number of non-procedural systems.

It's a bug, but it's not a reset the galaxy and throw out everyone's first discoveries level of bug.

 

[varonica]

Greetings FDev! I am halfway through a very long excursion towards the galaxy's center, and have encountered the obtrusive square regions of stars that many CMDRs have commented upon in these forums. I personally don't mind them too much, but I can see how some feel that they are immersion breaking. I believe I have a simple solution to this problem that will at least mitigate it a bit.

I'm unsure whether these star squares are 2-dimensional overlays or actual 3D cubes, but my solution should work either way.

Simply replace the star squares or star cubes currently in use with circles or spheres. I do not mean that the round replacement structures should fit inside the current square/cubic ones, but rather that they should entirely cover the square/cubic structures. In other words, the 4 or 8 points that make up the corners of the current squares or cubes would coincide with the new circles/spheres.

Notice that this will result in some seemingly arc-shaped overlaps like narrow lunes of an orange, as opposed to the current foursquare system where there is no sectional overlap whatsoever. However, a curved overlap will be much less noticeable than hard, straight, right angle skybox seams.

To help visualize my solution, if my description is unclear:. Draw four dots in a square on a piece of paper; this is the current system. Now draw a circle that intersects all four of those points; that is my proposed change.

Unless you have some incredibly bizarre rendering system in place for the skybox, this should be an easy change to make.

View attachment 131015

^ Notice the figure in the lower right hand corner. Due to the overlapping regions of circular-shaped structures, there will need to be a dense core of stars, surrounded by a less dense periphery. When two circles/spheres overlap, there will therefore be a gradient in these overlap regions.

As already said, you are assuming this is a display artifact where they can just adjust the shapes with a shader, but as already mentioned it's not, it's actually an artifact of the procedurally generated galaxy. The squares are actually there in the virtual galaxy. Creating the galaxy with overlapping circles (actually spheres) really wouldn't work because FDEV would no longer be able to match the star count per volume to the actual star count in that region due to stars from the neighbouring region intruding on that region.

Anyway the point is, as mentioned, it would require regenerating the galaxy from scratch. There may be some way they can lessen the effect using shaders, but reshaping the squares won't work.

 

[Bloodsign]

Ah, interesting! I wondered if this was the case. So if I understand this correctly the stars as presented in the skybox are the ACTUAL realspace locations of star systems? Because the galaxy was initially divided into cubes which were then density populated, these cubes are essentially "hard-wired" in at this point?

A bit of a sticky situation, because as others mentioned, deleting real systems to adjust things eliminates discoveries that CMDRs have made. There is still a fairly simple solution here though:

The issue seems to arise around the borders of the superdense cubes, and is largely due to the cubes being consistently dense throughout. An algorithm could be written to process these superdense cubes; all stars within the cube would be moved towards the center of the cube, with the distance moved being based on the original distance from the center. Thus, stuff already in the middle of the cube would move a little or not at all, while stuff on the periphery would move a great deal. The movement formula would be adjusted so that the resulting peripheral density would be optimal for blending nicely into adjacent cubes. This approach has the benefit of neither adding nor subtracting systems, so no CMDR will have their work negated.

From what I can see only the superdense cubes need to be adjusted, I'm not sure I understand the "regenerate the whole galaxy" argument.

 

[Robert Maynard]

You might find this interesting:

Source: https://www.youtube.com/watch?v=Vz3nhCykZNw

 

[Ian Doncaster]

So if I understand this correctly the stars as presented in the skybox are the ACTUAL realspace locations of star systems?

Correct. There's a bit of room to play with the distance each brightness of star is drawn at ... but not very much or the sky in Sol would look very wrong, and within the ranges possible the cube problem isn't going away.

From what I can see only the superdense cubes need to be adjusted, I'm not sure I understand the "regenerate the whole galaxy" argument.

The thing to remember is that the galaxy doesn't actually exist, most of the time. There are 400 billion systems, so if you just go for storing a basic position (to the resolution the game stores it) and primary star class, it would take over 20 terabytes of storage to record them all. Most players don't have a 20 TB disk just to dedicate to storing the Elite Dangerous galaxy. Even storing the tiny subset - less than a percent of a percent - that sites like EDSM have recorded presents the 3rd-party developers with significant challenges.

So instead every region of it is generated - quickly - as needed, when you do something that's relevant like looking at the galaxy map, or jumping to a new system and generating the skybox. The video Robert posted goes into a lot more detail about how.

That means that Frontier can't just change some bits of it - they have to change the entire generation algorithm. And if they do that, then any systems which have already been visited would move, and possibly change contents. They could add exceptions to those systems - as they've done for ones like Sol - so that they stayed where they were, but that would require >100 million exceptions, which would be in the minimal case another 6GB on the size of every Elite Dangerous installation, or considerably more if it also needed to store more than just the base system position.

 

[Bloodsign]

Correct. There's a bit of room to play with the distance each brightness of star is drawn at ... but not very much or the sky in Sol would look very wrong, and within the ranges possible the cube problem isn't going away.


The thing to remember is that the galaxy doesn't actually exist, most of the time. There are 400 billion systems, so if you just go for storing a basic position (to the resolution the game stores it) and primary star class, it would take over 20 terabytes of storage to record them all. Most players don't have a 20 TB disk just to dedicate to storing the Elite Dangerous galaxy. Even storing the tiny subset - less than a percent of a percent - that sites like EDSM have recorded presents the 3rd-party developers with significant challenges.

So instead every region of it is generated - quickly - as needed, when you do something that's relevant like looking at the galaxy map, or jumping to a new system and generating the skybox. The video Robert posted goes into a lot more detail about how.

That means that Frontier can't just change some bits of it - they have to change the entire generation algorithm. And if they do that, then any systems which have already been visited would move, and possibly change contents. They could add exceptions to those systems - as they've done for ones like Sol - so that they stayed where they were, but that would require >100 million exceptions, which would be in the minimal case another 6GB on the size of every Elite Dangerous installation, or considerably more if it also needed to store more than just the base system position.

Good info, thank you.

I can't see that altering the on-the-fly generation system for superdense cubes only would add that much data to the end-user install though. For one, there's no reason to change the internals of the star systems at all, just the position of the star system within the cube, to mitigate border blending.

Or maybe I'm making an unwarranted assumption here, I would ASSUME that either:

1. Planets are located relative to suns, moons are located relative to planets, and stations are located relative to the bodies they orbit, therefore all that needs to be done is to reposition the main stars and everything else follows,

OR

2. Star systems are like desktop folders, everything contained inside and moving the folder on the desktop doesn't affect the contents at all.

Or are we dealing with a system (God help us) where every element (stars, planets, asteroids, stations, etc.) has absolute coordinates relative to an origin point (center of the galaxy, for example) and must be repositioned individually? If so, that was a terrible design choice and we are definitely stuck.

 

[Enderby]

I like your blanket.

 

[Azmuth Divarchchron]

Ah, interesting! I wondered if this was the case. So if I understand this correctly the stars as presented in the skybox are the ACTUAL realspace locations of star systems? Because the galaxy was initially divided into cubes which were then density populated, these cubes are essentially "hard-wired" in at this point?

A bit of a sticky situation, because as others mentioned, deleting real systems to adjust things eliminates discoveries that CMDRs have made. There is still a fairly simple solution here though:

The issue seems to arise around the borders of the superdense cubes, and is largely due to the cubes being consistently dense throughout. An algorithm could be written to process these superdense cubes; all stars within the cube would be moved towards the center of the cube, with the distance moved being based on the original distance from the center. Thus, stuff already in the middle of the cube would move a little or not at all, while stuff on the periphery would move a great deal. The movement formula would be adjusted so that the resulting peripheral density would be optimal for blending nicely into adjacent cubes. This approach has the benefit of neither adding nor subtracting systems, so no CMDR will have their work negated.

From what I can see only the superdense cubes need to be adjusted, I'm not sure I understand the "regenerate the whole galaxy" argument.

Yes

If you travel far enough in the galaxy you start noticing the star field change because its actively tracking where those stars are and the amount of light making it to that point in space from said stars.
It even goes as far to simulate how much cosmic gas is obstructing light from stars that are behind them relative to your current position.
Even in hyperspace those 2 or more large balls of light you pass by are stars that it is keeping track of.

 

[Sea_Kerman]

No, our problem, as I understand it, is that we can’t move the systems without completely reconfiguring the galaxy.

 

[Bloodsign]

I like your blanket.

Hehe, thanks, I guess. Though I was really hoping to get some compliments on my exquisite penmanship.

 

[varonica]

Ah, interesting! I wondered if this was the case. So if I understand this correctly the stars as presented in the skybox are the ACTUAL realspace locations of star systems? Because the galaxy was initially divided into cubes which were then density populated, these cubes are essentially "hard-wired" in at this point?

That's exactly correct, the video someone has linked below your post is well worth watching all the way through, even the bits about body generation.

 

[MadDogMurdock]

No need to move the systems.
The solution is in the rendering of the skybox.

Use the star density of the neighbouring cubes to affect the skybox rendering of stars.
At the boundary between a dense and less dense cube, on the denser side of the boundary you'd render fewer of the stars than normal, and on the less dense side render more.
The general effect would smooth out the boundary into a gradient rather than a hard boundary.

 

[varonica]

That would be an ideal solution, change the way it looks without changing the galaxy itself, but we are dealing with unknowns here, no-one has ever rendered an entire galaxy before, who knows what other artifacts may arise out of FDEV's attempts to fix it, indeed they may have tested a few idea already and found them worse than the existing situation.

 

[Bloodsign]

That would be an ideal solution, change the way it looks without changing the galaxy itself, but we are dealing with unknowns here, no-one has ever rendered an entire galaxy before, who knows what other artifacts may arise out of FDEV's attempts to fix it, indeed they may have tested a few idea already and found them worse than the existing situation.

I'm sure they could somehow tinker with the visuals without affecting core functionality though. Even a trial-and-error approach could work, if they enlisted the help of traveling CMDRs to test the views after each update.