Archived

This topic is now archived and is closed to further replies.

Monder

Unreal and Quake engines

Recommended Posts

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?

Share this post


Link to post
Share on other sites
At least with the Quake engine, it has nothing to do with the space partitioning. The CSG map (map built with blocks) is compiled using a special tool into a BSP-partitioned world that the engine can load and use.
There might be something like this going on for Unreal engine too... This would mean that carving / adding is simply the way the map editor programmers wanted their application to be.

ToohrVyk
-------------
Extatica - a free 3d game engine
Available soon!
Click here to learn more

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Carving out of solid space and adding stuff to a room is ultimately the same thing.

When the room has been created by inserting a box or cutting one out of solid is meaningless as the player sees walls either way. It all comes down to putting objects in that room.

There is a mathematical leakage reason for it which nobody understands.

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

Share this post


Link to post
Share on other sites
quote:
Original post by Monder
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?


I think the reason the unreal map-making program uses the carving idea is because its impossible to have ''leaks'' when carving. A leak is when you don''t close a section off(like two walls don''t touch perfectly) so its possible to get outside the world. If the hole is big enough, players might fall outside the map and get stuck, but even if its really small it prevents the PVS system from optimizing the visibility information stored in the map file.
The map can run SIGNIFICANTLY slower if you don''t properly close the map using a ''build out of the void'' method, but its much more difficult to accidentally cause such a problem in the ''carve out of a solid world'' method.

----------
Almost typo-ified using Extrarius'' AUTOMATIC Typo Generator, but I decided to be nice =-)

Share this post


Link to post
Share on other sites
Additionally preference of the users may have something to do with it(at least partially) , I found the cookie cutter method less intuitive early on than the create faces method, but after becoming familiar with the cookie cutter i found it was easier to use and in worldcraft making verticies of different faces match was a pain (leak issues mentioned in above post). I'm not sure between the Q3A vs UrealED, but from my experience comes from using Worldcraft vs. RED (redfaction level editor).

[edited by - _walrus on March 3, 2003 4:47:23 PM]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
unreal is bugfree.. you can''t "falloff" an unreal level. (though, the editor is not bugfree, so you _can_ build holes)

unreal makes much more sense. a level should never go into infinity => digging out the level of solid makes more sense

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
quote:
Original post by billybob
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)


when compiling the level, extra faces are removed. so the end result would be the same as "carving" like in unreal. as long as there is no leaking like they said.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i think the quake method is far better becouse:

- you can have infinite levels (if you want to, you probobly don''t but it may sometimes be usefull)
- more intuitive for artists (his can be argued as it is subjective)
- simpler to code
- the brushes, that cut empty out of solid in unreal intersect with each other, making it harder to see what is really going on with the map''s geometry
- quake''s method allows modeling efforts to be seen in real-time while modeling, when cuting out of solid methid needs compiling the map to allow rendering
- quake methos produces mode polygons while editing, but the out-side hull can be easly optimized out of existance, so this is not a problem
- leaks, yes this is a problem, but is quite easy to find them and remove

when i summarise cons and pros i find quake''s method more flexible, more intuitive, faster to work with, easier to implement, and more powerfull for editing as you can have imiediate camera view on what is going on

Share this post


Link to post
Share on other sites
none of these methods are good

quake:
portal rendereres are outdated
computing a portal`s visibility is a wast of time frustrumculling with octrees brings the same performance as portal engines did in the past

use vertex array range extension :D

unreal: they use the anti portal method for in-door areas and octrees for out-doors

anti-portals are convex brushes placed by the mapper i think although i am not sure but antiportals are a nice and speedy solution if they work the way i think they do



none of these mapping ways is comfortable because it take a damn long time until you have finished a map

i wish there would exist an editor which does 3d studio max like meshes and would texture them just like the quake editors

using this as a base and render it with quad/octrees and you are fine

Share this post


Link to post
Share on other sites
Unreal''s method is far more intuitive for a portal engine. With the Quake technique, you need some special way to determine sectors and their boundaries; with the "carving out" technique, the map is built explicitly but intuitively from sectors. To determine portals, all you have to do is find common faces of different sectors and then clip them to each other. Viola: Portals.

For a simple engine that culls using a PVS, like Quake, it doesn''t matter as much. You can get tons of little sectors from BSP partitioning to determine the "empty polyhedra" of the level, or premade ones from the "carved out" technique; it doesn''t matter all that much.

Also, one comment for Basiror: The Quake engines were not portal engines. You will run across the word "portal" in reference to them, but these "portals" are used exclusively for determining PVS of a sector at map compile time. In-game, portals do not exist for all practical purposes.

Also to Basiror, another comment: Brute-force rendering with a simple space-partitioning scheme like octrees may be acceptable for simple scenes on today''s hardware, but it doesn''t solve the problem of either coarse or fine occlusion culling. Clipping frustra to portals solves the the occlusion problem. Precomputing a PVS solves the occlusion problem. But throwing everything at the z-buffer does NOT solve the problem satisfactorally for anything but simple scenes, because you''re still sending everything to the card, and AGP remains a major bottleneck. VAR may speed it up, but it''s still just brute force. Also, right now, comparing octrees to portals is an apples and oranges argument: One is a spacial partitioning scheme and the other is a coarse occlusion culling scheme.

Also to the last Anonymous Poster: nothing prevents you from having infinite levels with a "carving out" approach. In real life, a block of marble or whatever may have a finite size, but in a game, your world doesn''t need to (beyond the maximum values that your data types can hold), because really all it comes down to is what direction the normals of your polyhedra are facing - in or out. Quake-style brushes with outward-pointing normals may be more intuitive to artists, but I would argue that they are NOT easier to code, because finding portals is much easier when, by carving out, designers define sectors themselves. See the first paragraph!

Share this post


Link to post
Share on other sites