Blockouts for 3D Environments
I want to ask why people make environment blockouts in their 3D programs and then using that to create their environment in engine. Isn't it a hassle to arrange everything in the 3D program then have to do it again when you go to the engine? I just want to understand what's the purpose of this step when creating environments.
Replies
I'm blocking out a level at the moment with modular pieces. I can edit the individual pieces and see that it tiles correctly instantly, and easily see if I have the most efficient use of pieces to create the desired scene. In a perfect world I'd send the scene file from my modeling program to the engine, and it'd replace all the instances automatically, but at the moment yes you do have to do it twice if you do it this way. I find it much easier to work in my 3d package so I did it that way.
I've seen blockouts begin in UDK, then be taken to a 3d package, refined, then individual assets taken back to UDK as well. Whatever makes sense to you / seems better for the task at hand, obviously there's no single correct method.
As Placeholder geometry...
In a production pipeline, if a designer is waiting on level components, then if a dimensionally and functionally correct placeholder or standin is created. This will be used instead of final art so they can do their job without this art bottle neck.
To facilitate iteration...
Quick and dirty geometry is best for fast iteration, when all that is important is gameplay. Meshes can be ripped about and tweaked until it plays just right. The quicker you can get to near complete gameplay signoff the better and easier it will be for everyone. Blockouts help us to achieve this.
Unfortunately, this extremely important design stage can and does get compromised by the demand for early demos, or vertical slices and what have you, so it's never really a perfect process.
Once art starts replacing blockouts and doing final passes, any changes will cost time and money so you'll find resistence to change at this point. This can lead to conflict with design (often caused by high level feedback that invariable requires final art to visualise the game).
I can't stress how important it is to getting your gameplay nailed as soon as possible. Blockouts, white box, greybox, stand-ins, proxy's or whatever you call them help this process enormously.
Say that this wasn't for a game, but for just personal practice like the Monthly Noob Environment Challenges. How could you still apply this without having to focus on gameplay?
But it's also a massive help to artists to help them plan things and see a closer vision to the final scope the level or game represents.
The more accurate and broken down your whitebox/greybox pass is, the easier it will be to translate that into working sheets for planning, and avoid surprises.
Then as others have said, it's both a useful compositional technique and a way of chunking your scene, i.e. finding elements that repeat, are unique and could help prefab your scene.
Our concept artists will create (or use existing) blockouts and overdraw them to visualise the scene. Without game play messing things up, one possible workflow could be...
It depends, at the very beginning of a game or project you will likely have nothing to whitebox from.
It kinda changes as you make progress into production, as you will find yourself then having access to a wide range of finished props or structures, and then it becomes that kind of hybrid greyboxed environment where some of it is in finished state, some still whiteboxed. It's in constant evolution then until bit by bit you update. The more modular you worked when greyboxing, the more time you save later on when replacing models for the final assets, since you dont need to place stuff again, especially if you sticked to a grid.
I would tend to use solids/bsp at the start, when there's nothing else at hand. Only to rule them out very quickly with models. Because models will help you visualize how much re-use you can get, and how much work you have to plan for.