VOXEL GRAPHICS IN MOO3

From Bill Fisher, Executive Producer:

Looks like it's time to answer some questions about MOO3 graphics. I'll start by talking about the motivating factors behind what we're doing, and you can follow up with any additional questions and thoughts you may have.

We're using a software rendering engine for MOO3. It incorporates both voxel object and polygon functionality, plus some specialized rendering modes. What we use depends on what we're trying to accomplish. We're not doing voxel terrain like Comanche, though -- it's something quite different.

When I start a project, my first question is always "what's the target machine?" In order to do the best quality product, we need to have a clear understanding when we start about the machine we'll be running on in the real world. Not all of us have 1 GHz computers. This is especially true since we expect half of our sales to be in Europe, and machines there tend to be upgraded more slowly than in the States (things are often a little more expensive there).

Microprose, and then Hasbro Interactive (our first two publishers for this title) did surveys and told us that their customers could be expected to have two or even three-year-old hardware. That meant 233 MHz machines with no hardware acceleration. Hasbro, in particular, tended to cater to the broadest possible market, which meant that they tried to make games that would work on any machine. We've always done the same, so it was a pretty good fit.

We spent a long internally time discussing the technology for this game. Hardware acceleration would allow us to do some very fancy 3D combat graphics, but wouldn't do anything for the turn-based user interface that we couldn't do in software. It would also restrict the number of machines that could play our game. But it would be a cool bullet-point on the box -- "optimized for 3D accelerators" or some such. We could, of course, write a software renderer as well, but that would take a lot of time that would be better spent on the gameplay, in our opinion.

We had already developed a very powerful voxel engine on a previous project, so we knew that it was both possible and very attractive. Voxel objects are best when relatively small on the screen. But with the sorts of large-scale battles we planned for MOO3, we never expected ships to be really big anyway. And voxels are really easy to draw, even easier than in our previous product, because they're shown against the relatively simple background of deep space. Also, voxels allow the rendering of extremely detailed objects, using far more polygons than if they were rendered using traditional polygon hardware. The biggest drawback to voxels is that they take a fair amount of RAM if they're animated. But we don't need to animate spaceships very much. Again, it's an ideal use of the technology.

Ultimately, we did a series of three "taste tests" with our own team and with Hasbro/Infogrames people. We showed off the combat mode demo without explaining what it was, and everyone's response was "that looks great." We asked if they had a problem with the technology, and they said "not at all." We all felt the same way. Look at the combat, it looks cool, so who cares how it's done?

My only concern with this choice was that it wouldn't say "hardware acceleration" on the box, and that might make a few people think it's not a cool game. But that doesn't seem to be a problem. We talked about the technology when we demonstrated the game at E3 and subsequently when the CGW folks came by for their all-day meeting with us. Not a single person had a negative comment about the visuals. In fact, the comments we got about the visuals were very positive. That's when I knew we'd made the right choice.

Here's a little more information about the technologies we're using in MOO3. Ships are drawn using our custom voxel renderer. As was mentioned in a previous post, voxels are basically like little Lego cubes. An object is made up of a big stack of cubes, just like the huge structures you see at places like Legoland (there's a Legoland about an hour south of here. It's really cool).

Another way to think about voxels is to imagine one of those 3D fabrication machines that people now use to create industrial prototypes. Basically, they use some form of 3D positioning mechanism like a pair of laser beams to solidify liquid plastic in a "rendering tank." Our rendering tool for creating voxels is even called the "tank." The shape created in the tank is a hollow shell that matches the actual 3D contours of the object at a high level of detail.

The voxel code retains the colors of each dot, plus various other useful bits of information that allow us to handle lighting, color changes, and some other useful rendering tricks. This is all packed into a highly compressed format so it can be quickly scanned and drawn every frame.

Obviously, how much detail we keep is directly related to the dimensions of the tank. If the tank is only 50 voxels high, we don't get nearly as much information as when it's 100 high. The drawback is that storage requirements increase with the square of the dimensions of the tank, so doubling its size quadruples the RAM requirements. Fortunately, we're not animating the ships like one would animate a person, so we can pour a fair amount of detail into each ship (just like many 3D mechanisms, we use several levels of detail, or LODs).

What's cool about this technology is that we can represent extremely complex objects without any drawing-time penalty. The renderer doesn't care about the complexity of the curves. It just draws dots wherever it's told to draw them. You've probably noticed the graceful, sweeping curves of the Insecta ships or the spherical hull structures on the Ethereans and some of the others. Curved surfaces are terribly expensive to create using traditional polygons. Ross can tell you how many polygons are in each of the ship models. They're in the tens of thousands. It would be impossible to get such detail in ship models used in the actual game. Even a GeForce3 would grind to a halt. Our renderer, on the other hand, doesn't care. We can draw 50 of them per frame quite easily -- hundreds in a really big battle.

Another cool thing about using a software rendering system is that we can hybridize technologies. We can anti-alias the ships to increase detail. And some of our special weapon effects are customized texture maps drawn onto polygons. Finally, Ryan is working on a very interesting planet drawing mode that blends the best of voxel and polygon techniques to generate truly round-looking planets (do you realize how many polygons it takes to make a planet that doesn't look like one of the dice from a D&D game? It's much easier for us).

One final trick is that, since we're in control of the rendering, we also have full access to the Z buffer. That means we can do realistic over-and-under computations to make complex scenes look correct. Our objects interpenetrate correctly, for example. It's computationally very expensive to do that in a polygon world, but it comes as a natural side effect of the software-based rendering that we do.

Can you give an example of how complex some of the common ship models are in highest/lowest LOD?

I'm not sure what you mean exactly by "how complex?" It's not like a polygon model, where the higher LODs have more polygons. It's quite simple, really: the higher the level of detail, the more dots are in the image. A good way to think of this is to think in 2D rather than 3D. It's like a sprite image. If the sprite is 50 pixels tall and 40 wide, there are 2,000 dots (ignoring the empty ones for the purposes of this discussion). If it's 100 pixels high, then it will be 80 wide in order to maintain the aspect ratio. That gives you 8,000 dots.

Moving into 3D space, it's basically the same deal. A voxel rendered in the "tank" at 50 dots high will have a certain number of dots, and one at 100 will have 4X as many. From a complexity standpoint, it's the same. Only the length of the list of dots has changed.

Do you have a dynamic LOD (a la Sacrifice/Messiah) that adapts to the available processor power/need?

We've talked about it and done some work along those lines, but I'm not sure what's in the code at the moment. Basically, it's easy for us to use higher-quality models if we have more CPU power. We'll probably offer a mode which disables antialiasing, for example, since that requires the use of higher-resolution models and therefore takes more power. We may not need to get too tricky on the dynamic LOD stuff, but we can if we need to.

What LOD will the target machine be able to display on average? (i.e: do you get lots of bang for your buck if you have a GHz?)

What you'll see most on the faster machines is a combination of higher quality and higher frame rate. Greg's combat code is independent of the speed of the machine, so a really fast machine can play against a really slow one and get reasonable results. But the faster machine could be drawing frames at 3X the rate of the really slow box. As I noted above, one way to equalize this is to disable antialiasing on the slower box. Another would be to ratchet down the LOD scaling so we're using smaller data and doubling-up the sizes on the slower machine. As you can see, there are a number of adjustments we can make.

When will graphics cards incorporate hardware voxel engines?

Not any time soon, that I'm aware of. Unfortunately, it's a _very_ different technology, and consequently has very different requirements. I suspect we'll see more active discussion of this topic in a few years, given the current rate of decline in RAM prices. You'd want a huge amount of RAM on a card to make this technology worth implementing in the general case.

I hate polygons! Please don't make all the graphics polygons! I like smooth graphics...

If you're referring to the angular nature of many polygon-based visuals, that's one reason we're not using polygonal ships in MOO3. We are, however, using polygons for all of the ship design work, and for all of the cinematics. There, unlike inside of a game, we can use tremendous numbers of polygons. As I noted in my previous posts, we have tens of thousands of polygons in the original data used to create the voxel ships. And some of the scenes in the intro movie are straining the limits of our rendering software with over half a million polygons in a single frame.

Bottom line: it all depends on what you're doing and on choosing the most appropriate tool for the result you want to achieve.

Regarding the use of voxels as shells without rendering the insides of objects:

It's done as a skin. I like to think of it as being like the chocolate coating they put on your cone at Dairy Queen. It's just a thin shell. In the case of the voxel object, though, it's basically a shell that contains only empty space. We do that, as you'd surmised, in order to save storage. No sense keeping track of pixels nobody is ever going to see.

From Ross Worthley, Lead Artist:

Here's a quick run down of the main reasons voxels were chosen over polygons for combat ships.

1. By using voxels we are able to display MANY more ships on screen at once then we would be able to using polygons. Voxel objects do not require a powerful 3d accelerator to render. In fact voxel objects are rendered completely in software. This means that even if you don't have all the latest hardware (like me) you will still get a visually pleasing combat experience.

2. By using a rendering method that is less dependent on computer horse power we allow for a much larger audience. Not everyone has the latest and greatest equipment and we don't feel that they should have to in order to enjoy our game. Speaking of Comanche, I'm sure many fans of the previous games in the series were disappointed to find that you need a GeForce 3 card to run Comanche 4 well. We didn't want to put MOO fans in this position.

3. If we had gone with polys, we would have had to make two versions of each ship. A low poly version for in game combat and a high poly version for menu screens and rendered movies. Using voxels we can make a single high poly version and convert it to voxel form. Not having to make each ship twice allowed us to make twice as many ships.

4. Since during combat no single ship will ever take up more than 1/10th of the screen voxel ships look better than low-poly. As long as voxel objects are viewed at a distance the shape appears infinitely smooth and allows for great detail. When modeled low-poly the ships would be visually stunted at any distance.

While this is by no means a complete list, it should make clear some of the reasons we made the choice we did. Rest assured, we here in the QS art department are just as determined as you are (if not more so) to make sure that MOO3 looks as good as it can. If we though for a moment that using voxels instead of poly would in any way degrade the visual appeal of the game we would NOT have chosen to use them!