Hello.
What renders more efficiently: one large model/scene that represents the entire level or bunches of smaller meshes added together? i.e., should I make my whole level in Blender and export the whole thing as a single .fbx or should I make all the individual components (wall meshes, props, etc.) and export them all separately and piece together the level in UE?
Also, is the whole level “drawn” or rendered to the screen or only the meshes and texture directly in view of the camera?
2nd question only in view of camera. First question, I would say bunch of small meshes, this allows you to use multiple instances of a “class” for anything that appears multiple times. That’s what is normal to do. If you want to know technically if it’s sometimes more efficient to use a large mesh instead, I don’t really know. BTW the FBX import window can choose to combine or leave things as objects. There are collapsed menus in the options.
You need to split it up into pieces. There’s a bunch of things that you need to do for optimization that can only work when things are split up.
For example:
-If something is reused many times, it can be stored in memory once, otherwise you have many copies of the exact same thing in memory.
-There’s a system called Level of Detail, where it can switch a mesh from a high detail mesh to a low detail mesh when it gets further away and you can’t tell the difference.
-Things that aren’t visible to the camera can be hidden
Thanks. I am familiar with LOD and mip maps, I’ll have to read the docs to see how to use them in UE.
But… you said things that aren’t visible to the camera CAN be hidden? This doesn’t happen automatically?
Also, if I have, say, a block mesh I am using for a wall part, is it affected differently by lighting and shading if I rotate it? Do I have to make separate meshes for each rotation or when I build the level will UE make the adjustments? I am noticing some weird stuff my point lights are doing. I posted this under the Rendering section of the forum, but even after 18 views, no one has commented on it.
I wish there was a downloadable PDF for the docs. My computer catches viruses easy and I hate that I have to be on line just to read docs.
This is referred to as culling - it happens automatically but determination is based on the bounds of the object.
Hence really big objects are always visible because part of them is usually in the camera view frustum.
Here is a brief summary of optimization
Ok, OptimisticMonkey. That was why I asked the first question. I am new to UE but not to game making, and I have noticed that larger but fewer meshes usually run smoother than many many smaller meshes. In fact, in the last game I was working on before I decided to try UE4, the entire structure of the level was made up of only three meshes: the walls and ceilings, the terrain, and the props.
Thanks for the link, that confirmed my suspicions. And since the only things rendered or drawn are those things exclusively in the camera’s frustum (and I am assuming normals faced AWAY from the camera also do not get drawn), then I might be better off making larger common pieces for my level design. Correct?
I’ll experiment with it. I DO wish someone would give me some help with the questions I posted in the Rendering section of the forum.
Having fewer objects improves performance due to reduced draw calls (you get a draw call to render the mesh), but, you get additional draw calls for each material, and having large complex meshes will slow things down as well. So it’s a balance of the number of objects vs. the complexity.
Backfacing polygons will have an effect on performance, so in general if you have polygons that aren’t going to be visible then it’s good to delete them, unless they will affect lighting.
Thanks guys. I will implement all of this.
To BCETracks: using your info, I was able to reduce an 80kb fbx model down to less than 20kb.
I am going to make a few more meshes that are a bit bigger but still common enough to use several times in one level. That seems to be the general consensus here.
But that reminds me of something else… In previous games I have made, using other software, I had all the game info in external folders. The executable was actually quite small. If in game the player went to a new level, I had a routine that saved everything from that current level to external folders for later reference (in the event the level was revisited) and then deleted all the meshes and materials, etc , out of RAM and retrieved info for the next level again from files.
If I have multiple levels in UE, are they stored in such a way as to free up memory from meshes/materials/etc as the gameplay is directed from one level to another, or is the whole game with all of its levels and objects in memory all at once? That latter case would seem pretty stupid, but I am trying to get an idea about some basic mechanics of UE before I waste a lot of time making lots of levels that will cause a low frame rate.
Again, thanks to all of you. You guys are great.
It unloads things from memory that aren’t being used. So performance isn’t based on everything in the level but what is needed at the time. However, for things like baking lighting the entire level gets loaded into memory (since everything can affect lighting when it’s bouncing light around).
Thanks. That will save me a lot of time and headache.