How are you organizing level design for ease of iteration?
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
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
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).
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
I guess that came from the datasmith stuff.
problem solved then
You can also parent objects to each other if you want. Just like in maya.
Even destroyed buildings can be modular. Here's some examples from art station:
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 .
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.
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?
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.So in your case if it was say an area like this:
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.
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.
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)
have you seen the making of video of The Matrix Awakens ?
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
Okay, finalized a workflow that satisfies my needs well enough. Made a tutorial for it here:
Update: Some research on the subject was shared on unreal forums here:
https://recourse.nz/index.php/rdbptools-benchmarks/2/
1. In Maya, construct kit consisting of minimum common elements.
Seen here a few blocks of various sizes
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.