-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cascade Shadows Are Not Working Properly #2169
Comments
Hi, thank you for reporting.
Armory takes the information of the camera and not the viewport, so changing the far value of the camera should do the trick. If not please report back.
Cascades are limited to 4 on the UI and cascade size is limited to 4096 when exporting from what I see, so definitely giving this a look 👍
These are other issues that it's great that they are reported, but may not be too relevant to the main issue you opened. Maybe you could open different issues for each so the tracking of each of them doesn't get lost or tangled among themselves? |
I tried all the AA modes and AO is not working and only FXAA/MSAA are able to run without causing black screens. All the other AA modes cause black screen when the values is set to maximum. Without the post processing section I'm getting 3,333 fps but as soon as I enable the buggy post processing shaders the frame-rate drops to 714 fps. And the shadows were enabled in both cases just not showing in the game because of bugs. And then if I switch to full screen mode the fps gets cut in half again. Which is not suppose to happen. And the camera is clipping the background color in the second image, which is not suppose to happen either. Here is the scene file used. |
Hi, I can only guess because the textures are missing in the file, but it could be that the "metallic" value of the PBR shader darkens the materials and is responsible for the difference between Eevee and Armory. I used another texture but to me it looks pretty similar to the viewport, even with the metallic setting != 0. Regarding this and the other problems: please open separate issues here on Github (if they don't exist yet), otherwise it's too easy to loose track of it and they will be forgotten pretty fast. This issue is about cascade shadows and should not be about something else. Regarding the framerate: framerates are not linear at all, you can't compare them directly due to their nature as a fraction of a second. You should always compare the actual millisecond value. There are many articles out there that explain this in detail. Also, a framerate of 700 is still absolutely fine and I wouldn't worry about it. Without the compositor, the GPU will have almost no work for your scene so it will run pretty fast, and with the compositor there are some more tasks that it has to do. The reason why it will be slower when you run the game in full screen probably is that there are more pixels that have to be rendered, so the GPU has more work to do (even though GPUs are good at parallel processing). |
I also wanted to add,
As I said earlier, Armory doesn't take the values of the viewport when there are cameras present. If you select a camera object in Blender, and press On the other hand, EEVEE (the engine you see in the viewport) is not a game engine, but a render engine for quick visualization of assets that prioritizes quality over performance. |
There were no cameras present at first and even then the viewing range was not matching the viewport. It was not able to show the entire terrain in viewport mode. Here is the file again with the texture packed in. If you start it in Viewport mode everything gets clipped and the entire screen is grey with nothing to see. And in Camera mode when looking up and down something gets clipped in the distance. Like the background gets clipped or something. |
If Eevee and Armory are so different, there needs to be an option to bypass Eevee and to use the Armory3D renderer in the main viewport. Why use Eevee as a reference in the viewport when that's not how it shows in the game ? Can I use the Armory renderer in the main viewport ? I didn't find any option to switch it from Eevee to Armory. |
Armory was created before Eevee, so it's not really being used as a reference when exporting, but instead it's more of a cycles reference I suppose.
It was possible a long time ago to preview Armory inside of blender when Armory shipped with a custom compiled blender version with the SDK pre-installed, but it required a lot of effort to maintain it whenever blender was updated, so with time it was dropped. It's possible to integrate armory's renderer in blender natively, but it'll require quite the effort to do it #1098. |
I still don't understand why is the fps dropping so much when I enable the post processing section. Anti aliasing + lights + shadows are not supposed to destroy the fps so much. It goes from 3,333 fps to 714 fps or way less if it's in full screen mode. There must be a bug somewhere. Is there a way to fix it and keep a high fps in full screen mode ? |
Again, as explained above: there is not so much difference between 3333 fps and 714 fps, you can't compare them directly because fps don't scale linearly. Here it is explained a bit more detailed, I didn't find the detailed article that I wanted to link but this explains it very well too. Think about a game with 5 fps and with 10 fps. 5fps means that a frame takes 0.2s (1s / 5 frames = 0.2). For 10 fps we calculate 1/10 = 0.1s per frame, so you have a difference of 0.1s (0.2 - 0.1) = 100ms between both framerates. Now, take a look at 100fps and 105 fps. 1/100 = 0.01 and 1/105 = 0.00952..., which gets you a difference of about 0.00048s = 0.48ms between the framerates. So the same difference for higher framerates is less of a problem. Even in with 3333fps and 714fps, there isn't much of a difference and this is probably just caused by the fact that the GPU has to do at least something substantial. 1/3333 = 0.0003s = 0.3ms and 1/714 = 0.0014s = 1.4 ms, so the difference is 1.1ms which is totally fine. You could make things 6 times slower and you would still be able to play smoothly with 144fps. There is nothing to worry about if you don't experience lags and a profiler doesn't say that it's the compositor which slows things down. But again, please use the forums/the Discord channel for discussions and general questions and split different bugs into different issues here on GitHub. Does the original issue with cascading shadows still exist? Otherwise we can close this (cc @N8n5h, I don't know much about shadow mapping). |
I think the original issue could be mitigated by increasing the far distance, but it's true that cascades may produce sub-optimal results with bad quality in some cases depending on the camera view, the light direction and the scale of the shadows. As evidenced here armory/Shaders/std/shadows.glsl Line 291 in a4e9ad9
|
In Core Engine, which is using a modified version of the Unreal Engine, the cascade shadows are not limited to 4. Just saying. There must be some bugs somewhere. Plus a 4096x4096 greyscale image saved in png format shows a file size of 66.6 KB (68,205 bytes). If the texture is that small there is no reason to have it limited to 4 or the size limited to 4K. And how is that shadows.glsl suppose to work if the viewport is using Eevee ? Is it making a greyscale image which is mixed in as a compositing layer ? |
With these new settings, the shadows shows but there is a shadow plane cutting in and out or some clipping plane that gets mixed in as I rotate the camera. The textures are also distorted by the camera view in a weird way. Also, It looks like the Armory Props Shadow is asking for an IES Texture and a Clouds Texture. Do I have to create those manually ? |
Here is one example that works (somewhat) but that resolution on the shadow is not 4,096. It's not even 1,024. In the panel is set to 4,096 (map size) but it's not even close to that resolution. |
Here is an example that shows how the shadow projection is not intersecting the floor in the same spot. The camera has weird distortion so as the camera moves, the shadow also moves and it gets projected in different spots on the floor. Can you guys copy the viewport code into the camera code and add perspective distortion options separately ? Because the viewport is doing perspective properly without any distortion while the camera is doing perspective with some extreme distortion. |
The cascaded shadows are limited to 4, which is wrong, but even then, they are supposed to cover a set distance of 200 meters with perfect shadows and it's not doing it. Then I tried 1000 meters and still bad results. Then I maxed out the shadow size and still bad results. Then the viewport is not reading the 3D viewport settings and the view distance is stuck at 100 or 200 units. I set the view distance to 6000 units and it's not doing it. It works for the camera but not when starting the game in viewport mode. Then the rotate object node fails to apply rotation to the object that is linked to (the parent) unless the name is specified directly in the field. If the name is left blank, it fails to rotate the parent, despite the fact that it's already linked to it. Anti-aliasing and texture filtering are not working properly. Framerate drops too much if scene has over 100K triangles. And so on.
The text was updated successfully, but these errors were encountered: