The FBX objects didn’t inherently come with a collider (as far as I know), so I added mesh colliders to all the children, which seems to do the job right now. However, I heard that mesh colliders are resource intensive.
Is it all right to use Mesh Colliders for simple FBX objects that aren’t too complicated? For example, the house picture attached are made of objects that are pretty much lines put together with no curvature, so there doesn’t seem to be any crazy calculations that a computer must do to render the collider. But I don’t know how Mesh Colliders render things so I thought I would ask.
Also, are there common methods or rule of thumbs for creating an environment like this?
Do I need blender or some other program to combine all the children into one single gameobject or can I get away with just attaching tons of children to make one object in Unity for a game project (like the hierarchy picture attached)?
Are there ways to “gridize” terrain? My terrain FBX objects are all 1 unity units in X and Z axis (Y axis varies), and I was wondering if we can use the grid system just like in the 2D unity tutorial’s platformer to make the 3D terrain.
What things do I need to keep in mind when building an environment to make my game resource efficient?
How can we input so many grass and trees that refract light in a different way but the game seems to run so smoothly? Even crazier, how do these high end game studios make so much grass and trees that move around with the environment (wind, rain) but there seems to be negligible performance drop? Am I severely underestimating what current computers can do?
Mesh colliders don’t render anything. They detect collisions. My rule is; unless you need absolute precision in collisions, try to avoid them. With walls and stuff with no curves, you can size a box collider to work just fine. Also, if the player or any NPCs are never going to get near the roof, don’t bother with colliders on it. Colliders are (nearly) constantly checking if anything collided with it. If nothing will ever collide with it, it’s just wasted processing.
Kinda depends on the number of meshes. The fewer meshes you have, the better the performance will be. Believe it or not, the world in Minecraft does not consist of millions of cubes. The game would not run if it did. Instead, the ‘cubes’ (only the visible sides) are procedurally welded together to form bigger chunks to reduce the overall mesh count. That being said, there are loads of games that have modular pieces just placed next to each other. You may only start noticing a performance issue when the mesh count starts reaching thousands of meshes.
I’m sure you will find something like it on the asset store, but there’s nothing I’m aware of built into Unity
See my earlier comment. Texture packing also helps a lot. But these are usually only things to worry about when the game gets really large.
I cannot answer these with absolute certainty but a lot of the processing goes to the GPU. These are designed with one purpose; render graphics. There are also a lot of very clever tricks that is used to trick you into thinking things are far better looking than they really are. Things like ‘moving with the wind’ are usually done with shaders, and shaders run on the GPU. This is usually done via ‘vertex displacement’ which does nothing to the mesh, but the shader draws the meshes vertices as if they moved somewhere else.
There’s also ECS which is designed to deal with thousands upon thousands of entities. But this is a complete mindset change. V-Rising was built using Unity’s ECS system (with a whole lot of custom changes). Jelly Car Worlds is an indie game built in Unity with a full soft-body physics engine built in ECS.
High-end game studios also - usually - have their own engines that are specifically tailored to the games they are making. Unlike Unity and Unreal Engine that tries to cover all bases. For one of the “Lord of the Rings” games, EA used their “Tiger Woods” golf engine because it already did the things they wanted the engine to do, i.e. large area with a goal (Sloping Green, or Impenetrable Fortress, pick one) at the end. But that didn’t answer the question. Just some interesting trivia.
I hope this helps a bit. I’m sure other, more informed, people will also add to this (or correct my mistakes)
Edit
I said ‘usually’ quite a lot in here. Shows how many exceptions to rules there are…
Ah, I see. I thought was some sort of invisible wall of some sort, but it’s quite literally a detector for collisions and triggers, isn’t it. I see what you’re saying.
Ah, that’s good to know NOW. Thank you. I’ll work with box and other simpler colliders moving forward, especially since my practice doesn’t need anything that specific.
I just got to the lecture where they introduce some snap-on tool called progrids. However, the current version of Unity seemed to have removed it (it’s still downloadable via Package Manager → git URL). I suppose people don’t use it much to warrant support.
Oh, I did see that video game in my youtube feeds. It definitely looked interesting, what with how the physics seemed to work. ECS/DOTS definitely seems to be above my paygrade at the moment, especially when I’m wracking my brain with beginner’s code. Once I break through intermediate exercises I hope I can come back to it.
