Hi everyone.
Right now I’m working on a free roaming game based on exploration in a rather small world (think something like Proteus).
The dimensions of the world are 768x512 game units, the main character being like 1,5 game units or so. The art style is low poly, like first 3d games on PC. Something like this illustration, obviously with all the limitations of a real-time render
Now, I never made such open worlds, and I’m asking myself what are the best practices in rendering it without stressing too much the performances. Right now I’ve got this pretty big mesh (all the terrain, with hills, canyons and stuff) and my character moving through it (it flies, but at a rather low level). A first test shows good results, but now I have to populate the world with a lot of objects like trees, rocks and creatures. This kinda worries me about how the performances of the final world.
So I’m asking you: is this the best way to proceed? Should I divide the world in several submeshes? How it can be optimized? What can I do in advance to avoid problems later? Keep in mind I won’t use billboards and stuff like that, every mesh will be full 3d, non smoothed and with maybe just a GI/Ambient occlusion texture applied.
When you say the world is 768512 do you mean the whole world or only the current active/visible part ?
If it’s supposed to update as the player move out of this 768512 zone then you could use chunks because you don’t want to update the whole zone each time. If its a voxel world your video card won’t appreciate so much draw calls so chunks are mandatory. If the player may alter the world (like in Minecraft) its even worse (think about saving/loading…) Is you world procedural ? If so then you will have to be very nice with your computer But the good news is that if you never use random generation you will save a loooooot of your precious computer time (look at noises algorithms) because you only need to save changes.
For things like items, mobs, etc you could define an activity zone beyond where they are not checked. The way you store and check data (for instance strings are evil) is of prime importance. Have a look to Octrees.
One thing is sure : you must use very specific tricks.
Its depends on what your game is made of, whatever the engine you use.
You should be more specific because there is too much possibilities and tricks. A screenshot ?
the world dimensions are for the whole world, not the active/visible part.
I’ll have no procedural generation, and yes, I was thinking to set up areas where creature spawn/behavior are activated/calculated only if the player can see them.
Here is a screenshot of the early prototype:
Above you can see the whole play area (the mountains act as a barrier, preventing the player to go off bounds). Below a tentative in-game camera, which I need to tweak. The general visible area shouldn’t change too much, though.
Always have the DATA/RENDERING distinction in mind (Unity may be a trap here…)
DATA
I think it may be easier to say the behavior condition is simply a defined range instead of player visibility (this way you could have some backstabbing ducks and other evil rabbits.)
Other things to think about : Pathfinding and mobs FOV. I know 2D solutions but i’m not a 3D specialist
(About mobs FOV : a simple raycasting between the mob and the player may be enough but could be a bad choice if you want mobs to interact each other, for instance wolves hunt rabbits, rabbits eat plants, etc…then octrees would probably a better choice… )
and what about Field of Hearing (every directions, less affected by obstacles)…
RENDERING
On the visual part that’s another story, if you want to avoid to render things not supposed to be seen then you must use an occlusion method (Unity Pro) or make it yourself (using octrees in order to check what is visible and what is not.) Maybe you won’t need such method, it depends on the quantity of objects in your scene. I think you may ignore that now.
Thank you, I was thinking to use an occlusion system (I should get pro at some point for this project).
So, you’re suggesting that, as for the terrain, I could go on with a single mesh, and then optimize objects and behaviors?
I guess a lot of my questions will eventually be answered going deeper in development, though
There is a limit on the number of polygons a mesh may have.
If you plan to expend the terrain maybe you will have to split it into several chunks.
Is the lake a different mesh ? (seems to be)
Also think about the effects each parts of the terrain may have on the player. If he may go under water, for instance.
That would be probably easier to split the terrain into several parts
Yes, the lake is a different mesh.
Fortunately the player cannot do much (just turning left/right, we decide the height), so interacting with the environment won’t be a huge problem.
The mesh works well right now, I guess I can chunk it later, if necessary. Thank you!
poly’s isnt such a problem but the texture memory space and shaders are of huge importance, I have no experience with mobile but that’s a important rule to follow with them and a factor on pc but to a lesser degree.
few tips:
Pooling versus instantiating ie: spawning
Turn off renderers on gameObject prefabs such as houses/buildings/fences (player vicinity detection)
Instantiating spawn slowly
LOD if possible such as buildings ( detail level texture atlas)
camera Fulcrum occlusion
entities that are unseen can have their renderers only turned off or gameObject.active = true/false
realtime shadows will knock off 10-15fps / fake it, or use the localized floodlight lighting and static baking.
