Interview with Umbra at the Game Developer’s Conference 2008
Posted March 3 1:09 AM by Graham Rhodes
On Thursday, 21 February 2008 at the Game Developer’s Conference 2008, I spoke with Teppo Soininen, Head of Special Operations for umbra Software. Umbra has been around for several years. Their products provide solutions for real-time occlusion culling of geometry, to improve rendering performance of large 3D scenes. Umbra’s website is at umbra software.
Teppo began our conversation with a demo application, based on Big World Technology’s MMO engine, using umbra’s middleware for real-time geometry management.
TS: Basically, this is our middleware solution, which is using Big World’s engine to do rendering. What’s happening over here, here you can see the player’s eye view, and on the right-side you can see the bird’s eye view of the whole scene. You see only the visible geometry, a couple of houses. Now, I switch umbra, our middleware solution, off, and you can see the whole city. A real big city. This has more than a hundred thousand objects around, and it would ridiculously slow the rendering without any occlusion culling or visibility optimization. If we turn umbra on, and you can see it only renders the houses that are visible. I can move around, it updates. All the updating is done on the fly. We’re not doing any preprocessing of the scene, or anything like that.
GD: It looks like you may be frustum culling whole tiles.
TS: Yeah, this is frustum culling only. Inside the view frustum, we’re actually culling whole objects and tiles of terrain blocks over here, but the terrain blocks are handled as normal objects. We support dynamic objects, spinning object, the visibility changes constantly as the objects are moving…we support that. And what we’re actually doing over here is we’re taking all the geometry that’s in the scene, we’re making bounding volumes of all the objects and we’re forming a hierarchical data structure, like a spatial hierarchy.
GD: Are you doing this in object space?
TS: Yeah, object space. And screen space of course, since we need to know where the objects are aligned.
GD: Is the occlusion per pixel?
TS: Yes, the occlusion culling is done per pixel. What we do is we have a certain set of objects that we know are going to be visible on the frame. We render them to the depth buffer, and then we do occlusion queries, hardware occlusion queries with the GPU. For occlusion, the bounding volumes, we render them, see how many pixels would have been visible if the object was rendered, and if zero pixels would have been visible, we don’t render it at all. And because we have the spatial hierarchy, we actually can occlude huge chunks of objects. The spatial hierarchy is so that on the top level you have the whole scene, all the objects in one big bounding box, and on the bottom level you have only single objects in a bounding box. You traverse the hierarchy. We actually update the hierarchy on the fly, so objects that are not visible are not included in the hierarchy. We drop objects in the hierarchy once they become visible.
The only thing we’re relying on the Z-buffer for is doing the hardware occlusion queries, and the results are coming back. But the hierarchy we have on the object level is just a spatial hierarchy, which is an axis-aligned BSP, so we can see where the camera is and what objects would be visible from that point-of-view. We can actually dynamically add stuff to the hierarchy. You can have player-created content. You can blow up houses. The visibility can change drastically, and it works just fine.
GD: How many objects have you been able to handle?
TS: There’s no limit. Basically, the memory is the biggest limit. On the Xbox, we have an Unreal demo, which has as many objects as we could fit into a test kit Xbox’s memory, and this scene has more than a hundred thousand objects. The only thing that limits the thing is that the editor becomes so slow that it’s a pain in the ass to add objects, but there’s not a practical upper limit.
GD: Your hierarchical model enables you to cull away a lot of those tests, so you’re not looking at a hundred thousand occluders.
TS: Our system efficiency is not linearly dependent on the amount of objects. The idea is we are only dependent on the objects that are visible in the scene, not the objects in the whole scene. We’re making the system dependent on the output, not the input.
GD: The image on the right, the top-down view of the entire world that shows objects moving between visible and visible as the occlusion changes, is what’s telling the story.
TS: Exactly, and you can see wireframe the objects are popping in and out as they become visible or invisible. Let’s go behind the house, spin the house to the right. You can see the houses popping in and out. We deal on an object level, whole houses pop in and out.
GD: Are these houses modeled at the interior level?
TS: No. But because we have all the spatial information, we can do front-to-back rendering, so there’s no different if you are inside or outside. For example, let’s say you’re in a corridor inside. First you render the walls, then you render the ceiling and so forth, and everything that’s outside gets occluded. We can determine from the hierarchy that everything beyond this wall has been hidden because we do the occlusion query against the hierarchical bounding box.
GD: Do you represent depth as single or double precision?
TS: It depends on the rendering engine. It can be done whatever. We don’t care so much.
GD: The reason I ask is once you get into very fine-grained occlusion, for example wall thickness, or large worlds, then you may run into a floating point precision issue with single-precision. Its not hard to do.
TS: Yeah, we’re not actually mandating any precision. The renderer can do whatever it wants.
One of the biggest issues we have, because we render the real objects into the depth buffer, we can use trees for example, as occluders. The whole idea is that we render everything in the Z-buffer and do occlusion queries with the Z-buffer, we can use trees, for example, which are traditionally bad occluders, and we can use them as occlusion materials. A single tree doesn’t occlude much. It has holes between the leaves and stuff like that.
GD: That’s the beauty of the screen/pixel space approach. There’s a word for it.
TS: Occluder fusion. When you have millions of trees, there’s bound to be occluder fusion, and there’s some barrier beyond which you can’t see anyways, and it’s easy to find when you just do front-to-back rendering and do occlusion queries against the rendered geometry.
GD: It also occurred to me that the floating point issue..the depth buffer may only be single precision, but the fact that it scales nonlinearly means you’re going to get better resolution on occlusion for objects that are nearby, that are important, so again using the hardware depth buffer for occlusion queries its not hugely important that you have double-precision in your occlusion test.
TS: No, it isn’t. Basically, we render bounding boxes for the occlusion tests, and they’re really crude models anyway. The customers that are using umbra currently….we have loads of MMO games and we have first person shooter games. The released customers would be, for example, Age of Conan. This is using our technology. Lord of the Rings Online uses our technology. And so forth.
One of the big issues the artists are facing when doing big worlds, they have to hand-make occluders…you’ve seen World of Warcraft. It has these windy corridors, they actually load the city in when you are walking, and you can’t see the city from the outside. You don’t have to do that. Whatever hole is in the wall you want to see through. And you could use portals for this, but using umbra to render front-to-back and do occlusion queries against geometry.
GD: Portals add recursion in your render pipeline, and it complicates the engine.
TS: It complicates everything. On Big World we did an integration where you can actually use, for example, reflecting surfaces. You have a lake, and you can have different occlusion in the lake scene than from the player’s view. You might have a rock in front of the reflecting surface, and of course the rock occludes stuff from the reflection. It doesn’t necessarily occlude stuff from the other view, but it occludes stuff from the reflection. So we can handle that also.
In that city scene, I’ve been just copy and pasting objects around. No preprocessing is needed, and that’s making the content pipeline much faster. Artists have been really praising us for that. We didn’t think about that until we got the feedback, “it’s so cool that we don’t have to do the manual work!”
GD: That’s all important these days with the cost of content rising. Its all about tools.
TS: The whole philosophy of making games is not actually making technology, its making content.
GD: There’s still a lot of reinvention of technology, and that’s got to settle.
TS: There’s, for example, Unreal is famous for their content pipeline. They have pretty good content tools. You should be able to just buy the technology and be done with it, and then you should have artists and game designers and people who are involved with the game play doing stuff. But if they have to have prior knowledge of the technology, for example, “ok, I have my budget and cannot show anything that lies beyond 100 meters,” you always have technology limitations. At umbra, we’re always trying to push the technology limitations. We’ve actually been able to free one dimension in the limitation of content creation, and that’s what artists have been really happy about.
GD: Can you tell me what your licensing model is?
TS: We’ve been integrated into Big World’s engine, we have integration with Hero Engine, with Gamebryo. We’re an Epic IPP, so we’re integrated into Epic’s engine. And of course the proprietary engines on top of that. Basically, we’re integrated into most of the big engines.
Our deals vary depending on what platforms you use, but our basic deal is per platform, per title. And then we have support deals. The quite common deal is a three year support cycle for a couple of platforms. It’s quite common for studios to develop a title for Windows and Xbox, or the three major consoles.
GD: Do you have any options for independent developers or for non-commercial use?
TS: Yeah, we’re working on it currently. We’ve been really busy releasing and optimizing our current product. In a half a year’s time, we’re trying to come up with a freeware solution of umbra that would do only view frustum culling. But it would benefit from the hierarchical structure, so it would be better than your average view frustum culling. And we’re trying to come up with a model for independent, small-money developers.
GD: Your traditional cost model is royalty free?
TS: Yeah, yeah. And we’re thinking about options for independents and small developers who would give us royalties after the deal. Or, some deals with limited support. We’re thinking about, and we’re having a meeting at Lake Tahoe after GDC.
GD: Nice place for a meeting!
TS: Yeah, cause we’re from Finland. When we come here we want to enjoy something else also, from, like, seller booths!
GD: I understand. If I visited Finland, I’d want to find some nice area there to visit!
TS: We’ve been standing in this basement with no windows for a couple of days now, so it’s nice to get outside after this!
GD: Maybe you missed the rainy day!
TS: We actually arrived on Saturday already, so we’ve been setting up our stuff and fine-tuning our demos in the hotel rooms. We’re a small company, so we have limited resources of course.
GD: Its hard to fit a large monitor on the little table they give you in the hotel room!
TS: We actually rented a television and put it on top. We had two consoles on the floor, laptops all over the place, wiring everywhere!
GD: This was good. It was good to see your technology, and to learn that you have tentative plans to support indies and hobbyists. Gamedev visitors will be happy to hear this.
TS: Of course we want to be involved in the lower-end development, small independent development studies. Because we’re a small company, we don’t necessarily have the resources for that part. We have plans for it, and we’re going forward with it.
GD: The cool thing is, once you release it to the independent community, all of a sudden, somebody is going to integrate umbra with Ogre, or OpenSceneGraph, or open source game engines.
TS: Some of the independent games are going to be huge success anyway.
We’re already researching technology on imposters, for the case where you have huge visibility but no occlusion. When we have the time, we’ll launch into that.
Southwest Gaming Expo
