Or their very own money tree.
High Metal Content Worlds: 2014 vs 2017 comparison!!!!
- Thread starter Mengy
- Start date
Or their very own money tree.
I honestly think is about resource, the xbone can't stand toe to toe with a average PC build, I'm not putting consoles down... I have a PS4... I think there are two forces at work here.
1) Resource to keep two versions alive is not available (PC v's xbone)
2) Microsoft's firm grip on avoiding - "OMG the PC version is loads better than the xbone OMG"
1) Resource to keep two versions alive is not available (PC v's xbone)
2) Microsoft's firm grip on avoiding - "OMG the PC version is loads better than the xbone OMG"
Nope. It's pretty standard. All the console manufacturer's do it. My friend couldn't even tell me in a private chat what the advantages were from one console to the other. All he could say was, "I'm impressed with the capabilities of the hardware." That was the phrase they were told to say if anyone asked.
Here's my 2 cents (terrain generation used to be my thing once) based on hunches and some professional knowledge:
Colour palette and texture variation is probably dependant on the data that is pulled from the procedural engine and stellar forge and is done in real time as you approach a planet and its surface. I expect the height map is also done at the same time in a similar way and probably co-dependently. This is CPU intensive as well as GPU as the CPU has to "unpack" all the dat and then stream the resultant texturing and height map data to the GPU which then handles rendering (it possible that the GPU might also handle part of this but not the procedural stuff which is like a compression routine in reverse).
The rich looking planets in the early Horizons versions were probably pulling a lot of data to manufacture the textures and terrain features and I remember many people had stuttering issues where there even quite powerful rigs were pausing for a second or longer whilst all this stuff was being generated. I expect to mitigate this FDev essentially put a filter on the data from stellar forge and/or the procedural part of the engine for texture and terrain generation, which meant less workload on the CPU (and GPU) and less or no stuttering. It would be like unzipping a bitmap and only pulling out the data for and displaying 256 colours, rather than 16.7 million - you get the same image but less definition and colour variety.
IIRC there was also a hit in multi-player heavy areas and that might be because network updates are often tied to the cyclic rates in other parts of the engine.
I very much doubt consoles had much to do with the changes, but they would certainly have benefited them, by keeping the performance acceptable.
The question is can other optimisations allow the full or at least more data to be used and will/can FDev allow for a richer look for those with machines that can handle it? For the latter I suspect not as FDev have not allowed much in the way of differential options for differing machine specs. I can understand why, because if you give the option to "go large" everybody does and then bleats on the forums about poor coding when their 5-10 year old rig doesn't give them 144FPS. Better to "go medium" in that case and hope you can optimise in the future or wait until the general population has upgraded enough to allow you to "open the taps" again.
Here's hoping optimisations can be found similar to the way they managed for the planet rings.
Colour palette and texture variation is probably dependant on the data that is pulled from the procedural engine and stellar forge and is done in real time as you approach a planet and its surface. I expect the height map is also done at the same time in a similar way and probably co-dependently. This is CPU intensive as well as GPU as the CPU has to "unpack" all the dat and then stream the resultant texturing and height map data to the GPU which then handles rendering (it possible that the GPU might also handle part of this but not the procedural stuff which is like a compression routine in reverse).
The rich looking planets in the early Horizons versions were probably pulling a lot of data to manufacture the textures and terrain features and I remember many people had stuttering issues where there even quite powerful rigs were pausing for a second or longer whilst all this stuff was being generated. I expect to mitigate this FDev essentially put a filter on the data from stellar forge and/or the procedural part of the engine for texture and terrain generation, which meant less workload on the CPU (and GPU) and less or no stuttering. It would be like unzipping a bitmap and only pulling out the data for and displaying 256 colours, rather than 16.7 million - you get the same image but less definition and colour variety.
IIRC there was also a hit in multi-player heavy areas and that might be because network updates are often tied to the cyclic rates in other parts of the engine.
I very much doubt consoles had much to do with the changes, but they would certainly have benefited them, by keeping the performance acceptable.
The question is can other optimisations allow the full or at least more data to be used and will/can FDev allow for a richer look for those with machines that can handle it? For the latter I suspect not as FDev have not allowed much in the way of differential options for differing machine specs. I can understand why, because if you give the option to "go large" everybody does and then bleats on the forums about poor coding when their 5-10 year old rig doesn't give them 144FPS. Better to "go medium" in that case and hope you can optimise in the future or wait until the general population has upgraded enough to allow you to "open the taps" again.
Here's hoping optimisations can be found similar to the way they managed for the planet rings.
**** Scientific accuracy. Make the planets pretty to look at. Realism should not impede good gameplay.
verminstar
Banned
So yer saying FD intentionally lied when they said it was fer realism? Fairly serious assumption to make without anything other than yer imagination it back it up with. So if FD stick to their 'lie' by holding to their stance that it was ddne fer realism purposes, Im sure you can protest their sincerity with actual proof they lied?
Lemme know how that goes ^
Last edited:
verminstar
Banned
I know the grammar...Im just lazy and type with an accent...dont even realize Im doin it half the time. On the plus side, it really doesnt bother me at all ^
The downgrade most likely isn't because of consoles. Ice worlds and rocky ice worlds (and for the most part rocky worlds) remain unchanged since 2.2, so if the consoles were having issues with stellar forge then these worlds would have changed too. Only HMC and MR worlds were beige-ified in 2.2 though.
It's either a mistake or Frontier changed them intentionally for (most likely) creative reasons, we just have no way of knowing without Frontier speaking up on this issue.
It's either a mistake or Frontier changed them intentionally for (most likely) creative reasons, we just have no way of knowing without Frontier speaking up on this issue.
A PERIOD!!!! That's what goes at the end of a sentence!!!! A PERIOD! LIKE THIS. <--- SEE! BAAAAAAAAAH
^ doesn't mean anything at all!
Last edited:
This is an excellent post, and exactly what I was saying in my earlier post about randomization ranges, Teatime just said it much better. I suspect you are right: they limited the ranges that HMC and MR worlds use for the worldgen for some reason. Most likely performance issues, but the fact that the ice worlds and rocky ice worlds are unchanged is what really perplexes me because they would have been downgraded too if performance issues were the reason.
verminstar
Banned
No, rocky worlds have not changed as Im sitting at the base of mount everest cousin with a ringed water world within 0.2 ly away...this is the moon and its a mountain lovers wet dream. Just found it at teatime so no time tae get selfies yet, but they the biggest Ive seen in ages...means a weekend of joyriding and probably lose my last srv in the process ^
Im actually not a hundred percent sure how to post up pics from the bone...I know it can be done but I lost my password into photobucket and cant get to my library to post the links with. Working on it...tis a game of three halfs ^
Im actually not a hundred percent sure how to post up pics from the bone...I know it can be done but I lost my password into photobucket and cant get to my library to post the links with. Working on it...tis a game of three halfs ^
Even if it's realistic, which i'm not sure it is, it's ugly as sin and makes exploration rather depressing, all MR/HMC above 900-1000km radius look effectively the same, they have little color variation (grey, beige, brown) and even less terrain variation, just a smooth ball with proceduraly placed craters in a grid pattern and one or a few large, perfect frying pan craters.
Anyone glancing at bodies in the real Sol system should know that basing the color of worlds on star color is rubbish. Sure, the color of the star has an effect, but it's not enough to render a whole world beige. The materials present in the crust play a bigger role in determining color. That's optical physics 101.
Anyone who's visited white icy planets orbiting pure red stars will note that not everything is tinted red. Anyone who's been to the ruins sites will note that nothing about the surface of the various planets reflects the color of the parent star. So this theory that starlight is the reason for the change is rubbish.
First off the current planets are bugged. As frontier have said multiple times they changed the way main stars handle their lighting and gave them all a beige color. Its not intentional just not important enough to fix with a hotfix. Secondly unfortunately not every computer has a good enough GPU to run such detailed planets even on low. The game needs to be able to run on the average gaming computer + consoles. The game cannot give players with better computers completely different looking planets. Thirdly those planets were not landable on. Those spheres had a single painted texture on them. As you got closer quality would continue to decrease and decrease. By the time you landed on the planet one pixel of that texture would extend for miles.
- - - Updated - - -
The slider doesn't push anything to you CPU. The slider just decreases overall planet quality and has your GPU make less calculations. The CPU cannot help with planet generation. Planets use Compute Shaders, your CPU does not have the ability to use them.
- - - Updated - - -
The slider doesn't push anything to you CPU. The slider just decreases overall planet quality and has your GPU make less calculations. The CPU cannot help with planet generation. Planets use Compute Shaders, your CPU does not have the ability to use them.
Last edited:
You all smoke crack.
I love the beige planets! I enjoy the feeling I get when I see the same planet over and over. I like the 'I've been here before' feeling with every planet.
Not really. I'm with you OP. I miss the variations.
#EffBiege.
I love the beige planets! I enjoy the feeling I get when I see the same planet over and over. I like the 'I've been here before' feeling with every planet.
Not really. I'm with you OP. I miss the variations.
#EffBiege.
There isn't such a post. However there are at least a couple where devs have said the current planet colors are affected by star lighting in ways that wasn't intended.
Actually...
Look up ObsidianAnts posts.
It may be there. Pretty sure it is. Maybe.
I'm too tipsy and dont give a crap enough to do it myself.
So... yeah.