TaaTT4 wrote:Set objects render distance is something which has been in my todo list since almost the beginning, but I've always postponed it waiting to have all kind of objects in scene.
I guess now the time has come.
For what is worth, PixelCount LOD strategy (ScreenRatioPixelCountLodStrategy::lodUpdateImpl) shows how to calculate the area of the screen a sphere will occupy at a given distance. It needs 3 things:
- The projection matrix (dependency on FOV settings)
- The object's radius (mWorldRadius, which accounts for final scale)
- Distance to camera (taken from cameraPos - mWorldAabb->mCenter in our code)
You could use that math to calculate a distance value at which you will know mathematically that the object will be < 1 pixel; and use that as a minimum visibility distance for each object (and boost it for irrelevant objects that can disappear sooner; TBH we should be the ones providing this facility for you instead of telling you to implement it
Please note that it's resolution dependent. At 1920x1080 the area threshold is being smaller than a quarter of a pixel, that is area = 1 / (1920 * 4) which is 0.0001302083 but at 4K resolution it's 1/(3840 * 4). You'll probably want to use doubles for your math. Or maybe you won't care about resolution.
What I'm aiming to do is to mark every part of a complex object as "required" vs "optional".
For example, in a granstand the roof and the concrete structure will be marked as "required", while the seats, the fences, the poles, the stairs and so on will be marked as "optional".
The "optional" meshes will have a lower render distance than "required" meshes.
If the math pans out, you won't need the "required" category (since everything that is <1 pixel is 100% reasonable it should be left out). What you want is a booster variable (so they get dropped way before the become <1 pixel, but it's something manageable) to use for seats, stairs, etc. or an override (i.e. specify the value directly: drop the object after it's 150 meters away)
BTW, I guess all those tiny objects you've seen are transparent items (fences especially) which haven't been batched together to avoid this AABB transparency issue
Short bed sheet problem, eh? (do we cover our feet or our head? can't cover both at the same time).
For fences that are always exterior (i.e. you're always inside the fence) you can batch together the fence parts and then put it in a lower RenderQueue since it's guaranteed they should be rendered before trees. It will only look incorrect if you look the scene from the other side of the fence (i.e. from the outside):
In this case you can batch together the skin-coloured fence and put it in a lower RQ ID so it gets rendered first (which works always as long as you're inside the fence). You could batch the whole fence in one draw, or in several few (for better culling, it really depends on how many vertices make up that fence. If the whole fence is <1000 vertices just batch the whole thing).
Btw Nsight API Call Summary. I need those numbers.
I've sent you a PM with a link where to download it.
1. I guess I should've told you by now I can't run NSIGHT (no NV card, died like a year ago, still haven't bought a replacement...)
2. I don't want my
numbers. I want your numbers
. Perhaps your machine says CPU bottlenecked while mine says GPU bottlenecked (or viceversa). I need to know your numbers. Generating the call summary myself is pointless.