I'm not sure that can be fixed can it?
The position & type of stars (B & O-class) will be baked into place by the Stellar Forge, which is also what produces the cubes. Potentially the brightness of each star could be varied at the point where the skybox is generated as the player jumps into each system I suppose, it would be a lot of work.
I think the way the galaxy was recreated in the game is an amazing piece of art, that it has imperfections like this an acceptable compromise of procedural generation imo.
Captain Archer was the best captain IMO. He was the true pioneer of the lot.If it attacks you please don't call a conference like Picard. Give it everything you got, like Kirk would.
No - there was supposed to be a fix for some of the display issues in the core, where the sheer number of nearby stars overwhelmed the skybox generator and led to the only displayed stars being over at one end of the skybox - I haven't been back that way since to see if it worked, though.I though this was supposed to be fixed?
I think they once looked worse than they do now. Theoretically this can be somewhat "fixed" during skybox generation, maybe by not displaying all the stars close to the border with a more sparsely-populated cube.
The existence of the cubes is baked in but the way the skybox renders stars is not.No - there was supposed to be a fix for some of the display issues in the core, where the sheer number of nearby stars overwhelmed the skybox generator and led to the only displayed stars being over at one end of the skybox - I haven't been back that way since to see if it worked, though.
The existence of the cubes is unfixable in Elite Dangerous, and the visibility of them would only be fixable by reducing the apparent brightness of B-class stars substantially.
(Good demonstration of how a fully procedural algorithm can still produce recognisable repeating patterns, though, for the Odyssey terrain arguments)
The existence of the cubes is baked in but the way the skybox renders stars is not.
A relatively simple algorithm to compare neighbouring cubes and smooth how many stars get rendered towards the boundaries would go some way to covering up the bones of the system. I.e render more towards the side of the less dense cube and fewer on the matching side of the more dense cube.
The skybox is already selective about which stars get rendered. This just modifies the selection of which stars to render.One of the issues with doing it like that is, every star you see outside the cabin when you are playing the game is actually a star, the same with nebula, once you start adding and removing stars and/or nebula then what's the point of using the galaxy map to render the skybox at all? Just throw up a realistic looking starscape for where the player is located, that would save some rendering time.
I would be against that method of fixing the problem because we are no longer looking at the galaxy we are flying through. Sure increase or decrease the contrast slightly to make the edges less apparent but not add/remove stars to blend the edges because you no longer know what you are flying towards!
It's probably rendering all of the B-class ones in the less dense cube already, and some of the density changes are pretty spectacular so would be noticeable even skipping 90% of the denser cube. The straight-line/right-angle corner nature of the change would still be noticeable.The existence of the cubes is baked in but the way the skybox renders stars is not.
A relatively simple algorithm to compare neighbouring cubes and smooth how many stars get rendered towards the boundaries would go some way to covering up the bones of the system. I.e render more towards the side of the less dense cube and fewer on the matching side of the more dense cube.
You're not wrong.Can we prove that's not what the sky would look like from that galactic view point? No. So who's to say it isn't accurate?