Beta Testing 2.08

[duzenko]

1 hour ago, duzenko said:

A bigger issue here is the sliders are supposed to have nozzles (and I think they did at some point?)

Feels like a major UX problem

Made a fool of myself

The thumb shows with image_preload 1 (default value)

[duzenko]

Assets revision: 15925

Should fix the GUI feedback for gamma and brightness

[nbohr1more]

6 hours ago, duzenko said:

Assets revision: 15925

Should fix the GUI feedback for gamma and brightness

Cannot compile:

                 from /home/randy/tdm_src/trunk/framework/Console.cpp:17:
/home/randy/tdm_src/trunk/framework/../renderer/GuiModel.h:16:10: fatal error: ..\ui\Rectangle.h: No such file or directory
 #include "..\ui\Rectangle.h"
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

Probably needs to be added to the Linux project files?

 

[stgatilov]

11 hours ago, cabalistic said:

Not exactly a regression, no. Gamma/brightness were completely reimplemented and are no longer changing the desktop/OS gamma, but instead handling it ingame as an image post-processing step. Unfortunately, the consequence is that it no longer affects the menu. In all likelihood we'll remove the popups for this release, as it'll take some effort to make them work with the new implementation.

There was an idea of creating a new GUI screen which would show in-game screenshot with sliders including gamma, brightness, and other postprocessing settings.

See 5163

[lowenz]

And it's a good idea!

Ah, maybe move the "language" choice to a "game" section along with the "gameplay"  elements.

[duzenko]

2 hours ago, stgatilov said:

There was an idea of creating a new GUI screen which would show in-game screenshot with sliders including gamma, brightness, and other postprocessing settings.

See 5163

It's possible and should be quite simple actually

The currentRender persists when the GUI menu shows

Or we could have a fixed screenshot as a texture

[duzenko]

3 hours ago, nbohr1more said:

Cannot compile:

                 from /home/randy/tdm_src/trunk/framework/Console.cpp:17:
/home/randy/tdm_src/trunk/framework/../renderer/GuiModel.h:16:10: fatal error: ..\ui\Rectangle.h: No such file or directory
 #include "..\ui\Rectangle.h"
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

Probably needs to be added to the Linux project files?

 

Wrong slash in include path

Try now

[nbohr1more]

5 hours ago, duzenko said:

Wrong slash in include path

Try now

Thank you.

[nbohr1more]

SSAO Comparisons:

OFF:

 

ON:

 

 

OFF:

 

 

ON:

 

 

OFF:

 

 

ON:

 

[nbohr1more]

OFF:

 

 

ON:

 

 

OFF:

 

 

ON:

 

 

[demagogue]

You can definitely see the situations where it contributes, daytime outdoor scenes and big stretches of light-colored textures that break up the texture and give it some dimensionality, both of which are kind of rare for our game environments, but it makes a big difference when it makes a noticeable difference at all.

[nbohr1more]

Yeah, a mission like "Full Moon Fever" with ultra dark ambient light lots of direct lighting, interesting contrast lights,

interesting light textures and lighting that naturally enhances the shapes of objects does not benefit at all.

[cabalistic]

AO exclusively affects ambient lighting - if ambient is weak or overlaps with direct light, you won't see much of an effect. Also, a few missions have some AO already baked into the textures, reducing the difference.

If you really want to see SSAO in action, I can recommend William Steele 5

[stgatilov]

18 minutes ago, cabalistic said:

AO exclusively affects ambient lighting - if ambient is weak or overlaps with direct light, you won't see much of an effect. Also, a few missions have some AO already baked into the textures, reducing the difference.

Yeah, also keep in mind that the ugliness of SSAO is not noticeable on still screenshots.
It exhibits light leaking behind edges of big occluders, which catch attention as unnatural when you move around.

[Oktokolo]

I only use the lowest SSAO setting and it definitely improves all scenes noticably (even in missions where the author added "fake SSAO" on some edges). For me, it makes bright and dark environments more believable by adding that tiny amount of extra darkness where it belongs.
SSAO is not as impactful as soft shadows. But i would miss it if it would disappear.

[STiFU]

29 minutes ago, Abusimplea said:

even in missions where the author added "fake SSAO" on some edges

I guess mission authors should refrain from adding these grime decals now that we finally have SSAO.

[peter_spy]

4 hours ago, STiFU said:

I guess mission authors should refrain from adding these grime decals now that we finally have SSAO.

That kinda depends, AO is a generic effect and as such it won't replace dirt accumulation, water stains, etc.

[grayman]

We'll continue to use stains because they provide effects other than edge occlusion.

[STiFU]

2 hours ago, peter_spy said:

That kinda depends, AO is a generic effect and as such it won't replace dirt accumulation, water stains, etc.

Sure! I was just getting at the Fake-AO decals. I've seen people use such decals on every step of a staircase. That's stuff we probably won't need anymore.

[HMart]

5 hours ago, STiFU said:

Sure! I was just getting at the Fake-AO decals. I've seen people use such decals on every step of a staircase. That's stuff we probably won't need anymore.

For stuff like geometry corners I don't think spending time on fake AO is now a good idea, large patch's of grime/dirt yes but small fake AO will just get superseded by the AO darkening.

Btw AO is a high end effect like you know and it will take a percentage of performance away from people, depending on the card it could be considerable and they will have to turn the effect off, so if you remove the hand made AO and the SAO, they will get less graphical fidelity, is a trade off that imo you guys have to think about.   

Edited May 12, 2020 by HMart

[peter_spy]

1 hour ago, STiFU said:

I've seen people use such decals on every step of a staircase. That's stuff we probably won't need anymore.

Oh, absolutely, that's a bad idea in general, as it could increase drawcall count quite substantially.

[lowenz]

About the SSAO: https://gpuopen.com/fidelityfx-cacao/

[cabalistic]

47 minutes ago, lowenz said:

About the SSAO: https://gpuopen.com/fidelityfx-cacao/

I've seen it, but there's only an implementation for DX12, and given the sheer size of the shader file, that would be a monumental task to port Also, it's using compute shaders, which we don't (yet) support in the engine. That's also what stopped me from using Intel's ASSAO, which seems conceptually similar, and going for the older, but simpler SAO.

[HMart]

48 minutes ago, lowenz said:

About the SSAO: https://gpuopen.com/fidelityfx-cacao/

The current AO even being based on Nvidia code, imo runs reasonably well on my AMD gpu (RX 570X), I bet is not running as fast as it could, for obvious reasons but again runs well enough "in my case".

Also how many here have RDNA based AMD GPU's? I have a GCN based one. 

Cabalistic if it was you that implemented the TDM AO, what was the reason to prefer Nvidias SAO above lets say vendor agnostic Crytek SSAO? Documentation? Performance? Quality?  Just curious. 

[cabalistic]

Nvidia's SAO isn't really specific to Nvidia cards. All the techniques it uses are in some way also present in the FidelityFX implementation or Intel's ASSAO, those just add a couple additional advanced optimizations

Reasons for SAO: it was well documented, had an OpenGL sample implementation, good license, was reasonably simple to implement in a reasonable amount of code (definitely much less than the afore-mentioned ones!) and offers reasonable quality at reasonable performance - not fully state of the art, but also significantly better than some basic implementations that you often find in tutorials (and which I started with in my first attempt)