SDFGI: Massive slowdown when the camera speed is too fast (even on empty scenes)

[ghost]

Godot version: no commit hash, as it was compiled by hand, but it's probably the one starting from here https://github.com/godotengine/godot/commit/f2149fe763a5678237b417fb9fefec5a5c74ae9d

OS/device including version: windows 10 1709 16299.431 vulkan r9 380 4 gb ggdr 5 1425 mhz

AMD stuff 2020.0729.1547.28422 20.20.01.13-200729a-357776E-RadeonSoftwareAdrenalin2020

Issue description: if you increase your camera speed, to a very high value, the framerate drops into the 20s

this is bad if you were to make, a space game with a space ship, which needs to fly VERY FAST this makes using the editor impossible, the framerate is too low and it's barely usable at all times

Steps to reproduce:

1. select the file system menu
2. double click on default_env.res
3. in the inspector menu, enable sdfgi
4. select the view port
5. move the camera around and increase the camera's movement speed until it starts to stutter (scroll wheel up)
6. your framerate is destroyed

Minimal reproduction project: even an empty project will do

if you move slowly, the framerate is fine if you move quickly, it all goes to hell

disabling SDFGI fixes the framerate

[Calinou]

Does it improve if you go to the Project Settings, decrease the number of SDFGI rays to 5 (the lowest) and increase the number of frames to converge to 30 (the slowest)? These are the settings I used in https://github.com/godotengine/godot/pull/39965.

Also, make sure to decrease the number of SDFGI cascades to 4 in the Environment resource. It's significantly faster than the current default (6).

[ghost]

i already lowered the number of cascades and it did nothing at all

it just looks worse and the framerate is still really low

the probe ray count only goes up to 8 not 5

changing the settings didn't help and the framerate is still low, it's beyond unusable ,

[Zylann]

In such scenarios I would imagine SDFGI should blend towards a much lower resolution, larger-scale area to adjust for a higher-speed motion scenario (or be turned off?), which is typically matching what happens with a spaceship. It goes faster, but further away from the map than a human character would be, and eventually sees further away. So we'd just need to change reference frame?

There are cascades but maybe they could be dynamic themselves? i.e if the game uses 4 cascades at once, upon scripted decision it could fade to 4 higher cascades (rather than being more than 4 all the time to sort of support them all, if you see what I mean)

Slow          Fast         Area size

---           Cascade 3      64
---           Cascade 2      32
---           Cascade 1      16
Cascade 3     Cascade 0      8
Cascade 2     ---            4
Cascade 1     ---            2
Cascade 0     ---            1

This above is use-case based, it would work really well with flying scenarios. For characters that can dash or go super-fast while remaining very close to the environment, there isnt much choice but to turn off the closest cascades because trying to keep them up to date at all times will demand too much work at once to the computer in a limited time (hence the limit I describe in my next post)

[ghost]

In such scenarios I would imagine SDFGI should blend towards a much lower resolution, larger-scale area to adjust for a higher-speed motion scenario (or be turned off?), which is typically matching what happens with a spaceship. It goes faster, but further away from the map than a human character would be.

my framerate shouldn't drop into the 20s when i have an empty scene, all i did was, i increased the camera's speed and it all went downhill from there

[Zylann]

In the current state of things, it will drop at least because it tries to relocate SDF volumes at a much faster rate, since the reference frame in terms of distances is not changing. Something in there is probably not dependent on scene complexity so performance just linearly decreases until it goes above frametime. Another thing that could occur is to limit how many times such "relocation" occurs, but @reduz may know more about what's going on.

If you think it should not happen specifically within an empty scene, then it's easily fixed by having SDFGI not run when the scene is empty, but that's probably not the fix you are expecting.

[ghost]

here's an even more barebones scene to showcase the problem (no sky or anything) this shouldn't happen, it makes the sdfgi system useless for any games which have the player moving at high speeds

[ghost]

If you think it should not happen specifically within an empty scene, then it's easily fixed by having SDFGI not run when the scene is empty, but that's probably not the fix you are expecting.

???

it should never do this in the first place, like, you have a scene with 3D models, the framerate drops, you have an empty scene, the framerate drops

there's clearly a problem in here, saying that, i should just never use sdfgi, seems like nonsense to me, i mean, to me it just makes the whole technique pointless, if it's not usable in 99% of most games

i mean immagine a racing game where you framerate drops this badly, do you just make all the cars, go really slowly? that's ridiculous

if someone were to make a wipeout styled game, they wouldn't be able to ever take advantage of the lighting system

i guess you can make a walking simulator with this system, but i don't know, i just find it odd how nobody ever brought this up, seems really strange to me

[Calinou]

@RaTcHeT302 The master branch is a perpetual work-in-progress. You have to expect new features to not always work as expected :slightly_smiling_face:

Zylann proposed a viable workaround that could be integrated into the engine in the future.

[ghost]

@RaTcHeT302 The master branch is a perpetual work-in-progress. You have to expect new features to not always work as expected 🙂

yes i know, but i still felt like this was very important to bring up, this seems like a pretty critical problem to me, and i'm surprised that nobody pointed it out yet, seems very odd to me

so i'd rather point it out as soon as possible, while everything can be fixed in time before a proper release

[ghost]

There are cascades but maybe they could bve dynamic themselves? i.e if the game uses 4 cascades at once, upon scripted decision it could fade to 4 higher cascades (rather than being more than 4 all the time to sort of support them all, if you see what I mean)

Walking       Flying         Area size

---           Cascade 3      64
---           Cascade 2      32
---           Cascade 1      16
Cascade 3     Cascade 0      8
Cascade 2     ---            4
Cascade 1     ---            2
Cascade 0     ---            1

guys it's not about the flying specifically, it's about the player's speed in itself, i just gave a very general example

but immagine if your guy started to sprint, or if you had like, a crysis style turbo speed sprint, your framerate would pretty much be obliterated

or take just cause 3 as an example, your character can use a slingshot, to attach himself to objects very far away once you attach yourself to a building, you are very quickly dragged towards it

now as your character moves across the map, SDFGI would need to update all those lights, and your framerate would just suffer as a whole, it would be unplayable by any normal means

i'm surprised that this was never taken into account at all, point is that, if you have a character in a space ship, on foot, whatever, with a speed that's higher beyond walking speed, your framerate will suffer as a result, and it makes the system really not versatile at all, and it makes its use cases, extremelly limited unless this is fixed

immagine a game like just cause where you can traverse the map at very high speeds, or hell any games with vehicles with them, if you develop any kind of action game, then, you are kinda screwed and you are left out

the system is... okay i guess if you have a large world and if you move slowly in it, but anything else, ehhh, it's not usable sadly

plus i find the idea of having to use a hacky scripting system to solve a core problem to be kinda silly, and if the quality loss is too much, i'd rather just give up on the system itself, if it's not consistent enough across the board

[ghost]

but see the fact that this happens with a scene that's just plain empty confuses me the most, i mean there are no lights in there, it was literally pitch black darkness, so what's going on here? technically my framerate should still be in the thousands right? i mean there were no lights to update, just seems really odd to me

i still believe that there's a huge flaw deep in there, i don't think that an empty scene should suffer such an insanely large frame drop

please stop fixating on the flying thing, and understand that my framerate DROPPED when there was NOTHING IN THE SCENE

[ghost]

okay i'll update the title, maybe that'll clear things up, just in case

[reduz]

This is expected, cascades need to re-voxel when you move, if you make a game that will move fast, you will need to use a larger cell size so revoxeling happens lest often. That said there is a good amount of optimization pending for SDFGI that will happen when everything else is more or less done, so will see this again later.

[reduz]

Oh also, the cmvalley scene you are testing with specifically sucks for SDFGI if you move fast, because it consists of very few extremely complex objects (in the million of polygons), so even if you want to revoxel a small bit of the scene when you move, its going to send millions of polygons to the vertex shader. A Properly made game scene that has the map split into more sections and objects will work way better.

[31]

please stop fixating on the flying thing, and understand that my framerate DROPPED when there was NOTHING IN THE SCENE

Maybe something very specific that's useful to bring up here: an empty scene has as much volume as a complex scene, it just happens to be empty. Since SDFGI (with my limited understanding) maintains a decent amount of volume-based data, I would expect it to have some framerate impact even on an empty scene.

(On the flipside, if there are optimizations that help a lot with empty space specifically, then I imagine they should help with the empty space in complex scenes too--so on first glance I'm not sure empty scene perf needs special attention. (Edit: Although it might be a reasonable benchmark to have, to be fair.))

[reduz]

Also as a note, jump flood after revoxel will run anyway even if your scene is completely empty, this will drop framerate a bit if it happens to often, so make sure to use a larger cell size.

All these things will be present in the documentation by the time its written, so for the time being understand that you are testing a work in progress, undocumented feature.