Mapping for the Unreal engine and Quake engine is very different. In Unreal your meant to think of carving everything out of an infinite block and in Quake your meant to think of adding everything to an empty void. I was wondering why is this? Is it something to do with their space partitioning techniques?

Talking about Unreal Engine:
I was wondering what Space Partitioning Algorithms they use. I now Quake uses BSPs, but what about Unreal? Does it use BSPs too, or Octrees or whatever else exists. Just curious about that. I have no intent on rewriting Unreal or whatsoever.

Thanks for the replies guys. I thought it was probably just the way the map editors work it''s just every map editing website I''ve read about it on(well many) talks about positive and negative space engines so I though there may actaully be a difference in the way the handle the map drawing stuff

In response to the comment made by walkingcarcass: "There is a mathematical leakage reason for it which nobody understands." ...

The whole idea is to partition the world into "solid space" and "empty space". So any surfaces that can be seen are facing "empty space". You must never have any geometry in which the visible side is facing solid space.

To illustrate what that means, picture a cube, for example. You know intuitively that each quadrilateral faces away from the center of the cube. That is, each quad is facing empty space, and the volume inside the cube is considered solid space. You never want to have geometry protruding solid space. If you did have this situation occuring in your 3D modelling application, you would need to do some boolean operations to cut out, or remove, the intersecting geometry.

Now why would you put these restrictions on the geometry? Well, the BSP compiler uses the knowledge that everything is either in solid space and empty space to build a list called a possible visibility set (PVS).

The way this works is as follows. The BSP compiler first creates a all of the portals. Think of these as invisible windows that plug up the doorways between concave hulls. When this step is done, you will now have rooms, or pockets of meshes that are all separated by these portals.

Next, the compiler generates a list called the possible visibility set (PVS) for each of these rooms (or brushes if you will). So when the camera is inside any node, you will already know what nodes are possibly visible from that node, and only bother to process and render those brushes. As you can imagine, this greatly reduces the amount of geometry the game engine needs to deal with on a per frame basis. This is why your first person shooters can render the maps so fast - they are not trying to render everything, just a small subset of it.

Thats just an oversimplified idea of what is going on here.

But just to summarize, your world geometry should always be completely separated into solid space and empty space. If any solid geometry is intersecting, perform boolean operations to subtract the overlapping portion of the geometry, and make sure the rest is welded together to become a single solid mesh. If you keep this in mind when you are modelling, all should work well.

The beauty of those game world editors such as UnrealEd, Q3Radiant, etc. is that they are designed to make sure you are building worlds that follow this concept of solid / empty space. Doing the work yourself in traditional modelling tools like 3ds max and Maya put the onus on the artist to keep things straight. These tools will save you time, and probably alot of frustration.


Terry Sznober
http://www.terrysznober.com

unreal''s is probably simpler to make, even though it SEEMS harder. its also probably faster because for one room, you have 6 polygons, but in quake you have 6 * 6, because each wall is really a block by itself (simple blocks, not complex intersections if it can do that)