[Feature Request] near LOD cutoff
It would be very useful to have a near LOD cutoff. This means the object is not drawn if nearer than the near cutoff.
This can be very useful in large worlds where a whole town is represented by a sillouette, and as you get neare the buildings LOD in to simple boxes and the sillouette goes away. Thus you have a meta-object representing a whole cluster of sub-objects. These meta-objects could also be called far tell-tales. The players use thm to plan things like "let shead for that town 5 km away".
asked Jan 12 '15 at 07:53 PM in Rendering
SND R Keene
Hey SND R Keene -
Thank you for the clarification. I have entered a feature request to our engineers for their consideration.
answered Jan 14 '15 at 03:00 PM
Lovecraft_K ♦♦ STAFF
That is not quite the point. In a large world there could be 1,000,000 objects from house to salt shaker.
You want to only instance into the engine what the player needs to see. There is a 0.26 millisecond overhead per Actor in a scene in Unreal on my machine. (The tick processing, even if the tick does nothing, measured empirically).
So a town needs to be a single Actor if 3 km away, but then fracture into houses as indivivual Actors as they get closer, and delete the town object from the world. We use the term "Instance LOD" for this design pattern.
We also do this for a house. As the player walks toward the house at about 20 meters all the objects in the house begin instancing into the engine, but in a throttled manner so the frame rate does not lag. Typical is 1 instance per frame ordered in distance from the player. We also uninstance in a throttled manner as the player moves.
So in a 1,000,000 object world, we only have 4000 or 5000 instanced Actors in the scene.
Unreal already does this partly with terrain chunks and scene division, but for a crowded world like a town it is too coarse grained.
A companion design pattern is Physics LOD. In this we only process capsule movement every N ticks depending on distance from the player, with a physics time interval of dt * N, and LERP position between physics checks. So an Actor's physics is disable most of the ticks. We had to eliminate the native capsule, and use a capsule sweep test with N times the single tick move distance. If near a building we cut N down to 1 or 2 so the capsule test could navigate walls and furniture. We'll see how that shakes out in Unreal.
For proximity avoidance between Actors, and for Instance LOD 'what is nearest the player', we have a 4 meter grid of lists as to what Actors are in that area of the world. This lets us check at most a few nearby Actors very very quickly.
The two combined algorithms give us good frame rates and low stutter on a 16km square world with 1,000,000 or more 'WorldObjects'. Our database of 1,000,000 world objects (not engine GameObjects or Actors) take 50 MB of memory in C#.
(But, that was in Unity, and we are porting to Unreal which is a away better engine.)
Note: We also have a class called ChunkedDictionary in C# where the dictionary is N sub-dictionaries so you can progressively iterate over the dictionaries in a chunk-per-tick fashion. Usually there are 100 sub-chunks so you can process 1% of the objects per tick. We'll be implementing that in C++ in a few days.
Follow this question
Once you sign in you will be able to subscribe for any updates here