LOD Design Patterns C#

I want to create a custom LOD system and I was wondering about the best way to go about it. Im very weary about having about a thousand gameobjects checking for the camera position in their update loops all at the same time to determine which LOD to use.

So I was thinking about using the Observer Pattern to have the camera keep track of a list of registered gameObjects and update them with its current position. But then again Im concerned about performance when the list of registered gameObjects gets huge. (There could be over 4000 objects that need to be LODed. Its a big open world.)

Anyone have any insights on this?

FWIW. I’ve found it worthwhile to just write your own personal little ad-hoc spatial culling system, considering the nature and paradigm of your game. (Rather than trying to create some final, last-word general purpose system.)

for example, your game takes place in a 1km cube say. Just divide it in to chunks (perhaps more than one series) the relevant size of your LOD concept and have a few routines that handle that for you. you’ll only have to look at the list of the ten or so the camera is pointing at.

very typically depending on the nature of your game there are other drastic simplifications.

{one example of zillions - very often the camera only points in pretty specific ways, in that case you can easily precompute lists of which chunks you have to look at, given various camera positions - indeed issues like “does the camera even move” massively affect your approach, good approaches will suggest themselves based on your paradigm)

to summarise, IME simply going ahead and building a little ad-hoc spatial culler - specifically for your situation - inevitably works pretty well, better than a very general solution. (perhaps because of the very specific nature of 3d games, and how the “paradigm” tends to vary so wildly.) it’s not hard to program (just shove things in a few lists) so it’s valuable material. Hope this philosophical thought helps in some way.


so it’s a city great, so the whole universe is say 2km on a side?

i’d just make a 2d array. cut the city in to say 20x20 grid

(Aside - simply tune this value later. Don’t worry about it at all. once it’s operating just try different values, and see what works best.)

each array is just a list (or array) “whatIsInThisOne”

“whatIsInThisOne” is simply a list of what’s in that box. or perhaps “physically small items” (it could be that “physically big items” are shown regardless) or it could be you have all of what I describe but sat 3x for three different thing sizes.

so, it’s that easy happily !

(to be sure to be sure, you know that U3D has a lot of totally awesome culling stuff built-in anyway … you never know what it will do for you, quite apart from all this.)

Well there is always a octree approach, in which objects will register their position when they move and update which cell they are in, then when it comes to rendering (a camera script is probably the best bet, on the pre render function of something) you could attempt to use the cameras values to minimize which cells will be rendered, and thus cut down the amount of objects you then have to do distance calculations on.

…OR you could use the much easier sounding approach. the MonoBehaviour functions OnBecameVisible, and OnBecameInvisible. These functions are called as and when an objects renderer detects that it is visible by the active camera. you can use these methods to set a flag that is then used to calculate or not calculate the LOD distance code in the update.

not tested any of this myself, but it sounds like that solution would do the trick. Hope it helps.