Improper Rendering - New w/ Page 7

[JelloMold]

Fun new feature when I loaded up Page 7 today. The world doesn't... draw itself right? It didn't do this yesterday. It's not doing it for other people I talk to. I'm not on the newest computer, but it's never had trouble with ultra+ graphics. Set my graphics to exactly the same as others in the same zones and they do not get this mess. I re-validated twice. Any tips or possible fixes welcome.

[Lunar Ronin]

Just to help with data collection, which graphics card (if any), are you using?

[Rudra]

I'm really hoping that whatever is causing that for you is why almost all the new wall art looks like shapeless blobs in a frame....

[Nishastra]

This is also happening to me. There's basically a huge gap between the horizon and the skybox. No graphics options change anything, nor does verifying the game.

 

Edited February 22 by Nishastra
Added screenshot

[Shenanigunner]

Try adjusting /visscale n — start with 5 and adjust up and down for best visual/fps balance. (Limits are 0-10).

 

This and other key settings have gone in and out of being persistent, so I have a standard "set visuals" keybind I can whack to set everything on start of a post-hangover/-apocalyptic/-update session.

 

F10 "visscale 10$$dofweight 0.5$$fsaa 4"

 

 

Edited February 22 by Shenanigunner

[Nishastra]

Increasing visscale makes the gap less ugly, but it doesn't get rid of it. This is with it at max.

 

[Night]

I made some posts about this issue in the patch discussion and was hoping the devs would respond to notes about it from others as well, but since it doesn't seem to get much traction as people are discussing other issues so you did a good thing of making a bug thread of it. With my initial lookaround, and then following that with more testing, the recent patch somehow broke render distance and water rendering. None seem affected by /visscale and are an issue even on the default visual distance.

 

The issues seem to be in heavily lowered render distance, testable by just flying back and forth along some trees and seeing the details on them pop in instantly once you get close enough whereas the details would face in gradually normally and the objects load in with more detail before the patch. You didn't need to be very close to the object to see its model fully loaded, which seems the case now with trees, rocks and even cars, as well as rooftop detailing. The water texture also is rendering on top of every other map effect, causing really uncanny views and in open maps it allows you to see the edge of the world.

 

The third part to it is the seeming removal of world fog that would blur the edges between the skybox and the rest of the map. All of those issues can be tested just by going to Ouroboros as it even has some trees, and just looking to the side you can see both the water textures rendering and see the square of it in the distance, as well as the lack of map fog which causes a weird bright ring to appear around the map area.

 

Edited February 22 by Night

[Lockely]

There is definitely some rendering weirdness going on in general this patch. Look at the balcony ahead of my character. I have everything set to max distance and it's still only rendering the shell until I take a few steps forward:

 

 

 

[JelloMold]

On 2/20/2024 at 10:29 PM, Lunar Ronin said:

Just to help with data collection, which graphics card (if any), are you using?

I'm on a Radeon RX 480 on this machine. Latest drivers. All settings cranked up and running fine aside from the documented rendering bugs.

 

Just attempted to do the V-day Red Widow arc and oh my god, the last mission is unplayable thanks to whatever's gone wonky in the spaghetti code.

[Number Six]

@JelloMold's first issue looks like possibly a corrupt shader cache. That can be cleared using the "Reset graphics settings on next run" option in the launcher, or if you don't want to do that, manually deleting [cohinstall]\cache\shaders.

 

What @Night and I think @Nishastra are seeing I believe is an issue with the new gamma correction not applying to the skybox fog... and apparently fogged-out water. I did a comparison between page 6 and page 7 in Ouroboros and it looks identical at 100% gamma, but moving gamma to the extremes in page 7 makes it obvious what's happening.

 

 

 

 

Workaround for now is to use 100% gamma or close to it when outdoors until that oversight can be fixed.

 

 

[Number Six]

9 hours ago, JelloMold said:

Just attempted to do the V-day Red Widow arc and oh my god, the last mission is unplayable thanks to whatever's gone wonky in the spaghetti code.

 

This is a completely separate issue specific to that mission (and a couple of Dark Astoria cave missions); we've got a fix in the pipeline for it.

[Nishastra]

Hmm, I've never touched gamma. It was already at 100%. If I change it, I can make this look drastically worse, but...

 

 

This is the same place in St. Martial as my other shots but with gamma turned down from 100%.

 

 

Also I can pretty easily replicate JelloMold's picture if I turn on water reflections and go to Port Oakes.

 

EDIT:

 

Okay, it's a shader. I restored older shaders and fiddled around until I found which one specifically. It's "multiplyRegfp.cg". When I use the older version of that, the gap goes away.

 

Edited February 23 by Nishastra

[JelloMold]

7 hours ago, Number Six said:

@JelloMold's first issue looks like possibly a corrupt shader cache. That can be cleared using the "Reset graphics settings on next run" option in the launcher, or if you don't want to do that, manually deleting [cohinstall]\cache\shaders.

Tried the Reset Graphics Settings option and it reset to... the same render issue.

 

4 hours ago, Nishastra said:

Okay, it's a shader. I restored older shaders and fiddled around until I found which one specifically. It's "multiplyRegfp.cg". When I use the older version of that, the gap goes away.

That last shot looks like heaven to me! If I were, say, a very dumb person who wanted to accomplish the same thing you did, do you have any tips on how I might go about that? 

[Nishastra]

2 hours ago, JelloMold said:

That last shot looks like heaven to me! If I were, say, a very dumb person who wanted to accomplish the same thing you did, do you have any tips on how I might go about that? 

 

Okay, if you extract this into your Homecoming/Data/ directory, it should override that one file with an older version.

 

(Removed, check next post if you need it)

 

 

The end result should be "Homecoming/Data/shaders/cgfx/multiplyRegfp.cg". And then just delete that file to undo this whenever.

 

I would assume that they updated this file for a reason so this probably breaks something, but I can't stand the huge ugly hole in the world so...

Edited February 24 by Nishastra

[Number Six]

There is definitely something screwy going on with that shader, had already identified it as a problem but it's been acting very strange and producing output that makes no sense. Finally got it to cooperate. There's one other problematic one that needs to be fixed as well that's making scene fog not affect some trees.

[Nishastra]

Huh, well, I learned something today: You can edit a shader file while the game is running and it will be reflected in real time. Thanks to that, I know with certainty that the line "out_color.rgb = calc_gamma_correction( out_color.rgb );" is the problem.

 

It seems to be mostly overriding the previous line, which calculates fog color. Having the gamma line there has almost the same results as just removing the fog line.

 

shaders2.zip

 

Here's a better version of my previous zip for anyone still wanting a quick fix. The file I had in there before would break cel-shading. This one shouldn't actually break anything, it just has the gamma line commented out.

Edited February 24 by Nishastra

[Azari]

Urrrg. Hope the HC team can get this fixed real quick. Seems like it should be simple and quick.

[Number Six]

21 minutes ago, Azari said:

Seems like it should be simple and quick.

 

Hahahaha, no, it's a complete nightmare I've been fighting for hours. out_color.rgb = calc_gamma_correction( out_color.rgb ); should work. It works fine in half a dozen other fragment programs. But in that one, it causes the fog calculation to go screwy in a way that defies logic. Reversing the order or changing random other things causes different seemingly non-deterministic behavior that makes no sense.

 

I went so far as to rewrite how the fog is handled so I can change the order and do it the opposite way, which makes it work correctly for multiplyRegfp (yay!). But doing that somehow breaks it for colorBlendDualfp, in a similar way. And let's not even talk about the headache that SSAO adds to the mix.

 

So yeah, about to throw up my hands and just do it in a postprocessing pass instead. I really didn't want to do that because you lose a little bit of color fidelity that way, but it may be the only way that's feasible with the house of cards that is the renderer.

[Injunuity]

just saw this, as i was doing the vday granville mission to use cupid's bow. if it's corrupt shader cache, it's happening while playing the game, as i use ccleaner to clear my temp files and shader cache (and to shutdown my computer) every night. yet these still happen. first is to show buildings in the background, 2nd is for the mobs at ground level.

[Number Six]

15 minutes ago, Injunuity said:

just saw this, as i was doing the vday granville mission to use cupid's bow. if it's corrupt shader cache, it's happening while playing the game, as i use ccleaner to clear my temp files and shader cache (and to shutdown my computer) every night. yet these still happen. first is to show buildings in the background, 2nd is for the mobs at ground level.

 

That one is a different issue specific to that map. A fix for it is in the pipeline and should be out soon.

[Injunuity]

5 minutes ago, Number Six said:

 

That one is a different issue specific to that map. A fix for it is in the pipeline and should be out soon.

nw, figured i'd post as well, since i'm doing something i hadn't seen in other posts. ie; clearing shader cache nightly

[Azari]

Welp. Good luck. Funny how something that looks so trivial could be so temperamental.

Edited February 24 by Azari

[Number Six]

Thanks, it's was quite frustrating. I ended up scrapping the whole thing and re-implementing it in postprocessing. There's a couple downsides to that but nothing major -- and it works without graphical glitches, so good enough.

[Night]

6 hours ago, Number Six said:

Thanks, it's was quite frustrating. I ended up scrapping the whole thing and re-implementing it in postprocessing. There's a couple downsides to that but nothing major -- and it works without graphical glitches, so good enough.

Thank you for figuring it out, I'd have never guessed it was the gamma setting that's at fault for this. Is it the same cause for the sudden seeming lowering in render distance as well? The distance finer detail on trees, rocks, rooftops and cars load in at seems to have been lowered and requires you to be much closer now before they suddenly pop-in, whereas normally the higher detail would begin loading onto an object and be a bit see-through when you were still a fair distance away from it, and become more 'solid' the closer you got, but I think it would fully load when you were still at a larger distance from it than how close you must be now for the details to suddenly pop-in. It's easier to check by flying back and forth along some trees and seeing their higher-detail bits just pop instantly once you get closer.

Edited February 24 by Night

[Number Six]

4 hours ago, Night said:

Is it the same cause for the sudden seeming lowering in render distance as well? The distance finer detail on trees, rocks, rooftops and cars load in at seems to have been lowered and requires you to be much closer now before they suddenly pop-in,

 

Yes, it's not actually causing pop-in, but what's happening is the fog distance calculation is wrong*, so the fog isn't hiding the transition like it normally does. Also if you have SSAO enabled, the difference in the scene fog calculation and the separate fog calculation that SSAO does causes abrupt transitions in brightness that look like pop-in.

 

* (the variable from the vertex program is not consistently getting passed through to the fragment program, thinking we may have hit a limit in the number of uniform variables but it's not showing up on the error console)