It has been a while since my last post in this blog series. It is difficult to find the time to write, so I'll try to keep the words few, and use images to explain where possible. The topic this time will be a breakdown of this burning flame shot.
The biggest dilemma when doing art for a game is that if I spend time on modeling and texturing something like a doorway, it may later turn out that the doorway is too narrow, and the player capsule easily gets stuck when passing through. It is difficult to leave the blockout stage. And even blocking out a simple gameplay scenario in Maya takes considerable time. I'll discuss how I approached these two problems.
In a previous post, I briefly mentioned the procedural dungeon generator I made in Houdini. This does not give you much control for setting up a specific gameplay scenario. I have been torn between the two options of procedural generation and manual blockout. This time, I am taking a hybrid approach, making a simple grid based design in the Tiled editor, and using this as a base for generating the level in Houdini. Here is an example map (please excuse the ugly tiles, but avoiding doodling on these are also important to save time during game development).
This map could be exported as for example a CSV file, but exporting is an extra step that takes time, so I'm am parsing the original Tiled file in Houdini. Based on this, I determine where to place doors, floors, walls, pillars, roofs etc.
Next, I generate a point cloud with position, orientation and the ID of the entity (modular piece) to place.
Finally, the modular pieces are instantiated at each point.
A little technical digression. The game engine also needs the point cloud to build the level. Again, exporting these would be an extra step that would take time. There is a little library that comes with Houdini called libHAPIL.dylib. This contains the Houdini API (HAPI). In my Unity implementation, I call this directly to ask Houdini for this point cloud. After saving a map in the Tiled editor, the new level will be immediately available when running the game. SideFX also provides artist friendly Houdini Engine for Unreal/Unity, but directly using HAPI allows for more flexibility, like reading this point cloud with entity IDs.
As mentioned, the problem with making modular pieces is that things like the size of a doorway might change due to gameplay reasons. The approach I took for these was to generate each module procedurally in Houdini. For example, the module below consists of two pieces, the stone doorway, and the metal portcullis. These are separated, as the portcullis is animated when opened.
The doorway part has 18 parameters that can be modified.
The portcullis part is a bit more simple, with only 10 parameters.
Also, the torch consists of two parts, the torch itself, and the holder, in case the player would pick up the torch.
The torch parameters would not fit on one page, so in this case, I had to divide it up into several tabs.
The generated geometry has clean watertight topology, so once I know it is working well with the gameplay, I can take it into ZBrush to add fine details. Alternatively, I might do procedural sculpting in Houdini, by boolean out dented corners, like this example.
Or possibly converting to voxel volumes, and doing the same thing for a more ZBrush-like result.
The generators themselves are also built using a boolean cutter approach. A pillar is generated from a solid block, that is cut into slabs that are stacked up on top of each other. Each slab is further shaped by cutting off the sides. These cutters are currently flat planes, giving a very clean and simple result. By adding noise to these planes, a more organic result would be achieved (exaggerated example to illustrate the method).
Likewise, the texturing can also be done manually in Painter/Mari, or procedurally in Substance Designer or in the shader itself. Any metadata that would make texturing easier, like IDs for different bricks in the stone wall, can easily be injected by the generator as needed.
As I plan to make a short promo cinematic for the game, it is convenient to reuse the models already generated by Houdini. I am personally a big fan of Clarisse. The point cloud can be imported into Clarisse as an alembic, and the entity IDs extracted and used to scatter the modules, rebuilding the level.
The orientation is stored as a forward vector, which require a bit of a trick to use in Clarisse. In case someone would like to try this at home, here is the required setup. The forward vector (which I store as point normal) is extracted as euler angles. Then (0.0, 0.75, -0.25) are added to the euler angles, and fed into the scatter rotation.
This time, I wanted to render out a burning torch in Houdini's built in renderer Mantra. The flame is a pyro simulation. One problem I encountered here was that the light emitted from the volumetric flame was not strong enough to light up the room. My solution was to spawn lit particles from the flame.
I wanted to be able to tweak the lighting in Nuke, so I needed AOVs for each light source. This is not well documented, and the only way I could get Mantra to output the AOVs, was by exporting the VEX variable "all" for each light (H17.5).
The final composition is the render at the top of this blog. Everything was done procedurally in Houdini.