FreeGameDev

Something has been changed to the texture reflection feature since STK v1.3. I think it was motivated by the this issue: https://github.com/supertuxkart/stk-code/pull/4575 . While these changes seem to work better in that single case, reflections now have disappeared from most other tracks. This affects my track Dyson Speedway as well as some others like skindoormimizs Waphin. Most standard tracks are rather bright, so I guess that's why no one else really cared about this before.

To get visible reflections you now have to set them to almost maximum (red PBR texture with almost full saturation). This makes it harder to adjust the strength of the reflections, because the range for the adjustment is much smaller. Before the full range (0-255) was usable and now it is down to rather 200-255.

Most important for my work is, if this is something that happened unintended and will be fixed in future or if this is the new state of the art of using reflections in STK?

For the new version of Dyson Speedway (https://forum.freegamedev.net/viewtopic ... 18&t=18044) I'm currently thinking of doubling certain parts of the track and using scripting to ask for the users STK version. Otherwise either STK v1.3 users have hardly any reflections at all or STK v1.2 and lower (and I'm sure there still are many) have extreme reflections on track which can be disturbing.

A proper implementation of Screen-Space Reflections (SSR) would use mipmapping and Gaussian blur to progressively increase the sharpness of the reflection from "super fuzzy" at a low shininess level (e.g. 0.2) to "perfect mirror" at 1.0. This matches how reflectivity works in real life, and provides a good looking result. The current, "dumb" implementation in STK, instead just mixes in the reflection based on the reflectivity value, resulting in a sharp, mirror-like reflection even on objects that should be rough. The compromise I made in the PR is to only mix on a 0.5-1.0 range, so objects meant to be rough would not act as a mirror. (A side effect was skipping the SSR calculation code on surfaces with a reflectivity less than 0.5, which brought a noticeable rendering speedup, as before it was calculated even for surfaces with a value of 0).

As for how to support STK 1.3 vs 1.2's implementation, I'd suggest aiming for 1.3, as 1.2 and below won't connect online on most platforms anyways due to an expired certificate. I will note that things will likely change again anyways in STK 2.0 with the new Vulkan renderer, theoretically we will have proper mipmapping in the SSR implementation, rather than band-aid fixes and hacks (and maybe even an option for ray-traced reflections? It'd be nice

Thanks for your reply QwertyChouskie.

QwertyChouskie {l Wrote}:...things will likely change again anyways in STK 2.0 with the new Vulkan renderer, theoretically we will have proper mipmapping in the SSR implementation, rather than band-aid fixes and hacks (and maybe even an option for ray-traced reflections? It'd be nice

Yes, that sounds good. Any idea when STK 2.0 might be released (months, years, decades )?

RX1 {l Wrote}:Yes, that sounds good. Any idea when STK 2.0 might be released (months, years, decades )?

It's hard to say, generally releases come every ~1-1.5 years, but it could be longer given the large change to take place.

There will be 1.4 instead of 2.0 btw due to not enough new tracks