Home Technical Talk

Which workflow is most efficient in terms of optimization when creating a level?

polycounter lvl 3
Offline / Send Message
orangesky polycounter lvl 3

Hello everyone,

Today I am posting to try to solve a question that I have been carrying with me for a long time, and truth be told, I would like to be able to resolve it in order to create my environments with more confidence and security, or at least shed some light on the matter.

The question is related to finding the workflow that is most beneficial for the performance of a real-time graphics engine such as Unreal, Unity, or Godot when creating a 3D environment for video games.

Well, I know that there are different possibilities for creating a 3D environment for video games. I will mention the ones that are theoretically the most widespread and accepted by the industry. I would like to receive the response from people with much more experience than me and hear their opinion on which workflow is most suitable in each possible situation:

Modular pieces in the engine:

1- Modular construction in the engine (placing modules in the engine editor, for example: interiors created from small wall modules of different types, exteriors with larger wall modules).

Dividing the level into more or less large parts:

2- Building an entire level in a 3D software and dividing the environment into zones (e.g., an entire level of an office building where each floor of the building is a unique model).

Modular pieces using Splines:

3- Using Splines to construct the level's architecture from modular pieces.

Modularity within the graphics engine:

It seems to be the most common technique (based on YouTube videos and some courses). It seems to be a good practice to create the entire environment modularly within the graphics engine using architectural modules.

Workflow in broad strokes (I'm sure I'm skipping steps): Create a basic blockout of the level, model modular pieces in a 3D software, export the pieces to the graphics engine, replace the blockout with the new modular pieces by placing each one and reusing them as many times as necessary to build the desired level.

Examples: Building an interior like an apartment building or a subway station (small wall modules, window modules, door modules, columns...).

Building a street in a city or a town (larger wall modules, roof modules, modules containing a certain number of windows...).

Advantages: Speed of creation, with a small number of pieces, it is possible to create an entire level. It is easy to iterate with the design of the pieces, and modifications can propagate throughout the level with a simple re-importation into the engine.

Disadvantages: It is more difficult to provide variety among different parts of a 3D environment.

Regarding optimization, I have the following questions:

Can this workflow result in a high number of draw calls? Does each repeated piece in the 3D environment count as a draw call if they share the same material among most of the pieces, or is each model repetition managed efficiently?

Building level sections as unique blocks:

This is a technique I've also seen used in many places. It involves constructing the entire 3D environment in a 3D software and dividing it into relatively small sections. Each section would be a unique 3D model that contains the minimum amount of materials necessary.

Workflow (in broad strokes): Build an entire level in a 3D modeling software, defining which areas will be joined together in a single piece (it is also possible to create the level modularly in a 3D engine and define which areas will be combined as a single piece just before runtime).

Examples:

Creating an interior environment, such as an apartment building where each apartment is a unique piece (only with unified level architecture).

Creating a neighborhood in a city, where each street with its buildings (exterior only) is a unique piece.

Advantages: Design variety where unique pieces can ensure that different spaces in the level don't look the same.

Disadvantages: If a level has been created in a 3D modeling software, modifying the level becomes much more complicated.

Regarding optimization, I have the following questions:

Will using large pieces with an appropriate amount of tileable materials result in an acceptable number of draw calls?

How can optimization in general be affected using this method?

Is it more or less efficient than the modular workflow with many repeated pieces?

Building level architecture using splines:

We must consider that using splines to construct roads and street surfaces is extremely useful, and even many fences are created this way. But what if we used this technique to create a significant portion of the modular architecture in a 3D environment?

Workflow (in broad strokes): Create architecture modules in a 3D software, export the modules to the engine, and use splines to place the modules in the necessary locations to build the environment.

Examples:

Using splines to create the interior walls of an office building.

Advantages:

Speed when positioning each module. Relatively easy control to mix different modules within the same spline. Can easily create spaces with organic shapes.

Disadvantages: It may be difficult to create the necessary variety to break the modularity.

Optimization:

Considering that each spline counts as a single object in UE4/5, can they be beneficial or are they expensive to render? Are the draw calls of a spline similar to the modular method?

Thank you very much for your attention and help. Let's see if together we can come up with a general idea of which workflow is more suitable or in which situations one method is more interesting than the other.

Apologies for the lengthy text, but I'm tired of always having the same doubt in my mind.

Replies

  • Benjammin
    Offline / Send Message
    Benjammin greentooth
    Hello. 
    Regardless of the methods you use to assemble things in your level, the vast majority of environment art is built around modular pieces. I feel like you're defining different "methods" that are actually the same thing. For example, splines are used in combination with block modularity for curved/organic things. 

    Just make your environments with modular kits. You can experiment with fancy methods for placement if you like, but its not something to lose sleep over.


  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    Unreal spline meshes are not very efficient.
    Splinemesh components are not (and cannot) be instanced on the GPU so you are looking at a minimum 1 draw call per mesh section plus the overhead of processing the spline mesh. It's cheaper to collapse your actor to geometry than to use a splinemesh based actor.  

    There's no reason to not use them where you need the flexibility they offer but its not a great idea to just use them for everything. 

    I dislike the term draw call because it doesn't actually mean anything useful. 
    However, less material slots == less state switching on the gpu == less slow.  
    UE 4.26 and onward support dynamic batching. This means that if you have many modular instances that share the same material and lod level it will count as 1 draw call 

  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    there does exist a tool for ISM splines you can find on marketplace. it can be very handy for things like rows of trees, fences, and so on. I suppose could be helpful for building city blocks but I'd expect it to be easier to hand place that sort of thing.


    edit: name of tool is Simple Instanced Spline Mesh by Furious Production


  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    You can use a spline to place ISMs or standard static mesh components and you won't get the problem - they'll batch as per normal

    vanilla splinemesh components are unique due to the deformation so it'd take some trickery or a clever plugin to solve the issue
  • Fabi_G
    Offline / Send Message
    Fabi_G high dynamic range
    I think techniques can be combined based on the specific situation. Before a production, I would assume most cases were identified, workflows defined and documented. Probably hard to think of everything and some solutions have to be found mid project. When doing an art focused portfolio project, I would make quality the priority and not stress out about performance too much (make reasonable assets). Potentially spline meshes could be converted to static meshes to reduce draw calls, maybe a tool that converts back and forth. I think there is always a balance between ease of working/ iteration speed and performance optimisation, another thing to figure out before production.
  • orangesky
    Offline / Send Message
    orangesky polycounter lvl 3
    Thank you very much, everyone, for responding within such a short period of time. I will do my best to answer and I hope I don't seem bothersome with this topic, but I want to clarify my ideas as best as possible. Also, I apologize, my English is not very good and I may have errors in expressing myself.

    @Benjammin

    When I say different methods, I'm referring to the differences between distribute instances of modular models throughout a level directly in the game engine or preparing rooms as single-mesh models in a 3D modeling software and placing them in the engine. Based on your response, can I infer that it doesn't matter whether I do it one way or the other, as I will still achieve more or less the same results regardless of whether I intelligently combine the pieces into unique models or not?
    In the end, does it all boil down to the number of materials in use and the total polygon count per frame?

    @poopipe
    Yes, I can see that splines are not very effective when it comes to optimizing an environment. It's better to limit the use of splines to logical cases and avoid forcing them unless a project specifically requires it.The issue of draw calls is what's been bothering me. Does this mean that if I use dynamic/static batching to combine modular models that share the same material and level of detail, just like if I manually combine the models in Blender and import them into Unreal, I will achieve similar results? (Of course, I'll have to be careful not to combine models that have an astronomically high polygon count when summed together.)And if I don't use dynamic/static batching and simply distribute the 3D modules throughout the environment, grouping the ones that share materials, will I still achieve good performance results as long as I properly configure occlusion culling?

    @Alex_J

    Thank you very much for the tool you suggested, but I don't intend to use splines beyond creating winding streets or fences.

    @Fabi_G

    I may be getting ahead of myself with problems I don't even have yet, hahaha, but I like knowing what people have learned throughout their careers and having a mental framework of the pros and cons of each workflow. I know that in this industry, workflows evolve almost weekly, and there are thousands of ways to accomplish the same thing.
  • Benjammin
    Offline / Send Message
    Benjammin greentooth
    orangesky said:


    When I say different methods, I'm referring to the differences between distribute instances of modular models throughout a level directly in the game engine or preparing rooms as single-mesh models in a 3D modeling software and placing them in the engine. Based on your response, can I infer that it doesn't matter whether I do it one way or the other, as I will still achieve more or less the same results regardless of whether I intelligently combine the pieces into unique models or not?

    In the end, does it all boil down to the number of materials in use and the total polygon count per frame

    It absolutely matters- that would be a nightmare to edit and iterate on. However, some pipelines don't use an editor like Unreal - levels are assembled in Maya or w/e, but using the same modular assets you would otherwise. You might merge things together at the end of the process for optimal performance, but you don't want to build that way from scratch.
Sign In or Register to comment.