With the power of Serialization, this is possible. You want to limit the load on the client’s device first and foremost.
The Idea Of Serialization ← starmaq’s forum post
When the game starts, it’s a hit or miss on what
server you’re given. You could get a higher performance
server, or a very low performing server.
Server capacity is extremely finite, and anything
running on the client’s computer is to be treated
the same, because there’s no telling what kind of
device or performance the clients will have.
The entire game has to run with as little data as
possible. If you can limit your data enough to have a functioning game, there’s more headroom for optimization and customization; this is where Serialization comes into play the most.
There’s multiple ways to calculate how the game disables shadows. You’re looking for the method that applies to your game the best.
One example is using a screen-space-chunk relationship. You have your Camera, and by using something like WorldToViewportPoint, you can lessen the load on the loop by searching for chunks inside the Viewport, instead of individual objects. This would be extremely better than looping the entire game’s instances. You can combine this method with a distance calculation that also uses chunks; when a player is far enough from a chunk, disable shadows for that chunk’s instances. Depending how far you’re willing to go in terms of serialization, the biggest point is to pre-package the game to be unpacked later. Converting and saving your game assets in their most simplest forms, will help lessen the strain of your game loading things. If you have these big elaborate chunks with hundreds of thousands of objects, there’s a couple ways to handle that much data. You can change the size of your chunks, make chunks within chunks, make custom chunks that aren’t square, (loading zones). The possibilities are endless my friend…