Home Unreal Engine

How are you organizing level design for ease of iteration?

grand marshal polycounter
Offline / Send Message
Alex_J grand marshal polycounter
Say that you are building some 3rd person game environments, something like this:

Which would be composed from a modular kit like this:

Say you pain stainkingly snap together these many walls, roofs, doors, etc to create a few buildings. Then later you want to pick up all those buildings, move them 10 meters left, or swap one out for another style... it is possible, you can group static meshes together, but it's really messy in the unreal outliner, and if you want to make edits to the buildings themselves, it really seems a lot easier to do that sort of thing in a 3d program.

So to me it seems that level blockout and replacing the blockout with actual art assets is a lot easier to do in 3d program just because you get much better organizational tools + better selection and editing tools. But the trade-off is that you don't get as immediate feedback about how it actually looks in game. It can be pretty fast, not a big deal to just export, wait half a second, import to game engine... but it's not ideal compared to working right in the game engine.

I also don't find any examples of enviro artist doing their work in 3d program like I am saying, so I am curious to hear anybodies thoughts / experiences? Are there good reasons to just put up with the game engines quirks and do blockout and level design in there? Any tricks to help prevent feeling "locked in" to your level design simply because iterating on it is a PITA?




Replies

  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    Ive built a couple of things over the years to dump content out from max and maya to unreal and I've come to the conclusion that it's very useful in very specific circumstances but it's generally best to work in editor for larger scale compositions.
    eg. When I'm blocking out  I'll build a whole house or floor of a building in max and just dump the fbx to unreal to run around it - editing brushes is far too slow and clunky for me.  I woudn't want to do a whole level like that though as it means going back to the DCC and changing the model to leave a bigger gap between two houses

    One tool it's definitely worth building is one that will dump instanced/referenced object transforms in max/maya to csv and load them into an actor as ISM/HISMs that reference existing static meshes in your unreal project. 
    I've found that really useful for more intricate compositions of modular pieces eg.buildings 
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    Reasons working in the editor is preferred is because of just what you see is what you get? Like, immediate feedback, you have a clear sense of scale and what it looks like for player, you can immediate actually play it... is that right? Anything else?

    Thats the major problem I have doing the work in maya is that its easy to get in the zone, laying things out for a few hours, then you load into engine and like scale is a tiny bit off or something - then it can be a PITA to fix little things like that. Of course these are the types of problem a little more discipline in the workflow can fix too, but ideally we can just be in creative zone completely and little human errors don't have a chance to cause so much trouble.

    The editor tool sounds like could be helpful but unfortunately I don't have the chops for that sort of thing. I am really only a gameplay scripter and can do a tiny amount of things in c++ but mostly stick to blueprint.

  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    Yep - that's the benefit. Scale and sightlines are the biggest problem when you're working in maya/max - you just can't get a decent representation of what it's like to move around like the player does.  


    The tool is all doable in blueprints and fairly simple python for the maya half  (you're just dumping transforms for selected objects to a text file)
    the only tricky bit is deciding how to connect a maya object name to a static mesh in your project (simplest is to use string comparisions). 

  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter

    just want to make sure I understand how the tool works. The goal for it is so that you can position objects in Maya, then in Unreal we can match a uasset by name to take that same location, like this:

    In Maya I might position a couple bridges like so:

    In unreal, rather than place these by hand again, we can use the importer tool which is going to say, "given a location, position a static mesh actor there and select which static mesh by searching for a matching string within some directory"

    And so you'd end up with whatever your bridge mesh static mesh asset in unreal is at those same locations?

    And you mentioned instanced static mesh - I should read more about that, my only understanding is that basically an instance is less drain because GPU already loaded it so its ready to go, whereas if it was not an instance we have to find location each time for loading. So like for grass the system uses instances.

    For level geometry, any reason we wouldn't also use instances? They can use collision and you can interact with them using per-istance custom data. The only thing is, in unreal, I am not sure if we can manipulate instances in the same way as an actor. Like grab one, move it around, duplicate it, etc. Just ignore if these are basic 101 questions I haven't properly looked into it yet as I'm not thinking about optimizations for now. It may be something simple like just right click and convert to instances or something.

    And then with nanite it may be different considerations entirely.


  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    yes - that's what the tool would do. it's something you'd want for a building made of modular pieces rather than for a whole level though I think . To do a whole level  you'd basically need to wipe the whole thing out and recreate it every iteration or find some way to keep track of things you want to replace or move  - in all - massive pain in the arse. 


    ISM meshes are sent to the GPU once (per lod level) and instanced there - this means 10 of them uses 1 'draw call'. normal static meshes are instanced in memory but not on the GPU (so 10 of them is 10 draw calls). 
    HISMS are magic - same sort of idea but they can lod independently and still manage to instance on the GPU

    after 4.26 you can enable automatic instancing and it'll treat static mesh actors like instanced static meshes so you don't need to worry about handling instancing between individual props

    It's still worth doing the ISM thing for actors where you want to use lots of instances of modules because it guarantees they'll instance - the auto instancing isn't necessarily predictable


  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    thanks, yeah it looks like this could make for an easier workflow and is worth pursuing. I was poking around to learn more about ISM / HISM and I happened on this video and it looks like it solves the same problem:

    TLDW checklist:
    1. In Maya, export the selection and make sure Preserve Instances is enabled in FBX options
    2. In Unreal, use File -> Import Into Level
    3. In Import into level options, Hierarchy Type should be Create Level Actors.  Static Meshes panel shows only the static meshes while the Scene panel shows each instance.
    4. The actor that is added to the level -> delete its group, select all instances, then
    5. Actor -> Merge Actors -> Batch (this creates an actor in content browser you can reuse, with the ISM setup how you had them in maya)


    update: also linking video from same author that looks like its building similar tool as poopipe mentioned, just in case is needed later or helpful to anybody:

    It has a bit of manual outliner cleanup to do afterwards but I think the core part of the problem is handled: we can work with instances in Maya and bring that directly into unreal and maintain them as instances, while also getting the static meshes imported individually to the content browser.



  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    ohh - very nice. 
    I guess that came from the datasmith stuff. 

    problem solved then 
  • sprunghunt
    Offline / Send Message
    sprunghunt polycounter
    Using maya or something else is not necessary. Unreal has plenty of features that make it easy to make levels.

    There are folders in the world outliner you can use to organise objects. 

    There are also groups which lock a collection of meshes together.

    You can also parent objects to each other if you want. Just like in maya.
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter

    thanks for reply, today I am starting to become a believer :)
    I decided to get some professional help so bought a course from Thiago Klafke and it's full of great tips for blocking out in Unreal. It's given me what I was trying to get - just a dead simple, intuitive way to quickly block things out, get a feel for the level, and have plenty of flexibility so there is not disincentive to make changes / experiments.  Basically, felt like I needed a standardized process so that I can just work, and not spend more time trying to figure out the best workflow.

    Mostly his methods center around using standardized kit and grid snapping - I don't think anything revolutionary, all stuff I understood somewhat but seeing somebody who has done it for 20 years of course is a lot more powerful than coming up with it all on my own.

    I still think there are going to be some portions that make sense to just model as they will be highly irregular (destroyed buildings, paths, rivers, etc), but I'm going to try to get as much as possible blocked out without leaving unreal first.

  • sprunghunt
    Offline / Send Message
    sprunghunt polycounter
    Alex_J said:

    thanks for reply, today I am starting to become a believer :)
    I decided to get some professional help so bought a course from Thiago Klafke and it's full of great tips for blocking out in Unreal. It's given me what I was trying to get - just a dead simple, intuitive way to quickly block things out, get a feel for the level, and have plenty of flexibility so there is not disincentive to make changes / experiments.  Basically, felt like I needed a standardized process so that I can just work, and not spend more time trying to figure out the best workflow.

    Mostly his methods center around using standardized kit and grid snapping - I don't think anything revolutionary, all stuff I understood somewhat but seeing somebody who has done it for 20 years of course is a lot more powerful than coming up with it all on my own.

    I still think there are going to be some portions that make sense to just model as they will be highly irregular (destroyed buildings, paths, rivers, etc), but I'm going to try to get as much as possible blocked out without leaving unreal first.


    Even destroyed buildings can be modular. Here's some examples from art station:

    For a destroyed building I'd think about getting off the grid and not snapping things together. To give it that natural irregular feel.

    Paths and rivers should be done using the terrain spline tools
    https://docs.unrealengine.com/4.27/en-US/BuildingWorlds/Landscape/Editing/Splines/



  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    I dunno ... 

    The reason I came up with tools for turning modular compositions (ie buildings) into single actors are :
    1 : you can store hundreds of instances in a single actor and not clutter the outliner
    2 : it's a lot less runtime overhead than having hundreds of separate actors in the scene 
    3 : you can duplicate a whole building easily and update all the duplicates at once by editing the source actor. 

    throw a load of those onto a landscape, rearrange them as you please and its a pretty flexible way to work. 


    In theory, level instancing in world partition is a better way to do the above - however, since world partition doesn't work properly yet I'd avoid it like the plague for at least the next 6 months .
  • sprunghunt
    Offline / Send Message
    sprunghunt polycounter
    poopipe said:
    I dunno ... 

    The reason I came up with tools for turning modular compositions (ie buildings) into single actors are :
    1 : you can store hundreds of instances in a single actor and not clutter the outliner
    2 : it's a lot less runtime overhead than having hundreds of separate actors in the scene 
    3 : you can duplicate a whole building easily and update all the duplicates at once by editing the source actor. 

    throw a load of those onto a landscape, rearrange them as you please and its a pretty flexible way to work. 


    In theory, level instancing in world partition is a better way to do the above - however, since world partition doesn't work properly yet I'd avoid it like the plague for at least the next 6 months .
    This is fine if you're making that kind of game. And for portfolio work. 

    But Modules should be the size that suits the gameplay space you want. So if you're making a lot of repeated buildings it's ok to have a module that's the size of a building. If you want lots of unique buildings then you need smaller modules. 

    And this is especially true if you want to work in a team with a level designer. If you don't expect the designer to change the shape of the buildings then they can be one actor. But if your level is supposed to have unique building shapes that are tuned for gameplay reasons then you need to allow for someone, who probably doesn't know maya, to edit the buildings somehow. 
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    It seems that the conversion of a building that is composed of many instances to a blueprint actor satisfies a few needs:

    1. it allows us to easily duplicate and transform entire buildings (useful for larger scenes with many buildings)
    2. because a building is composed of instances, we can still select individual parts of the building to move around for tweaking (for instance a building that has been destroyed and had physics sim to layout the rubble - you can still grab individual rubble chunks and move them around if needed)


  • Lamont
    Offline / Send Message
    Lamont polycounter lvl 15
    Alex_J said:
    It seems that the conversion of a building that is composed of many instances to a blueprint actor satisfies a few needs:

    1. it allows us to easily duplicate and transform entire buildings (useful for larger scenes with many buildings)
    2. because a building is composed of instances, we can still select individual parts of the building to move around for tweaking (for instance a building that has been destroyed and had physics sim to layout the rubble - you can still grab individual rubble chunks and move them around if needed)


    Only issue is, without a tool, snapping editing Blueprints is a PITA , and having nested Blueprints might cause issues. I would actually use Level Instances over Blueprints for grouping certain asset types.
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    thanks I'll take a look into Level Instances, haven't heard about that before

  • iam717
    Offline / Send Message
    iam717 greentooth
    just going to add, you all seen the new zelda/link game tears of the kingdom, something like this would be amazing to work with, with environment "controls and creation", their "teleport to areas is cool too, the ascension ability, glad they have this customization ability it is fun, i am glad i experienced it in wild star, apart from actual functionality, really cool.  Edit, mentioning it as if they can replicate what t.o.k. does then they can easily get what they want in thread 1st post.
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    What do you guys think about this?

    We've identified a few ways that you can get a model like this (image below) from maya to unreal. We can set it up in maya, and import in such a way that all these little repeating details come into unreal explicitly as instances. In that case, if unreal will load this model, it would be loading a few static meshes and then just the instance transforms.

    We can also just bring in the individual static meshes and then do placement in unreal - but end result is the same as far as how it would be loaded at runtime.

    Another method is that I can export this entire building (along with all of the little repeating elements) as a single static mesh. That is much simpler - but is there a performance cost? Is this not sort of manually doing what HLOD aims to accomplish? To bunch many small meshes together and cull as a single unit?

    If one part of this building is seen, probably the whole thing might as well be loaded? Like do we really gain much just by having those little repeating detail things occlusion cull when you are around backside of building, for instance?

    Absent of any hard answers probably the best thing to do is leave model grouped but not combined in maya so that it is easy to export it any possible way in future, but just do the simplest workflow for now which is group entire buildings as individual static meshes, and not worry about instancing every little element, even if many are shared across multiple building types?

    Another way to put it is: I am using a modular kit to create buildings in maya. The benefit of modular kit is only speed if I then export entire buildings for use in unreal. Unreal will not know that building A is composed from WallA and ColumnB, and buildingB is as well. As far as unreal knows, it just has two totally unique static meshes - though they share materials.

    In order for unreal to understand that buildingA and buildingB are composed of the same smaller pieces, we'd have to do the instance workflow - but the question is, is there any benefit to load a few static meshes and then tons of instances, or just a few much larger static meshes? 
    Right now many of these buildings are only measured in hundreds of kilobytes, though with more high poly detail naturally that will grow.
    (and just in case anybody is going to yell at me, i am aware the columns and such are much higher poly than needed - this is an example model I'm looking at, it came from sketchup or something like that, not made for games)



    But the TLDR results are, in comparing two levels with about 3500 high poly static meshes, one level is composed of blueprint actors each containing 12 ISM, and other level is composed of static mesh actors, each containing just one static mesh but that static mesh contains 12 columns, the performance stats are virtually identical.
    This is likley more total geometry than I think any levels would contains, but perhaps not a complete representation because this only involves a single static mesh and a few materials.

    I am also not sure what to measure exactly - I mean draw calls are the same but probably this setup would most heavily effect loading times on lower end hardware?

    If I cannot identify any serious problems I'll probably stick with static-mesh only workflow because it is dramatically simpler.


  • Lamont
    Offline / Send Message
    Lamont polycounter lvl 15
    If you can import into UE and keep it as instances, that is fine. Placing by hand is also fine (in case you want variations, group them BP's and what not). I prefer to do import all the parts separated and placed by hand. No telling what an LD would need to adjust, and if it is adjusted it breaks the workflow. So you want to stay fluid.

    Make kits. Keep yourself reactive to the needs of the LD, and make your work more versatile. Single giant meshes are no-no. And I think Nanite doesn't like that anyways.

    Doing that test with all those Nanite mesh's does not give you an idea of performance. It just proves the efficiency of Nanite for a single mesh repeated. What you would be battling with Nanite is pretty much how fast you can get it in and out of memory/disk. Matrix Demo with no people, Lumen, PPE or cars runs above 80fps after everything loads.

    The biggest battle is always going to be lighting (Lumen), material count/use and material complexity, and adhering to the things from 4.27 still hold in 5.X:
    • Light distance
    • Fade Distance
    • Light functions (if any)
    • Shadows
    • PPE's.
    • Few materials as possible
    If Nanite, use ISM.
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    thanks @Lamont , very helpful.

    when designing a kit, do you have a standardized process? Say for instance you are making a city block, maybe 500m - 1km square area. It probably is not possible to just know exactly what pieces you need, make a kit, and then assemble everything from that. I think it's probably better to have the blockout done, maybe even refine the blockout geometry a bit just so that there is not anything too abstract, then you can look that over and identify the common repeating elements, and construct your kit based on that?


  • Lamont
    Offline / Send Message
    Lamont polycounter lvl 15
    I look at building kits in these ways:
    • What biome I am trying to create?
    • How much variation do I need to make this biome look natural?

    So in your case if it was say an area like this:
    Ciudad perdida  Mexican settlement  Britannica

    Think about the types of parts I would need.
    • I see many window types, but I think I can get away with 7.
    • 10~12 doors.
    • Wall segments.
    • Roof types (three might be enough).
    • material types are about 3, and within those three I'd give variation of about 4. So for example brick would have 4 types. And I'd be sure to have my material system robust enough to give even more variation.
    Define units and stick with it (for all other kits as well). Because you need to connect these things in as many ways possible.
    Make support materials that help me make color variations easily.
    If I could or had access, defined rules means you can procedurally generate these buildings. Randomly generate one by one at the very least.

    After that is decided, I think about accessories for these structures to get more variations so the user doesn't see the same thing stamped everywhere.
    • Clothing line
    • Trash cans/bins
    • Bikes
    • Awnings
    • Rain gutters...
    • Pipes
    • Graffiti decals..
    • Air conditioners.
    • potted plants...
    • etc...

  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    ^^  100% in agreement on the process

    this sort of thing takes ages and you need to iterate - more time here == less time fixing mistakes

    for that example I'd want the smallest granularity to represent something along the lines  of a house rather than  a door/window/wall section etc. 
    that could be actor/level instance/group/whatever but I'd want to be able to grab a house and move it around/swap it for a variation/etc. as a single entity.
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter

    thanks a ton! very helpful to me to get some idea how others strategize the whole process. It all makes good sense to me and gives confidence to trust in the process.


    about this sentence here: "for that example I'd want the smallest granularity to represent something along the lines  of a house rather than  a door/window/wall section etc. "

    you mean that within unreal you'd simply want some way to select entire buildings in ergonomic way, but those buildings are still composed of instances of some modular kit, right?

    Like we have WallA, DoorB, WindowY, and these are instanced around to make BuildingB, and then as designer you typically just want to move that entire building around. Then if you need some little variation on the building in some corner, you can just duplicate the building, tweak it, and replace?


    I did compare file size of .uassets of a building. One where building was composed of a few ISM's and another where entire building is just a single unique static mesh, and the ISM file is considerably smaller in size. Difference was 3.4 mb compared to 300kb. I think that this is a more useful comparison to previous experiment I did comparing runtime performance. Because the major concern is simply how much data we are loading. In a streaming situation it could mean slowdown while actively playing, but even in an old school design where entire level is loaded at once, this would concern that load time. And in both situations, download size of the entire game, right?



  • poopipe
    Offline / Send Message
    poopipe grand marshal polycounter
    Yeah, exactly that wrt the granularity. Swapping the buildings out for other ones is easier etc. as well. 



    And yes - if you smush everything into a single static mesh you're wasting resources. Unique mesh data exists once in memory regardless of how many times you use it - using modules saves lots of resources because you get to use the same data many times (the difference between ISM and static mesh is purely on the GPU) 

  • sprunghunt
    Offline / Send Message
    sprunghunt polycounter
    @Alex_J
    have you seen the making of video of The Matrix Awakens ?
    https://www.youtube.com/watch?v=xLVJP-o0g28

    It seems like that's a good example of what you want to achieve and the kind of technology you'd need to use/create
  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    I had started downloading the example project at some point, got sidetracked, and forgot about it, lol. But i've heard they are heavily using instancing, so might be some good tricks in there. Will check it out, thanks

  • Alex_J
    Offline / Send Message
    Alex_J grand marshal polycounter
    Update update:
    Okay, finalized a workflow that satisfies my needs well enough. Made a tutorial for it here:
    https://youtu.be/uGMJodCvuis


    Update: Some research on the subject was shared on unreal forums here:
    https://recourse.nz/index.php/rdbptools-benchmarks/2/

    Some of my own test, in which I compare a building as single static mesh, compared to a packed level instance that is composed of 34 individual modular kit parts being instanced.

    I don't think runtime performance is going to be any issue here. It's all simple materials and level is not very big. But it looks like PLI's will be significantly less disk space. But it is a lot more work to setup. If the disk space is a matter of like, 10gb versus 30gb, maybe better to go for speed.


    Original --------------------
    Digging back into this. I'm still trying to get my workflow together and have whittled down to a few final questions.

    First priority is always ease of authorship, but there is some secondary concerns about general efficiency. I'll define the two workflows and how I see pros and cons of each.

    Workflow 1:
    1. In Maya, construct kit consisting of minimum common elements.

    Seen here a few blocks of various sizes

    2. In unreal, these can be combined to create larger compositions, like walls, and then walls into buildings:


    Packed Level Instances can be combined on top of each other. For instance, blocks to wall, walls to building. So once one wall is made, you don't need to redo the work except to make variations.

    Pro: More flexibility to create variations.
    For instance, if I want a hole in the wall, I can just make another Packed Level Instance for that variation and as far as unreal knows, there is no new static meshes involved. Just a different Packed Level Instance.

    Pro - less memory footprint
    Is the overhead of additional static meshes in the project compared to additional PLI's any different?
    It appears that PLI saves some memory compared to having more unique static meshes. For instance, a PLI that has four walls and roof composed of about a dozen unique static meshes being instanced is similar memory size compared to a unique static mesh of just one wall.

    Will this difference matter? 
    Unclear and I cannot easily test. If no further information can be gathered, will err on side of caution and go with this workflow, sense the ease of authorship between workflow 1 and 2 is not severe.

    Con - Ease of authorship
    Setting up walls and roofs and so on in unreal is slower compared to maya. But its not terrible because PLI's can be reused like prefabs.


    Workflow 2:
    1. In Maya, setup the same minimal kit, however...
    2. Combine into larger compositions (like walls) inside of maya, and export this as a unique static mesh.
     

    Pro: Faster authoring
    More of the snapping, selection, placement type of work is done in maya, so it is much faster.

    Con: Slower variations
    If I want to punch a hole in a wall, I have to make a new variation in maya and export that, compared to making the variation in unreal and getting more immediate feedback. But the time difference in minimal. Not a major concern.

    Con: More memory footprint
    If I want hole in the standard wall, this requires a unique static mesh even though it is largely the same as standard wall.


    Still much uncertainty, though at least I have two clear workflows defined. I'd prefer to make all the compositions in maya because it is faster and easier, but concern that I buildup a bazillion unique static meshes when there could have been just a dozen makes it seem like could be an issue where much work is done and then if it turns out to be a problem, it's tough shit. Have to redo it. I don't see any way to do a quick test other than compare a few examples and extrapolate from that.












Sign In or Register to comment.