Planet graphics is broken in many ways and FDEV is in silence. Why?

[alexzk]

flat smudgy textures

That just means u have not enough avail VRAM for any reason, like
1. game bugs, yes still there - complete relaunch game once an hour or when landed.
2. don't press F10 - this makes screenshot which has a bug for sure eating VRAM
3. chrome/video capture soft/shadows in windows/too big screen.

Many more reasons you can Imagine, but textures get bad when not enough of VRAM for the game.

This behave is old from Horizons. On my old 1050 with 2Gb when I was flying + Tube with v9 codec game was dropping resolution to 400p with "blured textures" automatically until I close Tube.

 

[dubsdj]

I have a 1080ti so I think that should be able to handle it.

 

[alexzk]

I have a 1080ti so I think that should be able to handle it.

Not really, my new 2060 still shows flat surface periodically, reloading game helps usually. + this is common case for real flat ice like world where you have huge empty field without limiting mountains. So card just don't have enough VRAM. But on surface with mountains it's just perfect always.

 

[The Nephilim]

When you create a ticket, you see the similar tickets already opened. Just 'vote' saying you have the same issue.
Cheers.

Simple answer, no.

 

[denispage]

I will tell you what I see. I see now invisible rocks on the ground which drop shadows. How do you do invisible something? You just negate perpendicular vector to point inside bounding box, so textures will be "inside" and that makes them culled = invisible.
Now, was 3d designer so drank and made plenty of assets with wrong normal vector? No. I think those "assets" are generated. And generator has a bug, which flips vector. But this means it is not hand made asset, nor it is copy-paste.

If I'm not wrong it a process called "Baking". And it's bugged.

Edit: Baking: Baking materials in CGI traditionally refers to the process of changing all the calculated data that goes into rendering a surface, into an image map for that surface. As you said, doing a pre calculation to shortcut future render time. A simple example: You've got a 3D game where you're inside a house full of different kinds of lights. From the ambient light coming in the windows to the textures of the lights on the walls. All of these lighting calculations ultimately results in a beautifully realistically lit environment. Baking that house creates new textures that take into account the original wall texture plus all of the lighting, shadows, and even ambient occlusion. Then as you play the game it's merely showing you these textures rather than recalculating all of the lighting for every new frame. There are limitations. If you bake your scene at a certain resolution, and then while using the pre-baked seen in your playback get too close to a shadow or other feature. It will pixelate because the baked textures have reached their limit. Obviously in modern game design this is adjusted so that the texture is sufficient for the expected reasonable proximity of the viewer. In Elite dangerous with the massive changes in scale of the planetary surfaces, they must likely do this for several levels of detail. A lot of care has to go into how all of these image maps are created so when transferring from one level of detail to another it's not noticeable to the viewer. We see this a lot when transferring from orbital cruise to landing, depending on the planet, these transitions are painfully obvious. I can't speculate any further on what people are seeing other than to conclude that Frontier has abbreviated the process somehow, leading to noticeable redundant features.

 

[CMDR Von Abrahart]

Looking fine to me

 

[denispage]

Simple answer, no.

They said in many streams. Basically when many open the same ticket (choosing by one already open, searchable as soon as you fill the subject), the ticket enter in a queue until reach this point on the first page.

But the community manager could be wrong.

 

[denispage]

View attachment 248931

Looking fine to me

Brings so many good memories...

 

[CMDR Von Abrahart]

If I'm not wrong it a process called "Baking". And it's bugged.

Edit: Baking: Baking materials in CGI traditionally refers to the process of changing all the calculated data that goes into rendering a surface, into an image map for that surface. As you said, doing a pre calculation to shortcut future render time. A simple example: You've got a 3D game where you're inside a house full of different kinds of lights. From the ambient light coming in the windows to the textures of the lights on the walls. All of these lighting calculations ultimately results in a beautifully realistically lit environment. Baking that house creates new textures that take into account the original wall texture plus all of the lighting, shadows, and even ambient occlusion. Then as you play the game it's merely showing you these textures rather than recalculating all of the lighting for every new frame. There are limitations. If you bake your scene at a certain resolution, and then while using the pre-baked seen in your playback get too close to a shadow or other feature. It will pixelate because the baked textures have reached their limit. Obviously in modern game design this is adjusted so that the texture is sufficient for the expected reasonable proximity of the viewer. In Elite dangerous with the massive changes in scale of the planetary surfaces, they must likely do this for several levels of detail. A lot of care has to go into how all of these image maps are created so when transferring from one level of detail to another it's not noticeable to the viewer. We see this a lot when transferring from orbital cruise to landing, depending on the planet, these transitions are painfully obvious. I can't speculate any further on what people are seeing other than to conclude that Frontier has abbreviated the process somehow, leading to noticeable redundant features.

it clearly something in the ‘process’ but with profiling software they MUST know exactly what’s causing this - be it a card issue, caches and whatever. They’ve probably got all sorts of ‘Top Men’ ( people ) working on this. But looking at graphical loads is all part of Alpha and Beta testing. - something clearly not finished - its a shame .. but I’m optomistic that it’ll get done. It better as I’m a Kickstarter Backer and will be sad that if it all falls to bits.

 

[dubsdj]

What I found interesting was that when driving along a flat area on the planet, the SRV often will hit an invisible rock and completely flip the rover. This makes me think that the terrain generation isn't generating the terrain its supposed to but the the game surface does have the correct new terrain calculations and still thinks there is a big rock on the the surface, even though its not there.

 

[CMDR-ss47ply]

What I found interesting was that when driving along a flat area on the planet, the SRV often will hit an invisible rock and completely flip the rover. This makes me think that the terrain generation isn't generating the terrain its supposed to but the the game surface does have the correct new terrain calculations and still thinks there is a big rock on the the surface, even though its not there.

I get that all the time usually near where the fog or smoke generators are

 

[jojon]

I will tell you what I see. I see now invisible rocks on the ground which drop shadows. How do you do invisible something? You just negate perpendicular vector to point inside bounding box, so textures will be "inside" and that makes them culled = invisible.
Now, was 3d designer so drank and made plenty of assets with wrong normal vector? No. I think those "assets" are generated. And generator has a bug, which flips vector. But this means it is not hand made asset, nor it is copy-paste.

I am pretty sure that were this the case, you would see the textures drawn on the inside of the rocks, as usual when you have inward-facing normals -- I highly doubt they self-occlude in the manner you propose. I'd look elsewhere, for reasons they fail to render.

I also think we see enough repeat scatter rocks, from a not particularly large assortment, which quickly makes them only too familiar, and not seldom placed right next to one another, with identical alignment, that we can rule out them being procedurally generated.

...not enough avail VRAM...

That should limit one's machine's ability to deliver high resolution terrain patches, yes. I often have to sit around and wait for more detailed LODs to finish generating, but other than that, my 11GiB 1080Ti seems to suffice to hold a decent amount of patches of decently high-detail terrain, and the terrain feature bitmaps involved in its generation.

A healthy amount of supersampling should also make the game generate and use higher LODs for the higher render resolution - too bad we don't have the performance to do that and get tolerable frame rates; I am pumping the. render resolution in VR (...because surfaces look terrible at x1.0...), and man do the frames chug along...


I am i full agreement with here_it_comes, by the way, that the terrain-gen probably works exactly as intended; It is precisely in line with the vibe I got from doc. Ross' describing it; And that at least some on the team are probably surprised (...but shouldn't be, IMHO), and quite crushed that we don't like it.

 

[denispage]

it clearly something in the ‘process’ but with profiling software they MUST know exactly what’s causing this - be it a card issue, caches and whatever. They’ve probably got all sorts of ‘Top Men’ ( people ) working on this. But looking at graphical loads is all part of Alpha and Beta testing. - something clearly not finished - its a shame .. but I’m optomistic that it’ll get done. It better as I’m a Kickstarter Backer and will be sad that if it all falls to bits.

The way they said in the stream was something like: We know there is a issue, we're investigating and it's extremally hard. Obsidian Ant make a comment saying that could take months do solve.
I hope he's wrong heheheh.

 

[CMDR Von Abrahart]

The way they said in the stream was something like: We know there is a issue, we're investigating and it's extremally hard. Obsidian Ant make a comment saying that could take months do solve.
I hope he's wrong heheheh.

I dont know who Obsidian Ant is. But having worked in games at crunch time - these devs, coders, artists need our support - it probably wasn‘t their fault - they are probably at their desks Friday night pouring over code and trying to make graphics code work for the one million drivers and cards out there. Its a management decision to release a Beta not the devs.

 

[denispage]

I dont know who Obsidian Ant is. But having worked in games at crunch time - these devs, coders, artists need our support - it probably wasn‘t their fault - they are probably at their desks Friday night pouring over code and trying to make graphics code work for the one million drivers and cards out there. Its a management decision to release a Beta not the devs.

Definitively the release wasn't their decision, and it's unfair because now they're getting the heat.
We (players) should focus in open tickets and showing the bugs, and criticize all the management poor decisions, including all the promises they 'forgot'.

Obsidian Ant it's a famous Elite Youtuber. His voice is in the game.

Obsidian Orbital

Obsidian Orbital is an Ocellus Starport in the Maia system. It was built after the community goal Among the Stars. It has all services with the exception of Outfitting and a Shipyard.[1] Work on a new Ocellus starport began in the Kaushpoos system of the Pleiades Nebula on October 28, 3301...

elite-dangerous.fandom.com

 

[dubsdj]

I dont know who Obsidian Ant is. But having worked in games at crunch time - these devs, coders, artists need our support - it probably wasn‘t their fault - they are probably at their desks Friday night pouring over code and trying to make graphics code work for the one million drivers and cards out there. Its a management decision to release a Beta not the devs.

I completely agree, it's not the devs fault and they must all be under a lot of pressure, which I sympathise. I do not think that the million graphics cards and drivers argument is right though. I'm sure all those graphics cards and drivers have some standards that they follow, otherwise all games would be completely broken.

 

[CMDR-ss47ply]

I completely agree, it's not the devs fault and they must all be under a lot of pressure, which I sympathise. I do not think that the million graphics cards and drivers argument is right though. I'm sure all those graphics cards and drivers have some standards that they follow, otherwise all games would be completely broken.

until patch 5 GeForce now..... didn't even know odyssey was on my pc so I also think driver validation is a problem as well...as many other problems

 

[dubsdj]

until patch 5 GeForce now..... didn't even know odyssey was on my pc so I also think driver validation is a problem as well...as many other problems

Yeah, I don't know.. Just seems to me that the graphics cards / drivers shouldn't really be such a headache as thousands of games out there seem to be able to make use of them without too much trouble, but I get your point.

 

[CMDR Von Abrahart]

Thats the best my iPad can do at this time of night

 

[here_it_comes]

Definitively the release wasn't their decision, and it's unfair because now they're getting the heat.

It was clearly released too early, but not all the issues are due to being undercooked. Copy pasta terrain was a dev decision, and is the worst of the planet tech issues.

@Fishman Supporting creators of any kind only makes sense when they create content that is appreciated. Spouting, "Support X!" is only a testament to the fact that people aren't finding it worth it. It reminds me of my days in the local music scene. The worse a band was, the harder they pushed, "Support Local Music!". The people do support local music, your band just sucks.