Your opinion when using 3D modeling software as a level editor

orangesky

Hello! I have a question; I would like to know what people who have been in the industry much longer than I have think about this workflow.

I've seen a lot of people on the internet using the following method; they usually create the entire level in 3D modeling software and then import everything as a single mesh into the game engine.

Example in video:

https://youtu.be/tPuIbGO_954?si=MFNk9FGsxjChfNs2

In my opinion, this is a bad practice, but do you think that for certain types of games, for example, games that aim to mimic graphics from Nintendo 64 or PlayStation 1, where low polygon counts are used, this could be an acceptable practice?

What do you think about using this workflow in games with modern graphics? I think The Last of Us uses a similar system with Maya (but I'm sure they have tools that make Maya integrate well with their graphics engine when exporting).

I would like to read your opinions!

Greetings!

Alex_J

its probably pointless to make any general suggestion. if you have a specific project and goal in mind it may be possible to consider how certain tools could help.

in general, having steps between edit the level and play the level is worse than having immediate feedback.

if you were remaking goldeneye n64, as an example, I still think you'd have easier time to export your level into pieces so that you can move them around to experiment quickly in the game engine.

FWIW in my own project I do level blockout mostly in maya and export in chunks to the game engine. but for level art I have to break it down to smaller pieces and it gets more complex. If your games level art was not more complicated than blockout geometry I suppose it wouldnt be much of a bother to place it in DCC and export to game engine. It only takes a second to do and then verify in game engine and you might find this more efficient if you are much faster working in DCC.

You have to consider things like occlusion culling though. it may not be any issue if your whole level isn't so big and complicated but to get some idea you have to know what sort of hardware requirements you'll face and do some stress test.

rexo12

I think building the level in a DCC and importing it is essentially your only option? Given that stuff like BSP fell out of favour for plain geometry long ago, that makes a DCC the most capable tool for building out level geo. Unreal, for example, has only recently added a modelling toolkit and it's still not particularly impressive, certainly wouldn't try to do anything other than small tweaks with it.

Importing the level as a single mesh is problematic, as this will basically prevent frustrum culling, occlusion culling and dynamic shadowmaps from working. For Unreal it will also produce low resolution distance fields, and if using lumen will be missing a lot of surface cache coverage. The asset would also just be a PITA to manage in the editor. That said for this particular use-case (imitating N64 graphics) none of the above really matters.

orangesky

Alex_J, I believe this phrase can summarize this post very well:

"It's probably pointless to make any general suggestion. If you have a specific project and goal in mind, it may be possible to consider how certain tools could help."

And if I share the same opinion as you, I think that creating modular pieces, which are placed directly in the engine in highly repetitive areas like all the corridors in GoldenEye, is the way to go for current engines.

This provides a lot of versatility when making changes and modifications throughout the level. If we want to change the size of the windows, we only need to do it once. If the entire level is one single piece, that modification would have to be repeated as many times as there are windows in that level.

In any case, both methods are suitable for retro imitation projects. The only difference is in the development speed, but there won't be much performance variation with today's hardware.

rexo12 Yes, it's a shame that BSP tools have disappeared from Unreal. Those tools defined an era and made it much easier to create a blockout. I don't like using Unreal's current tools; I prefer to prepare a modular kit for the blockout in Blender and assemble the entire blockout in the engine using those pieces. I believe that's a quite efficient and fast way to create blockouts.

I've just come up with two more questions related to the topic:

1. Originally, when developing for Nintendo 64, PS1, or even PS2, I assume it was common to use 3D modeling software as a level editor and import the result as a single piece into the graphics engine? That's how they did it in the early Ghost Recon games.

2. When did optimization systems like occlusion culling start to become popular? I suppose that during that time, it was more expensive to use an occlusion system than to render small levels with many loading screens in between.

Klunk

It really depends on the tools you have in house. there was an adage I saw  IIRC in Game Developer Mag circa 2005 along the lines of "Great Tools make great games" in an article on this very subject. Obviously back then the engine editing packages were pretty limited at best. Most of the "big" modelling packages are very open ended with well document scripting and sdk with all the modelling tool one could ask for and can pretty much wysiwyg with the best of them. 

I've worked with text editors, in house editors, engine editors, third party editors and modelling package editors you just get used to it