Jump to content

[NOTABUG] Object visible range does not affect shadows


photo

Recommended Posts

If object has inf visible distance and there is global object visibility set on for example 200 (settings/visible distances), object still cast shadow in case shadow global visibility is over 200 (settings/shadows). I think global object visibility should have priority over global shadow visibility (objects which are not visible based on object global visibility distance should not cast shadows).
 

Edited by demostenes
Link to comment

Well, forests with big shadow visiblity look by far better and performance cost is surprisingly small (shadow distance 4000). I was trying to use SSS for this long distance shadows, but it seems, that it does not affect landscape terrain bellow (1st screen SSS only, 2nd with regular shadows). But of course there is no reason to see other objects, so I ve set object visibility to 200. And rest was just coincidence, I ve noticed, that objects with inf visibility (which was wrong setting anyway), cast shadows. I am not sure if this is final setting anyway, but this behaviour seemed wierd to me. Anyway it is nothing critical, correct visible distance for all objects solves it anyway.
 

 

Edited by demostenes
Link to comment

I ve also noticed other behaviour, not sure if it is intended. I have for example 10k nodes, with maximum surface visibility 200m. Even from 6000 meters  (also facing these nodes backwards does not help), performance impact is HUGE (eats 1/2+ of FPS, with global shadows limited to 200 it eats 1/3 of FPS). But if I use global object visibility 200, it costs nothing (same FPS like these nodes are turned off). So I need to keep both global shadows and object visibility low, otherwise large group of nodes will eat almost all performace, I need to be at least 10km away (there is big increase of performance), to have similiar performance like with these nodes turned off. 

It can be easily reproduced in ou project data\esqworld\demo_test.world, I ve put large group of nodes into dummy node there (rev 1810+). For screens I ve turned vegetation off, so terrain FPS are more or less constant:
image.thumb.png.b2626289c351c2b4d84abb3292b34fa4.png

 

 

 

Edited by demostenes
Link to comment
  • 1 month later...

Hi Jirka,

Sorry for the delay. Our dev team didn't have a much time to take a closer look into this.

This issue is in our list of priority tickets that we need to check prior 2.13 release, so there is a good chance that we will know the root cause of this behavior.

  • Like 2

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
  • 2 weeks later...

We found the root cause of this behavior and fixed (although, this will be released in 2.14 only).

We also slightly optimized spatial tree for such use-cases, so the big amount nodes in the same coordinate will not affect the performance so much (this also includes the shadows calculations in separate thread).

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
14 hours ago, silent said:

We found the root cause of this behavior and fixed (although, this will be released in 2.14 only).

We also slightly optimized spatial tree for such use-cases, so the big amount nodes in the same coordinate will not affect the performance so much (this also includes the shadows calculations in separate thread).

Thanks for good news. Does it mean, that there will be no need for devices like world switcher as vvvaseckiy suggested in other thread? In open world game we cant afford any performance loss caused by distant (out of max visibility) objects. On the other side we want to have visibility at least several Kms, to fully utilize unigine capabilities (it looks so much better). I am absolutelly sure, that number of nodes in our world will only grow. Now we have base of all big cities, but there will be countless points of interests in the world, but of course with at least one order of magnitude less nodes. Thanks.

 

 

 

Edited by demostenes
Link to comment
  • 8 months later...

After a big discussion with a the dev team I can only declare defeat :) Described behavior from the first post is the expected right now. We will update tooltips and documentation so it will become more obvious how important these parameters are.

So, if you have Shadow distance bigger than Object visibility distance you will see the shadows (but not the object itself). It's very important to check if you have correctly set distances in the settings.

Thanks!

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Ok, but at the end shadows are not the main issue, shadows are just part of it. I see main problem, that having somewhere lots of nodes (city node) causes huge performance drop, even if city is not visible (max lod 200m). I have to be several (7-10+?) kms away to get FPS back again. I dont know what is happening inside, so this is just guess, but it seems like these objects are part of spatial tree and LOD visibility checks are occupying CPU. And I need to be really far away, until these objects are finally unloaded. So it is obvious, that I can kill any world by just having enough objects there. 

So what to do? Switcher on the whole city causes huge lags when going on/off, so only way would be to put switcher on each building to distribute load. But sooner or later I would kill performance by having thousands of switchers in the world, so this leads to dividing map into some sectors and making hierarchy of switchers. Manual work, but in theory it should work.

Other solution could by some slow async load for these large nodes (specified load distance and unload distance) and it is question, if it is really possible to put thousands of nodes into spatial tree without lag. I think this was called world layer node and it was discarded with reasoning, that spatial tree alone can handle that better. But it seems it doesnt in extreme cases.

Maybe add some finer control over spatial tree and load/unload distances (setting size of world cells)? For supersonic jet you need totally different load/unload distances, than for FPS/3rd person game. But there can be issue with objects, you really want to see at big distance (sea, etc...). So you need to have several "layers", each with different rules, some "always load" rules, etc...

In past we were using world layer nodes and it worked, but this is now not possible. Generally it is issue each open world project will sooner or later have. So what is proper solution to this?  Thanks.

Edited by demostenes
Link to comment

First of all you need to tune the shadows distance to be smaller than objects visible distance set in the Settings :)

And the initial issue described there has been already fixed in the current master (with a huge math lib refactoring). Now in that case there will no performance drop since the spatial tree was simply bugged and didn't cut non-rendering nodes from a spatial tree completely.

Thanks!

  • Like 1

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
4 hours ago, silent said:

First of all you need to tune the shadows distance to be smaller than objects visible distance set in the Settings :)

And the initial issue described there has been already fixed in the current master (with a huge math lib refactoring). Now in that case there will no performance drop since the spatial tree was simply bugged and didn't cut non-rendering nodes from a spatial tree completely.

Thanks!

Ok, thanks. I thought that issue with spatial tree cant be solved. When it will be available?

Link to comment
On 7/2/2021 at 5:02 AM, silent said:

First of all you need to tune the shadows distance to be smaller than objects visible distance set in the Settings :)

And the initial issue described there has been already fixed in the current master (with a huge math lib refactoring). Now in that case there will no performance drop since the spatial tree was simply bugged and didn't cut non-rendering nodes from a spatial tree completely.

Thanks!

good to know

Link to comment
  • silent changed the title to [NOTABUG] Object visible range does not affect shadows
×
×
  • Create New...