I noticed there are some unity projects that has all of the game objects instantiated via run time. For example a multiplayer game where there is a Town square, Farming Forest and Hunting ground. These 3 places are in prefab and instantiated on runtime. I’m might be naive and noob to assume that occlusion culling and some other unity’s baking functionality wouldn’t work run time. What I really want to ask is what is the reasoning behind this?
Without seeing said projects, and said implmentations, the reasons could be many. That said, pre-baking with unity occlusion system, and etc etc… is not the only way to stay on top of performance, and, most times, demos are not ‘complete’ publishable ‘state’ projects, in fact, they are bare bone, for a reason.
1 Like
Developers do this to gain greater controlled over gpu and cpu usage.
having a skinned mesh renderer and not using the bones like a rag doll or in the form of inverse kinematics, is an incorrect approach to the system. For a skinner mesh renderer with bones takes a longer time to solve prerender than a mesh renderer. Both components do not need to exist. So a mesh can be rendered as in effect, a geometry flag. Sometimes this is all that it wanted of the piece. So rendering via script can be useful.
another reason is that certain grids and procedural wrapping zones generate the environment around the player in respect of perhaps another type of data sheet or RNG.
1 Like
Thanks guys for the detailed answers !