원본 사이트 : http://www.bluesnews.com/abrash/contents.shtml

Consider the Alternatives:? Quake’s Hidden-Surface Removal

by Michael Abrash

Okay, I admit it:? I’m sick and tired of classic rock.? Admittedly, it’s been a while--about 20 years--since last I was excited to hear anything by the Cars or Boston, and I was never particularly excited in the first place about Bob Seger or Queen--to say nothing of Elvis--so some things haven’t changed.? But I knew something was up when I found myself changing the station on the Allman Brothers and Steely Dan and Pink Floyd and, God help me, the Beatles (just stuff like “Hello Goodbye” and “I’ll Cry Instead,” though, not “Ticket to Ride” or “A Day in the Life”; I’m not that far gone).? It didn’t take long to figure out what the problem was; I’d been hearing the same songs for a quarter-century, and I was bored.

I tell you this by way of explaining why it was that when my daughter and I drove back from dinner the other night, the radio in my car was tuned, for the first time ever, to a station whose slogan is “There is no alternative.”

Now, we’re talking here about a ten-year-old who worships the Beatles and has been raised on a steady diet of oldies.? She loves melodies, catchy songs, and good singers, none of which you’re likely to find on an alternative rock station.? So it’s no surprise that when I turned on the radio, the first word out of her mouth was “Yuck!”

What did surprise me was that after listening for a while, she said, “You know, Dad, it’s actually kind of interesting.”

Apart from giving me a clue as to what sort of music I can expect to hear blasting through our house when she’s a teenager, her quick uptake on alternative rock (versus my decades-long devotion to the music of my youth) reminded me of something that it’s easy to forget as we become older and more set in our ways.? It reminded me that it’s essential to keep an open mind, and to be willing--better yet, eager--to try new things.? Programmers tend to become attached to familiar approaches, and are inclined to stick with whatever is currently doing the job adequately well, but in programming there are always alternatives, and I’ve found that they’re often worth considering.

Not that I should have needed any reminding, considering the ever-evolving nature of Quake.

Creative flux

Back in January, I described the creative flux that led to John Carmack’s decision to use a precalculated potentially visible set (PVS) of polygons for each possible viewpoint in Quake, the game we’re developing at id Software.? The precalculated PVS meant that instead of having to spend a lot of time searching through the world database to find out which polygons were visible from the current viewpoint, we could simply draw all the polygons in the PVS from back to front (getting the ordering courtesy of the world BSP tree; check out the May, July, and November 1995 columns for a discussion of BSP trees), and get the correct scene drawn with no searching at all, letting the back-to-front drawing perform the final stage of hidden-surface removal (HSR).? This was a terrific idea, but it was far from the end of the road for Quake’s design.

Drawing moving objects

For one thing, there was still the question of how to sort and draw moving objects properly; in fact, this is the question I’ve been asked most often since the January column came out, so I’ll take a moment to address it.? The primary problem is that a moving model can span multiple BSP leaves, with the leaves that are touched varying as the model moves; that, together with the possibility of multiple models in one leaf, means there’s no easy way to use BSP order to draw the models in correctly sorted order.? When I wrote the January column, we were drawing sprites (such as explosions), moveable BSP models (such as doors), and polygon models (such as monsters) by clipping each into all the leaves it touched, then drawing the appropriate parts as each BSP leaf was reached in back-to-front traversal.? However, this didn’t solve the issue of sorting multiple moving models in a single leaf against each other, and also left some ugly sorting problems with complex polygon models.

John solved the sorting issue for sprites and polygon models in a startlingly low-tech way:? We now z-buffer them.? (That is, before we draw each pixel, we compare its distance, or z, value with the z value of the pixel currently on the screen, drawing only if the new pixel is nearer than the current one.)? First, we draw the basic world--walls, ceilings, and the like.? No z-buffer testing is involved at this point (the world visible surface determination is done in a different way, as we’ll see soon); however, we do fill the z-buffer with the z values (actually, 1/z values, as discussed below) for all the world pixels.? Z-filling is a much faster process than z-buffering the entire world would be, because no reads or compares are involved, just writes of z values.? Once drawing and z-filling the world is done, we can simply draw the sprites and polygon models with z-buffering and get perfect sorting all around.

Whenever a z-buffer is involved, the questions inevitably are:? What’s the memory footprint, and what’s the performance impact?? Well, the memory footprint at 320x200 is 128K, not trivial but not a big deal for a game that

equires 8 Mb.? The performance impact is about 10% for z-filling the world, and roughly 20% (with lots of variation) for drawing sprites and polygon models.? In return, we get a perfectly sorted world, and also the ability to do additional effects, such as particle explosions and smoke, because the z-buffer lets us flawlessly sort such effects into the world.? All in all, the use of the z-buffer vastly improved the visual quality and flexibility of the Quake engine, and also simplified the code quite a bit, at an acceptable memory and performance cost.

Leveling and improving performance

As I said above, in the Quake architecture, the world itself is drawn first--without z-buffer reads or compares, but filling the z-buffer with the world polygons’ z values--and then the moving objects are drawn atop the world, using full z-buffering.? Thus far, I’ve discussed how to draw moving objects.? For the rest of this column, I’m going to talk about the other part of the drawing equation, how to draw the world itself, where the entire world is stored as a single BSP tree and never moves.

As you may recall from the January column, we’re concerned with both raw performance and level performance.? That is, we want the drawing code to run as fast as possible, but we also want the difference in drawing speed between the average scene and the slowest-drawing scene to be as small as possible.? It does little good to average 30 frames per second if 10% of the scenes draw at 5 fps, because the jerkiness in those scenes will be extremely obvious by comparison with the average scene, and highly objectionable.? It would be better to average 15 fps 100% of the time, even though the average drawing speed is only half as much.

The precalculated PVS was an important step toward both faster and more level performance, because it eliminated the need to identify visible polygons, a relatively slow step that tended to be at its worst in the most complex scenes.? Nonetheless, in some spots in real game levels the precalculated PVS contains five times more polygons than are actually visible; together with the back-to-front HSR approach, this created hot spots in which the frame rate bogged down visibly as hundreds of polygons are drawn back to front, most of those immediately getting overdrawn by nearer polygons.? Raw performance in general was also reduced by the typical 50% overdraw resulting from drawing everything in the PVS.? So, although drawing the PVS back to front as the final HSR stage worked and was an improvement over previous designs, it was not ideal.? Surely, John thought, there’s a better way to leverage the PVS than back-to-front drawing.

And indeed there is.

Sorted spans

The ideal final HSR stage for Quake would reject all the polygons in the PVS that are actually invisible, and draw only the visible pixels of the remaining polygons, with no overdraw--that is, with every pixel drawn exactly once--all at no performance cost, of course.? One way to do that (although certainly not at zero cost) would be to draw the polygons from front to back, maintaining a region describing the currently occluded portions of the screen and clipping each polygon to that region before drawing it.? That sounds promising, but it is in fact nothing more or less than the beam tree approach I described in the January column, an approach that we found to have considerable overhead and serious leveling problems.

We can do much better if we move the final HSR stage from the polygon level to the span level and use a sorted-spans approach.? In essence, this approach consists of turning each polygon into a set of spans, as shown in Figure 1, and then sorting and clipping the spans against each other until only the visible portions of visible spans are left to be drawn, as shown in Figure 2.? This may sound a lot like z-buffering (which is simply too slow for use in drawing the world, although it’s fine for smaller moving objects, as described earlier), but there are crucial differences.? By contrast with z-buffering, only visible portions of visible spans are scanned out pixel by pixel (although all polygon edges must still be rasterized).? Better yet, the sorting that z-buffering does at each pixel becomes a per-span operation with sorted spans, and because of the coherence implicit in a span list, each edge is sorted against only against some of the spans on the same line, and clipped only to the few spans that it overlaps horizontally.? Although complex scenes still take longer to process than simple scenes, the worst case isn’t as bad as with the beam tree or back-to-front approaches, because there’s no overdraw or scanning of hidden pixels, because complexity is limited to pixel resolution, and because span coherence tends to limit the worst-case sorting in any one area of the screen.? As a bonus, the output of sorted spans is in precisely the form that a low-level rasterizer needs, a set of span descriptors, each consisting of a start coordinate and a length.

Figure 1: Span generation.

In short, the sorted spans approach meets our original criteria pretty well; although it isn’t zero-cost, it’s not horribly expensive, it completely eliminates both overdraw and pixel scanning of obscured portions of polygons, and it tends to level worst-case performance.? We wouldn’t want to rely on sorted spans alone as our hidden-surface mechanism, but the precalculated PVS reduces the number of polygons to a level that sorted spans can handle quite nicely.

So we’ve found the approach we need; now it’s just a matter of writing some code and we’re on our way, right?? Well, yes and no.? Conceptually, the sorted-spans approach is simple, but it’s surprisingly difficult to implement, with a couple of major design choices to be made, a subtle mathematical element, and some tricky gotchas that we’ll see in the next column.? Let’s look at the design choices first.

Edges versus spans

The first design choice is whether to sort spans or edges (both of which fall into the general category of “sorted spans”).? Although the results are the same both ways--a list of spans to be drawn, with no overdraw--the implementations and performance implications are quite different, because the sorting and clipping are performed using very different data structures.

With span-sorting, spans are stored in x-sorted linked list buckets, typically with one bucket per scan line.? Each polygon in turn is rasterized into spans, as shown in Figure 1, and each span is sorted and clipped into the bucket for the scan line the span is on, as shown in Figure 2, so that at any time each bucket contains the nearest spans encountered thus far, always with no overlap.? This approach involves generating all spans for each polygon in turn, with each span immediately being sorted, clipped, and added to the appropriate bucket.

Figure 2: The spans from polygon A from Figure 1 sorted and clipped with the spans from polygon B, where polygon A is at a constant z distance of 100 and polygon B is at a constant z distance of 50 (polygon B is closer).


With edge-sorting, edges are stored in x-sorted linked list buckets according to their start scan line.? Each polygon in turn is decomposed into edges, cumulatively building a list of all the edges in the scene.? Once all edges for all polygons in the view frustum have been added to the edge list, the whole list is scanned out in a single top-to-bottom, left-to-right pass.? An active edge list (AEL) is maintained.? With each step to a new scan line, edges that end on that scan line are removed from the AEL, active edges are stepped to their new x coordinates, edges starting on the new scan line are added to the AEL, and the edges are sorted by current x coordinate.

For each scan line, a z-sorted active polygon list (APL) is maintained.? The x-sorted AEL is stepped through in order.? As each new edge is encountered (that is, as each polygon starts or ends as we move left to right), the associated polygon is activated and sorted into the APL, as shown in Figure 3, or deactivated and removed from the APL, as shown in Figure 4, for a leading or trailing edge, respectively.? If the nearest polygon has changed (that is, if the new polygon is nearest, or if the nearest polygon just ended), a span is emitted for the polygon that just stopped being the nearest, starting at the point where the polygon first because nearest and ending at the x coordinate of the current edge, and the current x coordinate is recorded in the polygon that is now the nearest.? This saved coordinate later serves as the start of the span emitted when the new nearest polygon ceases to be in front.

Figure 3: Activating a polygon when a leading edge is encountered in the AEL.

Figure 4: Deactivating a polygon when a trailing edge is encountered in the AEL.


Don’t worry if you didn’t follow all of that; the above is just a quick overview of edge-sorting to help make the rest of this column clearer.? There will a thorough discussion in the next column.

The spans that are generated with edge-sorting are exactly the same spans that ultimately emerge from span-sorting; the difference lies in the intermediate data structures that are used to sort the spans in the scene.? With edge-sorting, the spans are kept implicit in the edges until the final set of visible spans is generated, so the sorting, clipping, and span emission is done as each edge adds or removes a polygon, based on the span state implied by the edge and the set of active polygons.? With span-sorting, spans are immediately made explicit when each polygon is rasterized, and those intermediate spans are then sorted and clipped against other the spans on the scan line to generate the final spans, so the states of the spans are explicit at all times, and all work is done directly with spans.

Both span-sorting and edge-sorting work well, and both have been employed successfully in commercial projects.? We’ve chosen to use edge-sorting in Quake partly because it seems inherently more efficient, with excellent horizontal coherence that makes for minimal time spent sorting, in contrast with the potentially costly sorting into linked lists that span-sorting can involve.? A more important reason, though, is that with edge-sorting we’re able to share edges between adjacent polygons, and that cuts the work involved in sorting, clipping, and rasterizing edges nearly in half, while also shrinking the world database quite a bit due to the sharing.

One final advantage of edge-sorting is that it makes no distinction between convex and concave polygons.? That’s not an important consideration for most graphics engines, but in Quake, edge clipping, transformation, projection, and sorting has become a major bottleneck, so we’re doing everything we can to get the polygon and edge counts down, and concave polygons help a lot in that regard.? While it’s possible to handle concave polygons with span-sorting, that can involve significant performance penalties.

Nonetheless, there’s no cut-and-dried answer as to which approach is better.? In the end, span-sorting and edge-sorting amount to the same functionality, and the choice between them is a matter of whatever you feel most comfortable with.? In the next column, I’ll go into considerable detail about edge-sorting, complete with a full implementation.? I’m going the spend the rest of this column laying the foundation for next time by discussing sorting keys and 1/z calculation.? In the process, I’m going to have to make a few forward references to aspects of edge-sorting that I haven’t covered in detail; my apologies, but it’s unavoidable, and all should become clear by the end of the next column.

Edge-sorting keys

Now that we know we’re going to sort edges, using them to emit spans for the polygons nearest the viewer, the question becomes how we can tell which polygons are nearest.? Ideally, we’d just store a sorting key in each polygon, and whenever a new edge came along, we’d compare its surface’s key to the keys of other currently active polygons, and could easily tell which polygon was nearest.

That sounds too good to be true, but it is possible.? If, for example, your world database is stored as a BSP tree, with all polygons clipped into the BSP leaves, then BSP walk order is a valid drawing order.? So, for example, if you walk the BSP back to front, assigning each polygon an incrementally higher key as you reach it, polygons with higher keys are guaranteed to be in front of polygons with lower keys.? This is the approach Quake used for a while, although a different approach is now being used, for reasons I’ll explain shortly.

If you don’t happen to have a BSP or similar data structure handy, or if you have lots of moving polygons (BSPs don’t handle moving polygons very efficiently), another way to accomplish our objectives would be to sort all the polygons against one another before drawing the scene, assigning appropriate keys based on their spatial relationships in viewspace.? Unfortunately, this is generally an extremely slow task, because every polygon must be compared to every other polygon.? There are techniques to improve the performance of polygon sorts, but I don’t know of anyone who’s doing general polygon sorts of complex scenes in realtime on a PC.

An alternative is to sort by z distance from the viewer in screenspace, an approach that dovetails nicely with the excellent spatial coherence of edge-sorting.? As each new edge is encountered on a scan line, the corresponding polygon’s z distance can be calculated and compared to the other polygons’ distances, and the polygon can be sorted into the APL accordingly.

Getting z distances can be tricky, however.? Remember that we need to be able to calculate z at any arbitrary point on a polygon, because an edge may occur and cause its polygon to be sorted into the APL at any point on the screen.? We could calculate z directly from the screen x and y coordinates and the polygon’s plane equation, but unfortunately this can’t be done very quickly, because the z for a plane doesn’t vary linearly in screenspace; however, 1/z does vary linearly, so we’ll use that instead.? (See Chris Hecker’s series of columns on texture mapping over the past year in Game Developer magazine for a discussion of screenspace linearity and gradients for 1/z.)? Another advantage of using 1/z is that its resolution increases with decreasing distance, meaning that by using 1/z, we’ll have better depth resolution for nearby features, where it matters most.

The obvious way to get a 1/z value at any arbitrary point on a polygon is to calculate 1/z at the vertices, interpolate it down both edges of the polygon, and interpolate between the edges to get the value at the point of interest.? Unfortunately, that requires doing a lot of work along each edge, and worse, requires division to calculate the 1/z step per pixel across each span.

A better solution is to calculate 1/z directly from the plane equation and the screen x and y of the pixel of interest.? The equation is:

1/z = (a/d)x’ - (b/d)y’ + c/d

where z is the viewspace z coordinate of the point on the plane that projects to screen coordinate (x’,y’) (the origin for this calculation is the center of projection, the point on the screen straight ahead of the viewpoint), [a b c] is the plane normal in viewspace, and d is the distance from the viewspace origin to the plane along the normal.? Division is done only once per plane, because a, b, c, and d are per-plane constants.

The full 1/z calculation requires two multiplies and two adds, all of which should be floating-point to avoid range errors.? That much floating-point math sounds expensive but really isn’t, especially on a Pentium, where a plane’s 1/z value at any point can be calculated in as little as six cycles in assembly language.

For those who are interested, here’s a quick derivation of the 1/z equation.? The plane equation for a plane is

ax + by + cz - d = 0,

where x and y are viewspace coordinates, and a, b, c, d, and z are defined above.? If we substitute x=x’z and y=-y’z (from the definition of the perspective projection, with y inverted because y increases upward in viewspace but downward in screenspace), and do some rearrangement, we get

z = d / (ax’ - by’ + c).

Inverting and distributing yields

1/z = ax’/d - by’/d + c/d.

We’ll see 1/z sorting in action next time.

Quake and z-sorting

I mentioned above that Quake no longer uses BSP order as the sorting key; in fact, it uses 1/z as the key now.? Elegant as the gradients are, calculating 1/z from them is clearly slower than just doing a compare on a BSP-ordered key, so why have we switched Quake to 1/z?

The primary reason is to reduce the number of polygons.? Drawing in BSP order means following certain rules, including the rule that polygons must be split if they cross BSP planes.? This splitting increases the numbers of polygons and edges considerably.? By sorting on 1/z, we’re able to leave polygons unsplit but still get correct drawing order, so we have far fewer edges to process and faster drawing overall, despite the added cost of 1/z sorting.

Another advantage of 1/z sorting is that it solves the sorting issues I mentioned at the start involving moving models that are themselves small BSP trees.? Sorting in world BSP order wouldn’t work here, because these models are separate BSPs, and there’s no easy way to work them into the world BSP’s sequence order.? We don’t want to use z-buffering for these models because they’re often large objects such as doors, and we don’t want to lose the overdraw-reduction benefits that closed doors provide when drawn through the edge list.? With sorted spans, the edges of moving BSP models are simply placed in the edge list (first clipping polygons so they don’t cross any solid world surfaces, to avoid complications associated with interpenetration), along with all the world edges, and 1/z sorting takes care of the rest.

Onward to next time

There is, without a doubt, an awful lot of information in the preceding pages, and it may not all connect together yet in your mind.? The code and accompanying explanation next time should help; if you want to peek ahead, the code should be available from ftp.idsoftware.com/mikeab/ddjsort.zip by the time you read this column.? You may also want to take a look at Foley & van Dam’s Computer Graphics or Rogers’ Procedural Elements for Computer Graphics.

As I write this, it’s unclear whether Quake will end up sorting edges by BSP order or 1/z.? Actually, there’s no guarantee that sorted spans in any form will be the final design.? Sometimes it seems like we change graphics engines as often as they play Elvis on the ‘50s oldies stations (but, one would hope, with more aesthetically pleasing results!), and no doubt we’ll be considering the alternatives right up until the day we ship.
원본 사이트 : http://www.bluesnews.com/abrash/contents.shtml

Inside Quake: Visible-Surface Determination

by Michael Abrash

Years ago, I was working at Video Seven, a now-vanished video adapter manufacturer, helping to develop a VGA clone. The fellow who was designing Video Seven’s VGA chip, Tom Wilson, had worked around the clock for months to make his VGA run as fast as possible, and was confident he had pretty much maxed out its performance. As Tom was putting the finishing touches on his chip design, however, news came fourth-hand that a competitor, Paradise, had juiced up the performance of the clone they were developing, by putting in a FIFO.

That was it; there was no information about what sort of FIFO, or how much it helped, or anything else. Nonetheless, Tom, normally an affable, laid-back sort, took on the wide-awake, haunted look of a man with too much caffeine in him and no answers to show for it, as he tried to figure out, from hopelessly thin information, what Paradise had done. Finally, he concluded that Paradise must have put a write FIFO between the system bus and the VGA, so that when the CPU wrote to video memory, the write immediately went into the FIFO, allowing the CPU to keep on processing instead of stalling each time it wrote to display memory.

Tom couldn’t spare the gates or the time to do a full FIFO, but he could implement a one-deep FIFO, allowing the CPU to get one write ahead of the VGA. He wasn’t sure how well it would work, but it was all he could do, so he put it in and taped out the chip.

The one-deep FIFO turned out to work astonishingly well; for a time, Video Seven’s VGAs were the fastest around, a testament to Tom’s ingenuity and creativity under pressure. However, the truly remarkable part of this story is that Paradise’s FIFO design turned out to bear not the slightest resemblance to Tom’s, and didn’t work as well. Paradise had stuck a read FIFO between display memory and the video output stage of the VGA, allowing the video output to read ahead, so that when the CPU wanted to access display memory, pixels could come from the FIFO while the CPU was serviced immediately. That did indeed help performance--but not as much as Tom’s write FIFO.

What we have here is as neat a parable about the nature of creative design as one could hope to find. The scrap of news about Paradise’s chip contained almost no actual information, but it forced Tom to push past the limits he had unconsciously set in coming up with his original design. And, in the end, I think that the single most important element of great design, whether it be hardware or software or any creative endeavor, is precisely what the Paradise news triggered in Tom: The ability to detect the limits you have built into the way you think about your design, and transcend those limits.

The problem, of course, is how to go about transcending limits you don’t even know you’ve imposed. There’s no formula for success, but two principles can stand you in good stead: simplify, and keep on trying new things.

Generally, if you find your code getting more complex, you’re fine-tuning a frozen design, and it’s likely you can get more of a speed-up, with less code, by rethinking the design. A really good design should bring with it a moment of immense satisfaction in which everything falls into place, and you’re amazed at how little code is needed and how all the boundary cases just work properly.

As for how to rethink the design, do it by pursuing whatever ideas occur to you, no matter how off-the-wall they seem. Many of the truly brilliant design ideas I’ve heard over the years sounded like nonsense at first, because they didn’t fit my preconceived view of the world. Often, such ideas are in fact off-the-wall, but just as the news about Paradise’s chip sparked Tom’s imagination, aggressively pursuing seemingly-outlandish ideas can open up new design possibilities for you.

Case in point: The evolution of Quake’s 3-D graphics engine.

The toughest 3-D challenge of all

I’ve spent most of my waking hours for the last seven months working on Quake, id Software’s successor to DOOM, and after spending the next three months in much the same way, I expect Quake will be out as shareware around the time you read this.

In terms of graphics, Quake is to DOOM as DOOM was to its predecessor, Wolfenstein 3D. Quake adds true, arbitrary 3-D (you can look up and down, lean, and even fall on your side), detailed lighting and shadows, and 3-D monsters and players in place of DOOM’s sprites. Sometime soon, I’ll talk about how all that works, but this month I want to talk about what is, in my book, the toughest 3-D problem of all, visible surface determination (drawing the proper surface at each pixel), and its close relative, culling (discarding non-visible polygons as quickly as possible, a way of accelerating visible surface determination). In the interests of brevity, I’ll use the abbreviation VSD to mean both visible surface determination and culling from now on.

Why do I think VSD is the toughest 3-D challenge? Although rasterization issues such as texture mapping are fascinating and important, they are tasks of relatively finite scope, and are being moved into hardware as 3-D accelerators appear; also, they only scale with increases in screen resolution, which are relatively modest.

In contrast, VSD is an open-ended problem, and there are dozens of approaches currently in use. Even more significantly, the performance of VSD, done in an unsophisticated fashion, scales directly with scene complexity, which tends to increase as a square or cube function, so this very rapidly becomes the limiting factor in doing realistic worlds. I expect VSD increasingly to be the dominant issue in realtime PC 3-D over the next few years, as 3-D worlds become increasingly detailed. Already, a good-sized Quake level contains on the order of 10,000 polygons, about three times as many polygons as a comparable DOOM level.

The structure of Quake levels

Before diving into VSD, let me note that each Quake level is stored as a single huge 3-D BSP tree. This BSP tree, like any BSP, subdivides space, in this case along the planes of the polygons. However, unlike the BSP tree I presented last time, Quake’s BSP tree does not store polygons in the tree nodes, as part of the splitting planes, but rather in the empty (non-solid) leaves, as shown in overhead view in Figure 1.

Figure 1: In Quake, polygons are stored in the empty leaves. Shaded areas are solid leaves (solid volumes, such as the insides of walls).

Correct drawing order can be obtained by drawing the leaves in front-to-back or back-to-front BSP order, again as discussed last time. Also, because BSP leaves are always convex and the polygons are on the boundaries of the BSP leaves, facing inward, the polygons in a given leaf can never obscure one another and can be drawn in any order. (This is a general property of convex polyhedra.)

Culling and visible surface determination

The process of VSD would ideally work as follows. First, you would cull all polygons that are completely outside the view frustum (view pyramid), and would clip away the irrelevant portions of any polygons that are partially outside. Then you would draw only those pixels of each polygon that are actually visible from the current viewpoint, as shown in overhead view in Figure 2, wasting no time overdrawing pixels multiple times; note how little of the polygon set in Figure 2 actually need to be drawn. Finally, in a perfect world, the tests to figure out what parts of which polygons are visible would be free, and the processing time would be the same for all possible viewpoints, giving the game a smooth visual flow.

Figure 2: An ideal VSD architecture would draw only visible parts of visible polygons.


As it happens, it is easy to determine which polygons are outside the frustum or partially clipped, and it’s quite possible to figure out precisely which pixels need to be drawn. Alas, the world is far from perfect, and those tests are far from free, so the real trick is how to accelerate or skip various tests and still produce the desired result.

As I discussed at length last time, given a BSP, it’s easy and inexpensive to walk the world in front-to-back or back-to-front order. The simplest VSD solution, which I in fact demonstrated last time, is to simply walk the tree back-to-front, clip each polygon to the frustum, and draw it if it’s facing forward and not entirely clipped (the painter’s algorithm). Is that an adequate solution?

For relatively simple worlds, it is perfectly acceptable. It doesn’t scale very well, though. One problem is that as you add more polygons in the world, more transformations and tests have to be performed to cull polygons that aren’t visible; at some point, that will bog performance down considerably.

Happily, there’s a good workaround for this particular problem. As discussed earlier, each leaf of a BSP tree represents a convex subspace, with the nodes that bound the leaf delimiting the space. Perhaps less obvious is that each node in a BSP tree also describes a subspace--the subspace composed of all the node’s children, as shown in Figure 3. Another way of thinking of this is that each node splits into two pieces the subspace created by the nodes above it in the tree, and the node’s children then further carve that subspace into all the leaves that descend from the node.

Figure 3: Node E describes the shaded subspace, which contains leaves 5, 6, and 7, and node F.


Since a node’s subspace is bounded and convex, it is possible to test whether it is entirely outside the frustum. If it is, all of the node’s children are certain to be fully clipped, and can be rejected without any additional processing. Since most of the world is typically outside the frustum, many of the polygons in the world can be culled almost for free, in huge, node-subspace chunks. It’s relatively expensive to perform a perfect test for subspace clipping, so instead bounding spheres or boxes are often maintained for each node, specifically for culling tests.

So culling to the frustum isn’t a problem, and the BSP can be used to draw back to front. What’s the problem?


The problem John Carmack, the driving technical force behind DOOM and Quake, faced when he designed Quake was that in a complex world, many scenes have an awful lot of polygons in the frustum. Most of those polygons are partially or entirely obscured by other polygons, but the painter’s algorithm described above requires that every pixel of every polygon in the frustum be drawn, often only to be overdrawn. In a 10,000-polygon Quake level, it would be easy to get a worst-case overdraw level of 10 times or more; that is, in some frames each pixel could be drawn 10 times or more, on average. No rasterizer is fast enough to compensate for an order of magnitude more work than is actually necessary to show a scene; worse still, the painter’s algorithm will cause a vast difference between best-case and worst-case performance, so the frame rate can vary wildly as the viewer moves around.

So the problem John faced was how to keep overdraw down to a manageable level, preferably drawing each pixel exactly once, but certainly no more than two or three times in the worst case. As with frustum culling, it would be ideal if he could eliminate all invisible polygons in the frustum with virtually no work. It would also be a plus if he could manage to draw only the visible parts of partially-visible polygons, but that was a balancing act, in that it had to be a lower-cost operation than the overdraw that would otherwise result.

When I arrived at id at the beginning of March, John already had an engine prototyped and a plan in mind, and I assumed that our work was a simple matter of finishing and optimizing that engine. If I had been aware of id’s history, however, I would have known better. John had done not only DOOM, but also the engines for Wolf 3D and several earlier games, and had actually done several different versions of each engine in the course of development (once doing four engines in four weeks), for a total of perhaps 20 distinct engines over a four-year period. John’s tireless pursuit of new and better designs for Quake’s engine, from every angle he could think of, would end only when we shipped.

By three months after I arrived, only one element of the original VSD design was anywhere in sight, and John had taken “try new things” farther than I’d ever seen it taken.

The beam tree

John’s original Quake design was to draw front to back, using a second BSP tree to keep track of what parts of the screen were already drawn and which were still empty and therefore drawable by the remaining polygons. Logically, you can think of this BSP tree as being a 2-D region describing solid and empty areas of the screen, as shown in Figure 4, but in fact it is a 3-D tree, of the sort known as a beam tree. A beam tree is a collection of 3-D wedges (beams), bounded by planes, projecting out from some center point, in this case the viewpoint, as shown in Figure 5.

Figure 4: Quake's beam tree effectively partitioned the screen into 2-D regions.

Figure 5: Quake's beam tree was composed of 3-D wedges, or beams, projecting out from the viewpoint to polygon edges.


In John’s design, the beam tree started out consisting of a single beam describing the frustum; everything outside that beam was marked solid (so nothing would draw there), and the inside of the beam was marked empty. As each new polygon was reached while walking the world BSP tree front to back, that polygon was converted to a beam by running planes from its edges through the viewpoint, and any part of the beam that intersected empty beams in the beam tree was considered drawable and added to the beam tree as a solid beam. This continued until either there were no more polygons or the beam tree became entirely solid. Once the beam tree was completed, the visible portions of the polygons that had contributed to the beam tree were drawn.

The advantage to working with a 3-D beam tree, rather than a 2-D region, is that determining which side of a beam plane a polygon vertex is on involves only checking the sign of the dot product of the ray to the vertex and the plane normal, because all beam planes run through the origin (the viewpoint). Also, because a beam plane is completely described by a single normal, generating a beam from a polygon edge requires only a cross-product of the edge and a ray from the edge to the viewpoint. Finally, bounding spheres of BSP nodes can be used to do the aforementioned bulk culling to the frustum.

The early-out feature of the beam tree--stopping when the beam tree becomes solid--seems appealing, because it appears to cap worst-case performance. Unfortunately, there are still scenes where it’s possible to see all the way to the sky or the back wall of the world, so in the worst case, all polygons in the frustum will still have to be tested against the beam tree. Similar problems can arise from tiny cracks due to numeric precision limitations. Beam tree clipping is fairly time-consuming, and in scenes with long view distances, such as views across the top of a level, the total cost of beam processing slowed Quake’s frame rate to a crawl. So, in the end, the beam-tree approach proved to suffer from much the same malady as the painter’s algorithm: The worst case was much worse than the average case, and it didn’t scale well with increasing level complexity.

3-D engine du jour

Once the beam tree was working, John relentlessly worked at speeding up the 3-D engine, always trying to improve the design, rather than tweaking the implementation. At least once a week, and often every day, he would walk into my office and say “Last night I couldn’t get to sleep, so I was thinking...” and I’d know that I was about to get my mind stretched yet again. John tried many ways to improve the beam tree, with some success, but more interesting was the profusion of wildly different approaches that he generated, some of which were merely discussed, others of which were implemented in overnight or weekend-long bursts of coding, in both cases ultimately discarded or further evolved when they turned out not to meet the design criteria well enough. Here are some of those approaches, presented in minimal detail in the hopes that, like Tom Wilson with the Paradise FIFO, your imagination will be sparked.

Subdividing raycast: Rays are cast in an 8x8 screen-pixel grid; this is a highly efficient operation because the first intersection with a surface can be found by simply clipping the ray into the BSP tree, starting at the viewpoint, until a solid leaf is reached. If adjacent rays don’t hit the same surface, then a ray is cast halfway between, and so on until all adjacent rays either hit the same surface or are on adjacent pixels; then the block around each ray is drawn from the polygon that was hit. This scales very well, being limited by the number of pixels, with no overdraw. The problem is dropouts; it’s quite possible for small polygons to fall between rays and vanish.

Vertex-free surfaces: The world is represented by a set of surface planes. The polygons are implicit in the plane intersections, and are extracted from the planes as a final step before drawing. This makes for fast clipping and a very small data set (planes are far more compact than polygons), but it’s time-consuming to extract polygons from planes.

Draw-buffer: Like a z-buffer, but with 1 bit per pixel, indicating whether the pixel has been drawn yet. This eliminates overdraw, but at the cost of an inner-loop buffer test, extra writes and cache misses, and, worst of all, considerable complexity. Variations are testing the draw-buffer a byte at a time and completely skipping fully-occluded bytes, or branching off each draw-buffer byte to one of 256 unrolled inner loops for drawing 0-8 pixels, in the process possibly taking advantage of the ability of the x86 to do the perspective floating-point divide in parallel while 8 pixels are processed.

Span-based drawing: Polygons are rasterized into spans, which are added to a global span list and clipped against that list so that only the nearest span at each pixel remains. Little sorting is needed with front-to-back walking, because if there’s any overlap, the span already in the list is nearer. This eliminates overdraw, but at the cost of a lot of span arithmetic; also, every polygon still has to be turned into spans.

Portals: the holes where polygons are missing on surfaces are tracked, because it’s only through such portals that line-of-sight can extend. Drawing goes front-to-back, and when a portal is encountered, polygons and portals behind it are clipped to its limits, until no polygons or portals remain visible. Applied recursively, this allows drawing only the visible portions of visible polygons, but at the cost of a considerable amount of portal clipping.


In the end, John decided that the beam tree was a sort of second-order structure, reflecting information already implicitly contained in the world BSP tree, so he tackled the problem of extracting visibility information directly from the world BSP tree. He spent a week on this, as a byproduct devising a perfect DOOM (2-D) visibility architecture, whereby a single, linear walk of a DOOM BSP tree produces zero-overdraw 2-D visibility. Doing the same in 3-D turned out to be a much more complex problem, though, and by the end of the week John was frustrated by the increasing complexity and persistent glitches in the visibility code. Although the direct-BSP approach was getting closer to working, it was taking more and more tweaking, and a simple, clean design didn’t seem to be falling out. When I left work one Friday, John was preparing to try to get the direct-BSP approach working properly over the weekend.

When I came in on Monday, John had the look of a man who had broken through to the other side--and also the look of a man who hadn’t had much sleep. He had worked all weekend on the direct-BSP approach, and had gotten it working reasonably well, with insights into how to finish it off. At 3:30 AM Monday morning, as he lay in bed, thinking about portals, he thought of precalculating and storing in each leaf a list of all leaves visible from that leaf, and then at runtime just drawing the visible leaves back-to-front for whatever leaf the viewpoint happens to be in, ignoring all other leaves entirely.

Size was a concern; initially, a raw, uncompressed potentially visible set (PVS) was several megabytes in size. However, the PVS could be stored as a bit vector, with 1 bit per leaf, a structure that shrunk a great deal with simple zero-byte compression. Those steps, along with changing the BSP heuristic to generate fewer leaves (contrary to what I said a few months back, choosing as the next splitter the polygon that splits the fewest other polygons is clearly the best heuristic, based on the latest data) and sealing the outside of the levels so the BSPer can remove the outside surfaces, which can never be seen, eventually brought the PVS down to about 20 Kb for a good-size level.

In exchange for that 20 Kb, culling leaves outside the frustum is speeded up (because only leaves in the PVS are considered), and culling inside the frustum costs nothing more than a little overdraw (the PVS for a leaf includes all leaves visible from anywhere in the leaf, so some overdraw, typically on the order of 50% but ranging up to 150%, generally occurs). Better yet, precalculating the PVS results in a leveling of performance; worst case is no longer much worse than best case, because there’s no longer extra VSD processing--just more polygons and perhaps some extra overdraw--associated with complex scenes. The first time John showed me his working prototype, I went to the most complex scene I knew of, a place where the frame rate used to grind down into the single digits, and spun around smoothly, with no perceptible slowdown.

John says precalculating the PVS was a logical evolution of the approaches he had been considering, that there was no moment when he said “Eureka!”. Nonetheless, it was clearly a breakthrough to a brand-new, superior design, a design that, together with a still-in-development sorted-edge rasterizer that completely eliminates overdraw, comes remarkably close to meeting the “perfect-world” specifications we laid out at the start.

Simplify, and keep on trying new things

What does it all mean? Exactly what I said up front: Simplify, and keep trying new things. The precalculated PVS is simpler than any of the other schemes that had been considered (although precalculating the PVS is an interesting task that I’ll discuss another time). In fact, at runtime the precalculated PVS is just a constrained version of the painter’s algorithm. Does that mean it’s not particularly profound?

Not at all. All really great designs seem simple and even obvious--once they’ve been designed. But the process of getting there requires incredible persistence, and a willingness to try lots of different ideas until the right one falls into place, as happened here.

My friend Chris Hecker has a theory that all approaches work out to the same thing in the end, since they all reflect the same underlying state and functionality. In terms of underlying theory, I’ve found that to be true; whether you do perspective texture mapping with a divide or with incremental hyperbolic calculations, the numbers do exactly the same thing. When it comes to implementation, however, my experience is that simply time-shifting an approach, or matching hardware capabilities better, or caching can make an astonishing difference. My friend Terje Mathisen likes to say that “almost all programming can be viewed as an exercise in caching,” and that’s exactly what John did. No matter how fast he made his VSD calculations, they could never be as fast as precalculating and looking up the visibility, and his most inspired move was to yank himself out of the “faster code” mindset and realize that it was in fact possible to precalculate (in effect, cache) and look up the PVS.

The hardest thing in the world is to step outside a familiar, pretty good solution to a difficult problem and look for a different, better solution. The best ways I know to do that are to keep trying new, wacky things, and always, always, always try to simplify. One of John’s goals is to have fewer lines of code in each 3-D game than in the previous game, on the assumption that as he learns more, he should be able to do things better with less code.

So far, it seems to have worked out pretty well for him.

Learn now, pay forward

There’s one other thing I’d like to mention before I close up shop for this month. As far back as I can remember, DDJ has epitomized the attitude that sharing programming information is A Good Thing. I know a lot of programmers who were able to leap ahead in their development because of Hendrix’s Tiny C, or Stevens’ D-Flat, or simply by browsing through DDJ’s annual collections. (Me, for one.) Most companies understandably view sharing information in a very different way, as potential profit lost--but that’s what makes DDJ so valuable to the programming community.

It is in that spirit that id Software is allowing me to describe in these pages how Quake works, even before Quake has shipped. That’s also why id has placed the full source code for Wolfenstein 3D on ftp.idsoftware.com/idstuff/source; you can’t just recompile the code and sell it, but you can learn how a full-blown, successful game works; check wolfsrc.txt in the above-mentioned directory for details on how the code may be used.

So remember, when it’s legally possible, sharing information benefits us all in the long run. You can pay forward the debt for the information you gain here and elsewhere by sharing what you know whenever you can, by writing an article or book or posting on the Net. None of us learns in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!


Foley, James D., et al., Computer Graphics: Principles and Practice, Addison Wesley, 1990, ISBN 0-201-12110-7 (beams, BSP trees, VSD).

Teller, Seth, Visibility Computations in Densely Occluded Polyhedral Environments (dissertation), available on


along with several other papers relevant to visibility determination.

Teller, Seth, Visibility Preprocessing for Interactive Walkthroughs, SIGGRAPH 91 proceedings, pp. 61-69.

관능적인 몸매와 남자건 여자건 시종일관 애교 섞인 말로 플레이어를 농락하며 압도적인 차이로 제압하려는게 `devCAT`의 의도였건만 오히려 유저들에게 농락 당하며 카운터를 맞으면 옷이 하나씩  벗겨지는 비운의 보스 캐릭터 `서큐버스`

지금부터 필자는 마비노기에서 비운의 NPC가 되어버린 `서큐버스`의 진짜 모습을 설명 해주겠다. 이 글을 읽기전에 심장이 약하거나 임산부, 노약자 그리고 미성년자는 조용히 Alt + F4를 누르시기 바란다.

씰온라인의 서큐버스 (대사는 역시 비슷하다)

인큐버스, 서큐버스(incubus, succubus)

`인큐버스`와 `서큐버스`는 일반적으로 ′몽마(나이트메어)′라고 불리며, 인간을 타락 시키는 악마의 일종이다.

`인큐버스`는 남성의 모습을 하고 있으며, `서큐버스`는 여성의 모습으로 나타난다. 일설에 의하면 인간 여성에 대한 관능적인 욕구가 지나쳐서 타락한 천사라고하며 다른 설에 따르면 `서큐버스`는 ′숲의 님프′라고 한다. `인큐버스`는 라틴어의 ′incubo(위에서 자다,올라타다)′라는 낱말에서 유래된 이름이다. 마찬가지로 서큐버스는 ′succubo(밑에서 자다,아래에 눕다)′라는 단어에서 유래되었다.

`인큐버스`는 인간 여성을 꾀어서 거시기~(에잇 알려고 하지말자!)를 하는 것, 혹은 타락 시킬 목적으로 이 세상에 모습을 드러낸다. 그 방법은 다양하여 아름다운 젊은이의 모습으로 변하여 여성을 유혹해서 목적을 달성하는 경우도 있고, 밤중에 자고 있는 여성의 잠자리에 숨어 들어가서 음란한 꿈을 보이거나 꼼짝하지 못하도록 올라타기도 해서 상대방이 알아차리지 못하는 사이에 목적을 달성하는 방법을 쓰는 경우도 있다.

`인큐버스`는 남자 어른의 모습을 취하는 경우 외에도 `사티로스`의 모습으로 나타나는 수도 있고, 마녀로 불리는 자들 앞에서는 `음탕한 산양의 모습`을 취하는 경우도 있으며, 때로는 `여성의 모습`으로 변신하는 경우도 있다.

`인큐버스`와 `서큐버스`는 기본적으로 같은 존재이지만, 남성의 모습을 하고 있는 것이 `인큐버스`이고 여성의 모습을 하고 있는 것이 `서큐버스`라는 설도 있다.

인큐버스와 서큐버스

`서큐버스`는 `인큐버스`와는 반대로 인간 남성을 유혹해서 거시기(흠 자막처리)하고 타락시킬 목적을 가지고 있다. 인간의 남성과 거시기~ (또나왔어 버럭!)할 때 상대방의 삐리리리~(오 주여;; 내가 이걸 왜 알려준다 했던가....)을 얻는데, `인큐버스`가 그 삐리리~~(갈수록 태산이군)을 사용해서 인간 여성을 임신시킨다고 한다. 이 일에 대해서 `토마스 아퀴나스`는, 그런 결과로 태어난 아이의 아버지는 어머니인 여성과 거시기~(이제그만 ㅜㅜ)한 `인큐버스`가 아니라 삐리리~( 오 주여;;)을 서큐버스에게 빼앗긴 남성이라고 결론을 내렸다.

또한 `인큐버스`와 `서큐버스`는 `마녀`나 `마법사`의 조수로 일하는 경우도 있다. 일설에 따르면 가장 저급한 악마만이 `인큐버스`가 되어 일한다고 한다. `인큐버스`와 `서큐버스`는 마을이나 도시 등 사람이 사는 장소, 혹은 그 주변에 출몰한다.

그리고 유혹할 상대를 한번 정하면 상대방이 죽거나 자신이 그 상대에게 질리거나, 또는 효력이 있는 수단으로 쫓겨날 때까지 상대방을 물고 늘어진다. 때로는 마녀들의 집회와 같은 장소에 나타나서 그 자리에 있는 마녀들과 어울리기도 한다.

`인큐버스`나 `서큐버스`에게 대항하기 위해서는 교회의 힘, 특히 주술과 기도의 힘이 효과적이라고 믿어지는데, 그 힘을 가지고도 겨우 그들을 쫓아낼 수 있을 뿐이지 완전히 퇴치할 수는 없는 모양이다.

가장 효력이 있는 것은 이들이 들러붙은 사람 본인의 신앙심과 도덕심, 그리고 정신력일 것이다. 설령 `인큐버스`를 쫓아내는데 성공했다고 하더라도 `인큐버스`는 다시 다른 상대를 발견해서 들러붙거나 자칫 잘못하면 다시 한 번 원래의 상대에게 돌아와서 붙을 수도 있으므로 마음을 놓을 수 없는 일이다.

괴테의 <파우스트>에서 4대 (정령)의 주문 중 "가사를 돕는데 힘을 다해라 인쿠브스 인쿠브스 "라는 말이 나오는데 여기서 나오는 인쿠브스(인큐버스)는 땅의 정령인 `코볼트`(코볼드)와 같은 의미를 가지는 것으로 간주된다.


야릇한 생각 하지마라!

뭐 일단은 거시기~ 와 삐리리~ 밖에 기억에 안남겠지만 아무튼 현재까지의 MMORPG 게임에는 이러한 특징을 가진 서큐버스, 인큐버스를 나타내지 않고 오로지 생명력을 빨아들이는 형태로만 등장하는 경우가 전부이다. 이제 서큐버스에 대해 알았다면 옷벗기기 놀이로 서큐버스를 기만하지 말고 그냥 죽이자. 혹시 모른다 그대가 잠든 후에 나타나서... (-_ㅡㆀ)

던전의 천장에 닿을 듯한 거대한 몸집, 한방에 데들리 상태에 빠지게하는 무시무시한 파괴력, 어디에 얼굴이 있는지 전혀 알수 없는 얼굴, 얼마나 운동을 했으면 근육이 다 돌처럼 됐을까? 필자가 누구를 묘사 하고 있는지 짐작이 가는 독자가 분명히 있을 것이다. 그렇다 필자는 골렘을 묘사 하고 있었다.

키아던전과  피오르 던전에 보스방에서 서식하고 있는 골렘, 타 온라인 게임에서는 중간 보스 또는 일반 몬스터 급으로 등장하지만 마비노기에서 만큼은 엄청난 맷집과 똥파워를 자랑하는 보스로 등장한다.

판타지 게임을 하면서 얼마나 자주 등장하는 몬스터인지 필자가 설명하지 않아도 다 알고 있을 것이다. 필자는 이번 시간에 판타지 세계의 골렘에 대해서 얘기 해보려고 한다. 다소 지루한 내용이 될지 모르지만 독자들에게 판타지의 지식을 심어주고자 함이니 노력을 가상히 여기어 읽어 주기를 당부한다.

`골렘`은 유태인의 전설에 의해 탄생된 몬스터이다. 왕의 폭정에 괴로워하던 유태인들은 수호신으로서 거대한 진흙 인형을 만들었는데 이 인형에게 악마가 생명력을 불어넣어 왕에게 대항하게 한 것이 골렘이다.

중세 유럽에서 `골렘`은 전설의 영역에서 벗어나 하나의 사상으로까지 발전했다. 즉, 무의 상태에서 생명을 만들어 낸다고 하는, 인간에게 있어 궁극적인 테마의 제재가 된 것이다. 이 제재를 다루는 것은 연금술사나 밀교의 신앙인뿐이었다.

`골렘`이라는 단어가 생긴 것은 `카발리스트`라는 밀교 신앙자에 의해서였다. 그는 어떤 수수께끼를 풀기 위해 성서의 문자를 바꿔놓았는데 그 결과 만들어진 것이 이 `골렘`이라는 단어였다고 한다. 단어에 의해 만들어진 `골렘`은 마찬가지로 단어에 의해 원래의 점토로 다시 돌아간다고 한다.

중세 유럽의 `카발리스트`들이 `골렘`에 관한 연구를 하고 있었던 것과는 별도로 세계 각지에서도 무에서 생명을 만들어 내려고 하는 연구가 진행되었다. 13세기 독일의 연금술사 `알베르투스`는 30년 걸려서 점토로 `골렘`을 만들어 냈다고 한다.

`알베르투스`가 만든 `골렘`은 건물을 부시면서 걸어다니는 거대한 몬스터가 아니라 인간 정도 크기의 로봇과 같은 것이었다고 한다. 이 `골렘`은 걷고 말하고 인간의 질문에 답하고 수학 문제를 풀 수 있을 정도로 잘 만들어졌다. 그러나 너무 지나치게 떠드는 탓에 `알베르투스`의 제자가 망치로 부셔버렸다고 한다.

일반적으로 `골렘`은 악의 마법사에 의해 만들어지고 악의 마법사에 의해 움직이도록 되어 있다고 하는데, 원래 유태인의 전설에서는 민중을 돕는 좋은 존재였다. 그런데 골렘이 왜 악의 몬스터가 된 것일까? 그 원인은 `기독교 사상`과 깊이 관련되어 있는 것 같다.

기독교에서는 신 이외에 생명을 머물게 할 수 있는 자는 없다고 되어 있다. 만일 그러한 자가 있다면 그것은 바로 악마일 것이다. 즉, `골렘`을 만들어 내는 것은 악마의 임무라는 것이다.이렇게 골렘=악 이라는 도식이 성립하게 된 것이다.

골렘에 관한 이야기는 중세 유럽뿐만 아니라 현대에 있어서도 매우 친숙한 이야기이다. 대표적인 것으로는 `프랑켄쉬타인` 박사가 만든 몬스터를 들 수 있다. 고대에서 현대에 이르기까지 생명 있는 것을 만들어 내려는 인간의 시도는 끝이 없는 것 같다. 몬스터로서의 `골렘`의 특징으로는 진흙과 바위 등의 무기질에 유사생명을 부여받은 것이므로 지능이 없다는 점이 있다.

따라서 마법사가 `골렘`에게 명령을 내리면 이곳을 지켜라 , XX를 죽여라 등의 간단한 명령밖에 수행하지 못한다. 이 명령은 일종의 봉인(封印)이므로 명령이 없어지거나 마법사가 죽어버리면 골렘은 제멋대로 난폭해져 버린다. 이렇게 되면 `엘리멘탈`과 마찬가지로 누군가가 `골렘`을 쓰러뜨릴 때까지 난행을 멈추지 않는다.

종류에 따라 다르긴 하지만 `골렘`을 무찌르기 위해서는 `골렘` 자체를 파괴해야 한다. 이밖에도 `골렘`을 만들어 낼 때 함께 만들어진 `골렘`을 파괴시키는 주문이 있다면 싸우지 않고도 물리칠 수가 있다.

`골렘`의 공격방법은 대부분의 경우 맨주먹으로 치는 것이다. 경우에 따라서는 무기를 사용할 때도 있는데, 무기라고 해봤자 기껏해야 곤봉 정도이다. `골렘`을 종류별로 살펴보면 다음과 같다.

클레이 골렘(CLAY GOLEM)

유태인의 전설에 등장하는 골렘이다. 유태인뿐만 아니라 모든 전설에 등장하는 골렘은 대부분 이 골렘이다. 클레이란 점토를 말한다. 몸이 흙으로 만들어져 있기 때문에 칼 등의 무기로 찔러도 상당히 큰 대미지(팔을 자른다든가)를 입히지 않는 한 거의 효과가 없다.


인간의 육체를 사용해 만든 골렘이다. 프랑켄쉬타인이 만든 몬스터도 이 플레시 골렘이었다. 좀비와 비슷한 몬스터이지만, 좀비가 보통 사람 정도의 크기인데 비해 플레시 골렘은 2미터 정도의 큰 키를 가지고 있다. 플레시 골렘은 인간의 육체를 사용하고 있으므로 대미지를 가할 수가 있다. 그러나 인간처럼 출혈과다 등으로 죽지는 않는다. 플레시 골렘뿐만 아니라 모든 골렘에게는 심리적인 마법이 전혀 효과가 없다.

아이언 골렘(IRON GOLEM)

아이언이란 철을 말한다. 따라서 골렘 중에서는 가장 강력한 힘을 가지고 있으며 키도 5~6미터나 된다. 헤이파스토스가 만든 청동 거인 타로스(그리스 신화에 등장하는)가 금속으로 만들어진 골렘 중에서는 가장 유명하다. 아이언 골렘의 몸은 중세에서 가장 강력한 금속인 철로 만들어져 있으므로 보통의 무기로는 부상을 입힐 수가 없다. 마법이 걸린 무기, 그것도 매우 강력한 것이 아니면 안된다. 아이언 골렘은 골렘 중에서는 가장 강력한 공격력을 가지고 있다.


돌로 만들어진 골렘을 말한다. 리빙스태튜와 비슷한 것 같지만, 자신의 의지를 가지고 있지 못한 점이 리빙스태튜와 근본적으로 다르다. 돌로 만들어졌기 때문에 방어력은 높지만 반면에 재빨리 움직일 수 없으므로 공격을 받아도 잘 피하지 못한다. 또한 아이언 골렘과 달리 무기를 사용해 공격하는 일도 없으므로 공격력이 그다지 높지 못하다. 그렇기는 해도 역시 아이언 골렘과 같은 크기의 몸을 가지고 있으므로 간단히 쓰러뜨리기는 어렵다.

키아 던전과 피오드 던전에 나오는 골렘의 모습을 생각해보자. 마비노기에는 현재 스톤 골렘 밖에 존재하지 않는다. 골렘 뿐만 아니라 전체적인 몬스터의 종류가 판타지 라이프를 추구한다는 모토와는 달리 빈약하다는 느낌이 들고 있다. 따지고 들자면 아이템도 빈약하고 마법은 턱없이 빈약하다. 세상에 판타지에 마법이 6가지 밖에 존재하지 않는다는 것은 말도 안되지 않나?

말 만 `판타지 라이프` 라고 하지 말고 계속 모자라는 부분을 추가해서 정말 판타지 세계에 살고 있는 듯한 그날을 기다려보며 이 기사를 마치도록 하겠다.

보스 몬스터 탐구는 계속 되어야 한다;;;

일단 전의 므미님의 공략의 끝자락에서 얻은 ′마우러스′ 키워드를 가지고 많은 유저분들이 헤맬수 있을거라고 봅니다.

특히 타르라크에게 가는 줄 알고 타르라크에게 힘들게 가는 일이 있을수도 있겠지만 이 키워드는 타르라크나 메이븐이 아닌 티르코네일의 촌장 `던컨`에게 물어봐야 합니다.

그럼 던컨은 `마우러스 구이디온` 이라는 새로운 키워드를 주고 마우러스는 제 2차 포워르 전쟁에서 포워르 측의 마법사 자브키엘이 준비하던 마법을 막기위해 침투했다가 장렬히 전사했다는 말을 해줍니다.

그럼 이 키워드를 가지고 `타르라크`에게 찾아가게 되면...

그 마족의 책의 저자인 대마법사 마우러스가 자신의 스승이라는 말을 합니다. 그리고 타르라크는 책을 다시 보며 분노의 서 끝자락에 나오는 ′잃어버린 증표′가 무엇을 의미하는지 고민하다가 순간 분실물이 보관되어있는 관청을 생각해 내고 ′마우러스의 분실물′이라는 키워드가 생기며 관청에서 그 물건을 찾아와 줄것을 요구합니다. 그 즉시 에반에게 찾아가게 되면 에반은 방금전 사제 크리스텔이 그 분실물을 찾아갔음을 이야기 해줍니다.

그리고 다시 크리스텔에게 찾아가면 크리스텔은 붉은 여신의 날개(마스 던전행)과 부서진 토크(마우러스 RP아이템)을 주게 됩니다.

이제 이 부서진 토크를 넣고 들어가게 되면 대마법사 마우러스가 되어서 게임을 플레이 할수 있다.

마우러스는 아이스 볼트,파이어 볼트,라이트닝 볼트가 전부 1랭크이며 한번 차지를 할 경우 5차지가 되는 마우러스의 전용 스킬 ′체인 캐스팅′을 가지고 있어 수월한 플레이가 가능하다.(그 스킬만 배울수 있다면 필자는 무조건 마법사를 키울것이다 -_-)

일단 던전의 난이도는 기존의 마스던전과 동일하다. 코볼트가 나오고 아처도 나오지만 마우러스의 마법 차지 1~2번이면 방 하나가 끝장나니 그다지 어렵지는 않을 것이다.

이렇게 진행을 하다보면 중간에 마우러스가 휴식을 취하고 출구를 찾을 것을 다짐합니다. 그리고 보스방에 들어가게 되면 기존의 X개 타이틀을 가진 헬하운드 대신 고스트 아머들이 대거 등장하고 이벤트가 벌어지게 됩니다.

※ 미중년(?)의 파워풀 한 한마디. 매우 멋집니다 +_+

고스트 아머와 마우러스 간의 대화가 진행되고 얼마 안가 전투가 벌어집니다. 하지만 이 전투의 목적은 고스트 아머를 전멸시키기 위함이 아닌 스토리를 이어나가는 것입니다. 고스트 아머를 2~3마리 정도 처리를 하면(파이어볼트 1번 차지만 하면 한마리씩 죽어나갔다.) 어둠의 군주가 등장하여 싸움을 말립니다.

어둠의 군주와 마우러스와 대화를 하다가 어둠의 군주가 ′진실′을 보여주고 그 ′진실′을 보고 마우러스는 여신 모리안을 만나기를 원하게 되고 등노출 매니아, 입없는 여신 등등의 타이틀을 가진 모리안이 나타나게 됩니다.

그리고 또 새로운 키워드가 나오고 그리고 RP던전은 끝이 납니다.

키워드를 가지고 던컨에게 찾아가면 마우러스가 살아있음에 놀라며 분노의 서를 다시 봐야겠으니 타르라크에게 가져오라는 말을 합니다.(책을 가지고 있을 때는 안 보고... -_-) 그리고 ′분노의 서 돌려받기′라는 퀘스트가 생기게 됩니다. 타르라크는 아무래도 나이가 지긋한 던컨이 많은 것을 알고 있을것이라고 생각하며 그 책을 돌려줍니다.

(사실 필자는 타르라크가 ′그 책은 크리스텔에게 보냈는데요?′ 라든지 ′책을 복사하고 있으니 한달뒤에 오시면 돌려드리겠습니다′같은 식의 ′하루 버티기′ 혹은 ′유저 부려먹기 퀘스트′가 진행될까봐 조마조마했었다. -_-)

그리고 그 책을 던컨에게 가지고 가면 던컨은 복수의 서 가 3부작일 거라는 청천벽력과도 같은 소리를 합니다. 물론 아직 잘 모르시겠지만 3부작이라는 의미는 나중에 보시면 아시겠지만 엄청난 시간을 요구한다는 뜻입니다.

기다려라. 그러면 책이 도착할 것이다.

기다려라. 그러면 번역 될 것이다.

같은 일이 일어난다는 것이지요 -_-

일단 던컨은 이 책을 번역한 사람에게 다음 권에 대해서 물어봐 달라고 합니다.

네... 번역한 사람은 던바튼에 있지요. 밀납을 쓰던가 버스를 타던가 아니면 운동을 위한 도보를 해서 크리스텔에게 가면 자신은 모르지만 책방의 아이라 라면 알지도 모른다는 말을 합니다.

그리고 아이라에게 찾아가면 ′분노의 서 돌려받기′ 퀘스트가 끝이 나게 됩니다. 아이라는 1권은 가지고 있으니 낱개로 팔아야 한다고 궁시렁 대다가 마족의 언어로 쓰여진 책이라고 하자 사람이 읽지 못할 것을 총판에서 찍을리가 없다고 말을 합니다. 그러나 아이라는 그런 책을 찾는것에 흥미를 가지며 수소문을 할테니 좀 기다려 달라는 말을 합니다. (그 좀 기다려 달라는 것은?)

물론 그 기다리라는 것은 현실로 다음날에 오라는 것을 뜻합니다 -_-;;;

이제 분노의 서 2권에 대한 퀘스트로 들어가겠습니다.

분노의 서 2권에 대한 정보가 들어왔다고 부엉이가 날라오면 아이라를 찾아갑니다. 아이라는 영원의 땅, 티르 나 노이의 저자인 레슬리 씨가 그 책을 키아던전에서 본적이 있다고 하며 그 책을 보기 위해서는 현자의 메모 라는 아이템을 넣고 들어가야 한다는 말을 합니다.

현자의 메모와 키아 던전으로 가는 붉은 여신의 날개를 함께 줍니다. 참고로 이 키아던전은 팀플로 가서 클리어 해도 상관은 없습니다. 그리고 키아던전의 보상방에서 나오는(보상방에서 역인챈 굵은 나무가지가 안 나오고 대신 분노의 서가 나오게 됩니다.) 분노의 서를 들고 던컨에게 가지고 가면 던컨은 수고했다는 말과 함께 또 다시 번역! 해달라는 말을 합니다.

던바튼의 크리스텔에게 가게 되면 크리스텔은 번역을 해줄테니 책을 놓고가라고 합니다. 물론 그 번역기간은 현실시간으로 하루가 되겠습니다. -_-

현실시간으로 하루가 지나면 번역이 끝났음을 알리는 부엉이가 찾아오는데 그것을 보고 크리스텔을 찾아가면 크리스텔은 분노의 서 2권 번역본을 줍니다. 그리고 던컨에게 가게 되면 던컨은 정독을 하고 이번엔 3권을 달라고 합니다. 물론 다시 던바튼 서점의 아이라 에게 가야 합니다. 그러면 아이라는 구하도록 노력은 하겠지만 힘들거라는 말을 남깁니다.

그래도 하루가 지나면 부엉이가 오니 걱정을 놓고 기다리시기 바랍니다 -ㅅ-;;;(이제 이쯤 되면 메인 시나리오를 하는 많은 유저들이 인내의 도를 득도했을 것이라고 본다. -_-)

하루가 지나고 접속을 하면 아이라에게 부엉이가 날라오고 아이라에게 찾아가면 아이라는 ′분노의 서 3권′의 행방이 교복 매니아 라사에게 그 책이 있는것을 본적이 있다는 말을 합니다. 그대로 라사에게 찾아가면 라사는 가이레흐 유적 발굴장에서 일하는 세이머스 씨가 얻은 책이었고 그 책의 번역을 맡았던 것이라는 말을 합니다.

그리고 라사는 다시 세이머스에게 그 책을 보냈다는 말을 합니다. 즉, 마비노기 렉신강림 1순위 지역인 드래곤 유적지로 향해야 한다는 말이 됩니다. 반호르 지역에 가까우니 밀납 날개 하나를 구해서 반호르로 간 후 올라오는 것이 던바튼에서 내려가는 것에 비해 시간 절감이 될겁니다.

세이머스에게 찾아가면 세이머스는 자신도 어차피 읽지 못하는거 부탁 하나를 들어준다면 책을 주겠다고 합니다. 그 부탁이란 반호르에 살면서 많은 유저들에게 제련을 하기 위해 필요한 노를 미끼로 돈을 뜯어내는(?) 아들 숀에게 선물을 전해 달라는 것입니다.

선물에 쓰인 말에 전적으로 공감합니다 -_-

그리고 그 선물을 반호르의 숀에게 가져다가 주고 세이머스에게 돌아가면 세이머스는 분노의 서 3권을 줍니다.

이것을 크리스텔에게 가져가면 최대한 빨리 번역을 마치겠다는 말을 합니다.(그렇게 말 해도 하루. -_-) 하루가 지나고 접속을 하면 부엉이가 날라오고 크리스텔에게 가면 크리스텔은 분노의 서 3권 해석본을 전해줍니다. 그리고 또다시 그 책을 정독을 해야 합니다.

필자의 케릭터는 머리가 나쁜건지... -_- 3번의 정독을 했음에도 실패가 되더군요.(3번의 실패끝에 성공을 하고 기뻐서 날뛰는 제 케릭을 보며 한심함이 들었던...)

도대체 넌 누구를 닮아서 그렇게 머리가 나쁜거냐? -_-

정독을 하면 글라스 기브넨 이라는 키워드를 얻습니다. 분노의 서에서는 마족들의 침략 수단이라는 의미를 띄고 있었지만 던컨에게 찾아가면 화들짝 놀라며 어디서 들었냐고 물어보고 분노의 서 3권을 보겠다는 말을 합니다.

그 글라스 기브넨은 전설의 거인으로서 보이는 모든 것을 증오와 분노를 담아 파괴한다는 괴물이라고 말을 해줍니다. 그리고 그 글라스 기브넨에 대한 책을 반호르의 브라이스에게 빌려줬으니 그 책을 찾아보라는 말을 합니다. 물론 반호르로 가야한다는 뜻이 됩니다. 반호르로 가서 브라이스와 대화를 나누면 ′글라스 기브넨의 뼈′ 라는 키워드를 얻게 되고 그 괴물을 부활시키기 위해선 아다만티움이라는 광물질이 필요한데 그것을 반호르의 광산에서만 나온다는 말을 합니다.

그러나 얼마전 부터 그 광산에서는 그 광물질이 나오지 않았고 나오지 않는 원인으로 추정되는 것은 광맥이 끊어졌거나 누군가가 다 캐갔을 것이라는(트X스트냐? 48시간 -ㅅ-) 말을 합니다.

이제 이 키워드로 타르라크에게 찾아가면 타르라크는 글라스 기브넨을 만들기 위해서는 글라스 기브넨의 뼈대를 발굴해 맞춰야 하고 그 빠진 뼈가 있다면 아다만티움을 주조해서 만들어야 한다는 말을 합니다. 그리고 한번 굳어진 아다만티움은 절대 부숴지지 않으니 그 뼈를 부술 생각은 하지도 말라는 말을 합니다.

타르라크는 부탁을 하게 되는데 부서져버린 안경에 기억을 온전히 하기 위해 보존의 마법가루를 구해다 달라는 말을 합니다. 보존의 마법가루는 물건을 더이상 부서지지 않게 하는 효과(퍼거스의 웨폰 브레이크도 걸리지 않는 것일까?) 를 가지고 있다고 하고 그리고 그것을 구해주면 자신의 안경에 그 보존마법을 걸어서 주겠다는 말을 합니다.

이것을 구하기 위해서는 피오드 던전으로 향해야 합니다. 피오드 던전은 단일 층으로 구성되어 1층에 보스룸이 존재하여 빠른 레이드가 가능할거라고 생각하실지 모르겠지만 오토디펜을 가진 몹들로 인해 난이도가 상당하므로 아는 분들과 파티플을 이루어 가거나 아니면 필자처럼 용병을 구해서 가는 방법을 추천합니다.

일단 난이도가 높은 몹으로는 고르곤이라는 황소몬스터와 베어울프라는 몬스터로 두 몬스터 전부 오토 디펜스를 가지고 있으며 베어울프의 경우는 한번 때릴때의 데미지중 대부분이 부상률로 가기때문에 포션빨로 버틴다는것은 상당히 힘듭니다. 참고로 보존의 마법가루는 몬스터가 아닌 보상방에서 나오게 됩니다.

이렇게 마법가루를 구하는데 성공을 하였다면 타르라크에게 돌아가 보존의 마법가루를 건네고 메모리얼 아이템과 붉은 여신의 날개를 획득합시다. 참고로 이 메모리얼 아이템은 라비던전에서 사용해야하며 그 뿐만 아니라 3인플로 파티를 구성한 상태에서 사용해야 합니다.

이제 이 메모리얼 아이템을 3명의 파티를 이룬 상태에서 라비던전에 넣게되면 또다시 세전사가 되어서 게임을 플레이 할 수 있다. 이번 RP는 루에리와 마리의 역활이 특히 중요하며 마리의 경우 새로운 스킬이 가진 상태에서 게임을 플레이 합니다. 게임을 플레이하는 던전은 ′알베이 던전′으로 되어있고 던전 테마음이 다른 던전과 다릅니다.

그리고 세 전사는 이 곳을 ′티르 나 노이′라고 지칭하는데 알베이 던전이 티르 나 노이로 가는 길인지 아니면 사라진 세 전사가 알베이 던전이 티르 나 노이 인것으로 착각한 것인지는 자세히 알 수 가 없습니다. 일단 총 2층으로 구성되어 있으며 1층은 방이 어느정도 수를 가지고 있으나 2층은 방이 달랑 2개 입니다.

보스방에 들어서게 되면 이벤트 화면으로 바뀌게 됩니다. 그 이벤트에서 아주 충격적인 사실이 등장하고(그 사실이란... 비밀입니다~!) RP는 끝이 나게 됩니다. 그러고 나서 새로운 키워드를 얻게 되며 RP가 끝이 납니다.

필자가 타르라크의 이미지를 망치는데에는 고작 3초라는 시간밖에 걸리지 않았다. (도망)

이제 이 키워드로 타르라크와 던컨을 비롯한 에린의 NPC들에게 물어보아야 합니다. 이 다음의 스토리 진행이 구체적으로 제시가 되어있지 않습니다. 어떤 사람의 말로는 모든 에린의 NPC에게 말을 걸고 나서 50번정도의 접속을 해야 받았다는 말도 있고 23번의 접속끝에 받았다는 분도 있었습니다.

하지만 필자의 경우는 모든 에린의 NPC가 아닌 티르코네일과,던바튼의 NPC들에게 물어보고 우연히 캠핑패널티 때문에 껏다가 킨것 한번(강조중!!!)때문에 바로 모리안 여신이 나타났습니다. 이것으로 보아서 2가지의 추측이 가는 것이 있는데 필자가 행동했던 휴식 상태에서 껏다 킨 것 때문이 아닌가 싶은 것이 있고 또 하나의 경우로는 필자가 여신 모리안의 사랑을 받고 있는게 아닌가 싶은것도 있습니다.(-_-)

이 꿈을 꾸고 나면 여신의 펜던트가 손에 쥐여지게 되고 새 키워드가 생기게 되는데 이 키워드로 던컨에게 물어보면 ′티르 나 노이로 가는 방법′이라는 키워드가 생기며 타르라크에게 티르나노이로 가는 방법에 대해서 알아오라고 합니다. 그렇지만 타르라크에게 가게되면 알려주지 않습니다.

다시 던컨에게 찾아가면 타르라크가 되었던 크리스텔이 되었던 간에 빨리 알아오라고 합니다. 그리고 크리스텔에게 말을 하면 크리스텔은 레벨 40 이상이 되어야 한다는 말을 합니다.(한마디로 허접 즐 이라는 뜻인듯. -_-) 그리고 크리스텔과 타르라크가 한가지 의미있는 말을 담는데... 크리스텔의 경우는 ′소울 스트림의 인도자 마저도 도와줄수가 없다′라는 말을 합니다.

그 말을 풀이해보자면 나오의 부활이 안된다는 뜻인것으로 추정되며 타르라크의 경우는 ′에린과는 다른 방식으로 되어있는 곳이라고 하며 처음에 자신과 함께 들어갔던 동료가 아니고서는 부활을 해줄수 없다′ 라는 말을 합니다. 즉 마지막 여신상 부활이 안되고 오로지 동료에 의한 부활만 가능한 것으로 추정됩니다.

아직 필자가 레벨이 34인 관계로 더이상의 시나리오 진행은 불가능 했다.(현재 만돌린 4,5채널의 키아 무한 순례중) 확실히 메인시나리오를 즐기며 깨달은 것 중 하나는 상당한 인내심이 필요하고 많은 금전(밀납날개값)이 빠져나가게 될 것이라는 것이다.

하지만 무한 사냥에 지친 유저에게 새로운 재미로 다가올수 있는 메인 시나리오.(그러나 복수의 서 퀘스트에 들어서면 도리어 부작용이 일어날수도...)

아주 인내심이 좋은 유저분들에게 추천해 드립니다. ^^

- 공략하라고 리니지 GA에서 끌려온 수습기자 마나신궁 -

6월 22일 정식서비스 이후, 마비노기에는 새로운 의상이 많이 추가 되었었다.

추가 된 의상 중 극소수를 제외한 나머지 의상들은 유저들의 기대했던 것보다 디자인과 기능 면에서 부족한 점이 많아서 유저들의 외면을 받고 있는것은 누구나 아는 사실 일 것이다.

7월 6일 업데이트 된 내용을 보면 `데브캣`의 제휴사 `아이겐포스트`에서 실제로 판매하는 의상이 게임내에서 유니크성 아이템으로 한정 된 시간(7월 20일)까지 판매 될 것이라고 한다.

이번에 추가된 아이템을 보면 남자용과 여자용 하나씩이고 옵션이 없는 것임에도 불구하고 유니크 아이템이라는 이유로 가격이 비싸기 때문에 유저들의 반응은 그리 환영스럽지는 못하다.

※ 의상 원본 : http://www.mabinogi.com/4th/event_flff(b03).asp

남성복 아이겐 보이시 캐주얼

여성복 아이겐 걸리시 캐주얼

이상하게도 남자와 여자 옷이 같은 가격임에도 불구하고 내구력이 10이나 차이가 난다.

아이겐포스트 아이템 판매 NPC의 대사와 위치

게임에 실제 존재하는 회사의 광고가 삽입 되는 경우는 많았지만 의류 업체의 상품이 직접 적용 되는 것은 아주 드문 경우, 이런 광고가 가능한 것은 게임의 배경을 중세시대와 현대시대의 중간 쯤으로 설정한 마비노기 이기때문에 가능한 것 일까? 아마도 광고효과가 좋다면 앞으로 아이겐포스트의 의상은 추가 될 듯 한 느낌이 강하게 보인다.

다른 온라인 게임보다 튀는 아이디어로 항상 새로운 시도를 하는 `데브캣`의 자세는 높이 평가 할 만 하다. 하지만 일부 유저들은 "이런 아이템을 추가 하려고 연구하는 시간에 서버 안정화와 렉을 줄일 고민은 왜 하지 않느냐"라는 반응과 "제휴업체의 지원으로 좀 더 좋은 환경에서 게임을 할 수 있게 하려는 것이 아닐까" 이라는 대립적인 반응을 보이고 있다.

혹자는 마비노기를 커뮤니티가 중요시 되는 2세대 MMORPG 게임이라고 한다. 그래서 캐릭터의 의상은 게임에서 아주 중요한 자리를 차지하고 있으며 자신의 캐릭터를 꾸밀수 있는 의상이 다양해야 유저들에게 환영받을수 있을 것 이라고 말한다.

그러나 게임에 다양한 이벤트와 새로운 아이템들을 서비스 하는 것 보다 급한 것은 게임서버 안정화와 밸런스 조절이 아닐까? 진정한 판타지 라이프를 지향하는 `데브캣`이 앞으로 어떠한 길을 선택 할지 그 행로를 주목해 볼 필요가 있을 것 같다.

** 3차원 엔진 **
copyrightⓒ 김성완(찐빵귀신) [1999년 12월 21일]

1. 상용 3차원 엔진

국내는 대부분 Direct3D에 의존해서 3차원 게임을 개발하고 있고, 본격적인 의미의 3차원 엔진을 갖추고 있는 곳은 별로 없습니다.

상용3차원 엔진을 사서 하던 아니면 공개용 3차원 엔진을 사용하던 기본적인 3차원 엔진을 직접 개발 할 수 있을 정도의 지식과 능력을 갖추고 있지 않으면 제대로 활용하기 힘듭니다.

그러니까 3차원 엔진을 직접 개발할 능력이 되는데, 시간을 절약하기 위해서 상용3차원 엔진을 사는게 아니라면 사놓고도 어떻게 사용하는지 몰라서 헤멜 것이고, 결국 3차원 엔진을 개발하는데 드는 시간과 다름없는 시간을 소비할 겁니다. 기
본적인 3차원 프로그래밍에 대한 지식을 갖추었다 해도 전체 개발진이 상용 3차원 엔진에 익숙해져서 100% 제대로 활용하려면, 족히 6개월 정도의 시간이 필요합니다.
상용 3차원 엔진이 3차원 게임을 자동으로 척척 만들어 주는게 아니므로...

레인보우6 개발진도 3차원 엔진 라이센스 해서 개발하다 막판엔 결국 직접 만들어서 했다는 슬픈 스토리가 있죠.

2-3년씩 충분한 개발기간이 주어지는게 아니라면 남이 만든 엔진으로 어떻게 해볼려고 해도 부족한 시간속에서 제대로 분석하기도 힘들고, 일일이 기능들을 적용하고 테스트하고 해야하는데 시간은 턱없이 부족하고, 프로그램들에는 버그가 있게 마련이고 자기가 짠 프로그램도 버그 잡기 힘든데 하물며 남이 짠 건...

그리고 상용 3차원 엔진을 라이센스 할때는 반드시 소스도 함께 라이센스 해야합니다.
그런데 대개 소스까지 라이센스하면 라이센스 비가 엄청 뛰죠.
참고로 모노리쓰 사의 엔진의 경우 25만불 정도...
퀘이크나 언리얼 엔진의 경우는 소문에는 백만불 정도래는데..
아마 50만불 정도가 아닐까 합니다.
아주 저가형 엔진의 경우 '파워렌더'가 있는데 소스까지 라이센스하면 만불입니다.
그런데 싼게 비지떡이죠.

당장은 남이 만든 엔진을 사용하더라도 장기적인 안목에서 볼때 최소한 1년정도는 3차원 엔진 개발에 투자해야할 겁니다.

** 3차원 엔진 **
copyrightⓒ 김성완(찐빵귀신) [1998년 12월 28일]

2. D3d와 OpenGL은 3차원 엔진이 아니다.

3차원 하드웨어 가속을 인터페이스 해주는 대표적인 두개의 API가 바로 D3d와 OpenGL 이죠..

그런데 대개 초보들의 경우 이들 API를 사용하려면 모두다 이들 API만 사용해야하는 걸로 생각합니다.
하지만 실용적인 견지에서 보면 단지 폴리곤 rasterization 부분만 사용하면 그만입니다.

Direct3d와 OpenGl은 일반적인 의미의 3차원 엔진이 아니라 단지 하드웨어 가속기능을 동일한 인터페이스로 처리해주는 API라는걸 잊지마십시오.
3차원 가속기 없이 사용하는 것은 어디까지나 공부하기 위한 목적이지 실제 어플리케이션에서 사용하는 것은 개념없는 짓입니다.

그러므로 소프트웨어 3차원 엔진이 필요하면 퀘이크나 언리얼 엔진을 라이센스 하거나 직접 개발해야합니다.
Direct3d나 OpenGL은 3차원 가속기능의 표준적인 API이지, 일반적인 소프트웨어 3차원 엔진의 대체물이 아닙니다.
그리고 게임이 제대로된 완전제품이 되려면 일단 소프트웨어 엔진이 있어야 합니다.

소프트웨어 엔진은 단지 폴리곤 레스터라이즈만 소프트웨어로만 처리하는게 아니라, 그것보다 더 중요한 HSR(Hidden Surface Removal)을 담당하는 중요한 기능을 합니다.
당연한 얘기지만 하드웨어 가속기들도 HSR은 Z-Buffering외에는 전혀 지원하지 않습니다.
즉, BSP나 Portal등은 결국 소프트웨어의 몫입니다.

최근에 나온 툼레이더 3의 경우는 하드웨어 담당 기능의 대표격인 텍스츄어 필터링도 소프트웨어로 처리하더군요.(MMX이용)
그러니깐 툼레이더 2를 부두에서 돌린것보다 툼레이더 3를 소프트웨어 엔진에서 돌린 것이 더 화질이 좋습니다.
그리고 가장 이상적인 것은 기본적으로 소프트웨어 엔진이 하드웨어 가속기의 힘을 빌리지 않고도 최대한의 성능을 발휘해야합니다.

결국 퀘이크나 언리얼 엔진을 라이센스 할만한 돈이 없다면 직접 개발하는 수밖에 없습니다.
소프트웨어 엔진이 탄탄하게 갖추어져야 결국 하드웨어 가속기 상에서도 뛰어난 성능을 발휘하는 겁니다.

결론적으로 Direct3d나 OpenGL은 하드웨어 가속기능을 표준적으로 사용하기 위한 인터페이스지 결코 일반적인 목적의 3차원 엔진은 아닙니다.
물론 소프트웨 엔진은 320*200의 저해상도 모드만 지원하기로 한다면 사용할 수도 있지만..
요즘 처럼 이런 시대에 그런 저해상도를 유저들이 좋아할리 없겠죠.

** 3차원 엔진 **
copyrightⓒ 김성완(찐빵귀신) [1998년 1월 3일]

3. 국내에서는 3D엔진 안 만드는가??

대개 상용 3D 엔진들은 범용성을 만족해야 하므로, 속도면에서 특정 게임에 최적화된 자체 엔진들에 비해서 느립니다...
속도와 범용성은 같이 잡을 수 없는 두마리 토끼이죠..

대외적으로 상용 판매를 전재로 한 3D 엔진들은 어쩔 수 없이 범용성을 지향해야 하고, 결국 속도가 희생됩니다.
하지만 id의 퀘이크 엔진 처럼 거의 동일한 게임형식인 경우, 다른 개발사에 속도 희생 없이 제공이 가능합니다.

우리나라도 범용적인 상용 엔진 보다는 개발사간에 상호 라이센스 형식으로 기술을 제공하는게 좋을 듯 합니다.
괜히 각자 따로 자체 개발 하느라고 중복 투자 하느니 보다, 제일 괜찮은 엔진 개발한 회사 걸 서로 라이센스 해서 나누어 쓰는게 어떨지..

달러 한푼이 아까운 시절인데, 같은 국내 개발사 끼리 돕는게 애국이 아닐 지요...
제가 만일 개발사 오너이고 좋은 3D 엔진을 개발했다면 그렇게 했을텐데..
공짜로 주는 것도 아니고, 적정선에서 적절한 라이센스료 받고, 상호간에 직접 경쟁은 피하게 출시시기나 장르 조정하면 될 것으로...

사실 출시시기 조절이니 장르 조절이니 이런 것 안해도 계약하기 나름이죠.
3D 엔진 라이센스 해 간 개발사 게임이 잘나가면 일정 수량(만개 정도)이상 부터는 소정의 로얄티 받으면 되지요..
이러면 라이센스 해준 개발사만 이익을 보는게 아니라 라이센스 한 개발사도 3D 엔진 자체 개발하느라고 용쓰지 않아도 되고, 직접 개발시 보다 비용이 적게 드는 것이죠.

국내 게임 업게에 오래 몸담았던 경험으로는 우리나라에서 이런 일이 일어나기 힘들다는 걸 잘 알지만 꿈이라도 꾸어 보아야지요.

+ Recent posts