Vespers3D: The End of October Vespers Thing

Not long ago I started a separate blog of my own over at The Monk's Brew, which covers adventure games, indie game development, and the journey of creating Vespers3D. I'll try to cross-post when I can; here's a recent entry I thought some here would appreciate.

Vespers3D: The End of October Vespers Thing

Wow, October came and went in a hurry. Halloween and the ongoing IFComp took up a lot of my time toward the end of the month, which threw me off by a few days. So here, at the start of November, is an update on Vespers over the past month.

On the modelling front, N.R. and I spent much of the month improving the performance of the game with some creative workarounds for the problem we have had with portals in Torque. Portalization, for those of you unfamiliar, is a method used by people who model interior structures for Torque (such as buildings) to split up these models into "zones" in order to reduce rendering overhead. So basically, if a building has different sections or floors, for instance, you split it up into zones using portals placed over any of the visible openings into to that zone (such as a doorway or window). The Torque engine then uses the portals to determine when it should render the geometry and any objects within that zone -- if the player can "see" any of the portals to a zone, the engine will render everything inside. If not, all of those polygons can be skipped, which can significantly improve rendering (and game) speed in most cases.

The problem is that it can be very tricky to get portals working in Torque. The interior model must be completely sealed everywhere for portals to work -- there cannot be any leaks of any kind, or the zones will not be set up. Portals are created in the modelling program using special "brushes", and there are a whole series of rules you must follow when using these brushes, or the zones will not be set up. Portals must also be square or rectangular, which presents problems for some of our arched windows.

As an example of how fussy portals can be, there is a page on the Torque Developer Network devoted to creating portals, which has a section titled "Unproven Findings About Portals". Here are actual entries from that section showing what modellers are up against:

- Sometimes thicker portals experience problems.
- Sometimes portals can be made that are touching more than 4 other brushes.
- Sometimes portals will not work no matter what; and sometimes a portal works
  even when you try to build it wrong.

Encouraging stuff, especially when there are so many issues that are qualified with "sometimes" but without any additional information on when one might encounter those situations. In any case, it's likely that the interior models in Vespers are too complex for portals to work effectively, and it would take far too much effort to get them working at this point anyway.

So, we decided to try another route to reach the same destination.

As mentioned, the interior models in Vespers, such as the church, dormitory, refectory, and entrance hall, are fairly complex models with a good deal of geometry used to create detail structures, such as the wooden beams along the walls and ceiling. Most of the time, however, the player is only able to see a small portion of all of this geometry. Take the screenshot below, where the player is in the main entrance hall, looking out towards the cloister:


Here is a layout of the monastery, with the arrow showing where the player is located and which direction he is facing:


All of those structures in the layout are being rendered by the engine -- the church, refectory, dormitory, kitchen, and so on -- and yet only a small fraction are actually visible from this position. That's a lot of unnecessary rendering. Everything inside of the church, all of the different rooms in the dormitory, even the kitchen and calefactory -- all of these are there, and the engine has to deal with every detail of each one, even though most don't need to be drawn on screen. So if we can come up with a way of not rendering all of these things, then performance should improve dramatically.

The solution we came up with is to create our own set of "zones" -- areas that define which buildings and objects should be rendered, and which should not -- using the game's general room structure as the guide. So for instance, we can define a "Bedroom Zone" such that, when the player is in the Abbot's bedroom, we know to render the bedroom, main entrance hall, and locutory (and all of the objects therein), but we don't have to bother with the kitchen, calefactory, refectory, church, and so on, or any of the objects within those structures. We define these zones and their contents in script, and when the player moves from one room location to another, the triggers at these locations tell the engine to check the new zone and render only what needs to be rendered. The result is similar to Torque's portal system, but in fact we end up with a bit more flexibility.

Sometimes, however, we only need to render part of a building. For instance, when the player is in the main entrance hall, we need to render the refectory -- but only the outside of the refectory, since the player shouldn't be able to actually see anything inside the refectory. Same for the church and dormitory. So to do this, we created multiple different versions of each building -- one with all of the interior details, and additional ones with few or no details inside -- and tell the engine which one to render at each location in the game. We do this by specifying each model version as one "level of detail" (or LOD). LOD is normally used by the engine to draw lower-detail versions of models as they get further and further away from the player, also reducing rendering overhead. But in this case, we use LOD here in a slightly different fashion. Since the engine allows us to "force" the display of a specific LOD when we want, we use this to our advantage to display the LOD version specified by the zone.

The results so far have been mostly good.

In general, we have been able to increase frame rates significantly. Whereas before we were seeing a good deal of "lag" on older machines in many game locations, now most lag issues are completely gone from these older machines, except in some of the most intense rendering areas (such as the cloister) where there is still some optimization to be done. On more recent machines, frame rates are now excellent, and that makes me happy. But all is not perfect.

The problem is that we've now run into the occasional "pause." There are some areas in the game where, upon moving into a new room location, the number of models (buildings, scenery objects, lights, and game objects) being toggled on or off is quite large, causing the game to noticeably hesitate for a moment while it performs all of these actions. Although I'm really only noticing this on lower-end machines, it can be pretty jarring, and is definitely not the kind of thing I want to see.

There are still some things I can look into to help the situation, but overall I'm pretty happy with the results so far.

Aside from that, we've spent some time working on additional environmental decorations, such as piles of scattered dead leaves to distribute around the monastery, including a few versions with leaves that animate with a light breeze blowing through them. Should provide a nice little measure of ambience to the scene.

There have also been some advances on the NPC animation front, although I'll wait to report more the next time. Most of our characters have been re-rigged in Maya now, including facial bone structures to provide expressions and lip sync, but since there's not much to show just yet I'll save it for a later blog describing the whole setup process. I'm pretty happy with where the character models are at right now, and hopefully over the course of November we should start having some animations to plug into the game again. Should be fun to be doing that again.

Until next time...