Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

Refresh your Memory: Advanced Graphics Algorithms 140

Posted by CmdrTaco from the i-broke-my-brain dept.
subtle writes "DevMaster.net has posted an interesting article about advanced graphics algorithms. The article discusses six widely used algorithms in graphics rendering of indoor and outdoor environments, namely: quad-based static terrain, Roettger's approach to continuous levels-of-detail in terrain, real-time optimally adapting meshes, portals, BSPs and PVSs. In each case the algorithm is discussed and some aspects of implementation are considered, as well as analyize each algorithm for its application in modern graphics systems."
This discussion has been archived. No new comments can be posted.

Refresh your Memory: Advanced Graphics Algorithms More

Refresh your Memory: Advanced Graphics Algorithms

Comments Filter:

  • It has revolutionized landscaping (Score:5, Funny)

    by AtariAmarok ( 451306 ) on Tuesday May 11, 2004 @11:17AM (#9116877)
    "The article discusses six widely used algorithms in graphics rendering of indoor and outdoor environments"

    I look forward to re-doing my back yard with a nice quadratic mesh algorithm with pseudo-fractal post-processing.

  • In Case of /. (Score:4, Informative)

    by Anonymous Coward on Tuesday May 11, 2004 @11:17AM (#9116889)
    AWESOME Rock Music Here [kicks-ass.net]
    ___

    Advanced Graphics Algorithms

    By: Henri Hakl

    1. Introduction
    Graphics representation of reality - or at least virtual reality - in games, simulations, movies, commercial and military applications have become increasingly convincing and immersed a growing audience in disbelieve - and at times even utter belief. This process has, in part at least, been facilitated by exponentially growing processing speeds and in more recent years the advent of hardware acceleration of graphics rendering.

    However, even in spite of being able to process several giga-flops every second, a brute force approach to rendering is not able to produce nearly as realistic real-time environments and worlds as we find portrayed in games and interactive simulations. The reason is that numerous algorithms are used that approximate or compromise reality in order to achieve interactive rendering rates. These algorithms include methods to simplify scenes, to efficiently cull invisible parts or to simply ignore realistic computations in favour of faster approaches that, though inaccurate, portray reality.

    Following the introduction we present a section on several graphics rendering concepts that feature in this article. In the remainder of this article we will discuss six popular algorithms for indoor and outdoor rendering of environments, namely:

    quad-based static rendering of environments
    a continuous level-of-detail (CLOD) rendering of height fields as described by Roettger et al [1]
    real-time optimally adapting meshes (ROAM) for terrain rendering
    portal-based rendering of indoor environments
    binary space partitions (BSP) of indoor environments
    potential visibility sets (PVS)
    We will discuss each approach, offering a high-level description of each as well as implementation considerations where appropriate. Finally each algorithm will be discussed in terms of its application in modern graphics system before we conclude the article.

    2. Concepts in Graphics Rendering
    This section offers a broad overview into several key concepts in graphics rendering. These include the graphics pipeline, vertex representations, scene reduction techniques and graphics models - for a more extensive description we refer the interested reader to Alan Watt's 3D Computer Graphics [2].

    2.1 The Graphics Pipeline
    Graphics rendering is concerned with reducing a scene, a collection of three-dimensional data, to a smaller, visible subset and rendering this subset. To render a scene subset we note that a scene consists of polygons that are usually reduced to sets of triangles for hardware rendering purposes. The rendering process goes through a graphics pipeline during which the vertices of a triangle are transformed according to the current point-of-view and then projected from world space onto screen space according to the viewing frustum. The point-of-view determines the position and direction from which the world is rendered, while the viewing frustum determines the scope of the field-of-view (FOV).

    After transformation and projection the triangle is lighted (meaning lighting calculations are performed on it) and clipped (meaning only visible parts are drawn) and then finally drawn to the graphics buffer. A number of approaches can be adopted during the drawing of the triangle, such as wire-frame only, solid, textured and bump-mapped.

    Wire-framing only renders the lines connecting polygon vertices, solid renders color information only, texturing uses bitmap or procedural data that is projected onto the polygon, bump-mapping textures the polygon and utilizes some form of shadowing technique that creates a sense of depth to the image.

    2.2 Vertex Representation
    The triangle vertices used during the graphics pipeline can be represented in a number of ways, the simplest being a triangle-list. A triangle-list simply stores the vertices in sets of three, corresponding

    • Honor among nerds (Score:1, Insightful)

      by Anonymous Coward
      I'm always so amused when the link contents are posted by an A.C. It's like "Huzzah! Yes, there is honor among nerds! I don't want mod points for this - I want to earn them on merits of my own original posts!"

      For the socially retarded among you, the amusing part of that is that anyone actually cares enough to bother!

  • Huh? (Score:2, Informative)

    by JohnGrahamCumming ( 684871 ) *
    Perhaps I missed "Graphics Algorithms 101" in a previous /. article, but after reading (or trying to read) TFA my response is: wibble.

    John.

  • What happened to the days of... (Score:5, Funny)

    by SavedLinuXgeeK ( 769306 ) on Tuesday May 11, 2004 @11:18AM (#9116898) Homepage
    for (int x = 0; x 320;x++) for (int y = 0; x 249; y++) drawpixel(x,y,data[x,y]) What ever happened to the simpler times...

  • Refresh...? (Score:5, Insightful)

    by Ghoser777 ( 113623 ) <fahrenba@NOsPAm.mac.com> on Tuesday May 11, 2004 @11:19AM (#9116914) Homepage
    I hate when something is called a refresher course when it's something I never learned to begin with...

    Matt Fahrenbacher

    • Re:Refresh...? (Score:1, Funny)

      by Anonymous Coward
      by calling it a refresher, it will be 'ok' if its a dupe. maybe they are just covering their tails in case they feel it might be a dupe.

  • They forgot TNA (Score:5, Funny)

    by baudilus ( 665036 ) on Tuesday May 11, 2004 @11:20AM (#9116920)
    They for the TNA Algorithm - Tactile Natural Assimilation, for realistic representation of the skin around a woman's Breasts and Backside. This is the money maker, used for everything from Tomb Raider (Lara Croft) to Mario's bulbous (read: breastlike) nose in the popular Super Mario Bros. games.

    An egregious ommision.
    • I wonder what moron modded this interesting?

      I never found lara croft even remotely attractive, even in the latest games with the highest tech engines.

      Now the girls of DOA, that's a different animal altogether.
    • LOL! I can't believe that got an "Interesting"! Gotta love them mods...
    • You need to have a good MRF too. (mamary resonant frequency).

  • What, no Octrees? (Score:5, Interesting)

    by mausmalone ( 594185 ) on Tuesday May 11, 2004 @11:21AM (#9116931) Homepage Journal
    This is the first graphics programming article I've seen in a long time with no visual aids. I think the writer simply wanted to write a huge "smart" article so that he'd seem impressive. Missed some good algorithms for terrain rendering (tilemap, octrees, frustrum culling). If you want a really good site about graphics algorithms, check out Paul Debevec's homepage [debevec.org] (famous for his contributions to The Matrix)

    • Re:What, no Octrees? (Score:4, Insightful)

      by Aardpig ( 622459 ) on Tuesday May 11, 2004 @11:29AM (#9117000)

      The type of problems solved by Octrees are also solved by BSP algorithms. So to put both in the article would have been a little redundant.

    • Re:What, no Octrees? (Score:2, Insightful)

      by farkinga ( 113105 )
      The content of the article aside, its "smart" format is appealing on several levels.

      Among other things, it is a format that is immediately usable. That isn't to say that internet-magazine articles are generally difficult to read, but some are easier than others due to advertising, having the article split into several pages, etc.

      Also, this article is a more permanent statement: it can be referred to in the future, all at once, easily. There really is no reference value to most internet-magazine articles
    • He mentioned quadtrees for terrain rendering.
    • I think the writer simply wanted to write a huge "smart" article so that he'd seem impressive. How can someone write an article on on CLOD without ever mentioning our friend Bezier? If someone wanted to write a "smart" article about graphics programming, he would have been better off writing one on GPU programming.

  • Is H. Fuchs' first name... (Score:3, Funny)

    by Anonymous Coward on Tuesday May 11, 2004 @11:21AM (#9116932)
    Holy?
  • We could have a true-to-life Mars landscape to traverse with these more accurate algorithms. Or, say, ride along the top of a microprocessor that's been nrought to scale with human size.
  • What about the basic things like line drawing, or drawing bezier and other spline curves?

    Not to mention others like arbitrary region management, collision detection with large numbers of objects, and manipulating color data in different color spaces.

    • Well, the first three you mentioned are interesting, if rather pedestrian these days (I mean, you might as well include linked lists in that set. I'm sure they're used in games). As for the remaining ones, collision detection isn't a "graphics" problem, although it's definitely a game-related issue (and an even more complex problem in three dimensions). As for alternate color spaces, what games have you been playing??

  • IAAGD (Score:5, Insightful)

    by MaestroSartori ( 146297 ) on Tuesday May 11, 2004 @11:28AM (#9116987) Homepage
    (I am a Game Developer) and I'm trying to work out why this article was posted. Its too advanced for beginners, its not detailed enough for professionals. Its basically a list of the names & very basic approaches of a few graphics algorithms. I suppose people vaguely interested who know the basics but haven't tried some of these out are the target audience.

    Anyone there fit the bill? Did you like this article? Was it helpful and informative?

    • Re:IAAGD (Score:5, Insightful)

      by XMyth ( 266414 ) on Tuesday May 11, 2004 @11:38AM (#9117084) Homepage

      I suppose people vaguely interested who know the basics but haven't tried some of these out are the target audience.

      For any given subject, that's about 95% of the Slashdot crowd.

      =)
    • Perhaps there are stages between beginner and pro?

    • Re:IAAGD (Score:5, Interesting)

      by BillLeeLee ( 629420 ) <(moc.liamg) (ta) (niugnephsab)> on Tuesday May 11, 2004 @11:51AM (#9117191)
      Overall I enjoyed the article. I'm a complete beginner when it comes to computer graphics, but I'm really interested in computational theory and algorithms and I think I'm pretty good with those subjects (classes I've enjoyed the most on my road to being a CS major are algorithms and mathematical courses for the most part).

      The article touches on many subjects I haven't heard about and I learned what a BSP (binary space partitioning) tree is, at least. Graphics are probably the next thing I'll try to get into, and I still have an OpenGL manual lying around that's only been opened once.

      Perhaps as a game programmer, you'd probably see that it's not as in-depth as you'd want, and it's probably not simple enough to be understood by everyone, but the article caters to, I guess, intermediate level people with a developing interest in computer graphics? Hits the sweet spot with me. ;)
    • I suppose people vaguely interested who know the basics but haven't tried some of these out are the target audience

      Sounds like my normal bedtime reading!
      • this being /. your normal bedtime reading is probably pr0n... you certainly "know the basics but haven't tried some of these [sex] out."

        har har har!
    • i've had an interest in generating worlds from random noise, particularly a network of probabilitsic methods and adaptive systems on top of a complex perlin noise engine. i still havent gotten to heavily into render code though, and i've definately made a backup of this page as reference materials for when i get around to turning my world into an actual optimized engine.

      this seems to be his purpose: reference materials. he brushes upon everything needed to be useful and leaves the details of implementati
    • Okay - I have my Graphics exam at 9am tomorrow. It's 10pm now, and we were told that we must tell the lecturer stuff that he didn't teach us to get good marks (which is bollocks to Uni policy - we checked). This article is a godsend, as I can now talk about BSPs and check the links in these threads to sound more knowledgable in any essay questions.

      W00t! W00t!
    • I agree... this article is nonsense. There are tons of exciting new things happening in graphics, and this article covers none of them. The stuff covered here is as old as Quake, and much of it is probably obsolete on today's graphics hardware. And even if the techniques covered were relevant, there is nothing for the reader to work with -- no sample code, not even a single diagram or even a rough algorithm given. What's the point?
    • That'd be me.

      I messed around with BSPs and Portals a few years ago just for fun. I was thinking that having a look at outdoors techniques might be interesting, and then this article comes along. I admit it probably hasn't done a lot more than saving me the equivalent reading time in googling, but it has been more pleasant.

  • Outdoor environment rendering.... (Score:5, Interesting)

    by old_skul ( 566766 ) on Tuesday May 11, 2004 @11:31AM (#9117019) Journal
    This is a very hot technical issue in gaming right now. The last 5 years have netted us decent techniques for doing network communications for low-latency gaming; with those in place now, we turn again to graphics.

    Tribes [tribalwar.com] and Tribes 2 [tribes2.com] were some of the first games to take on outdoor environments and do them well. Now, we have Unreal Tournament 2004 [ut2k4.com] and Far Cry [farcry.com] leading the pack with gloriously realistic outdoor playspaces.

    It's only a matter of time before next generation gaming engines like these turn to non-linear gameplay such as what's in GTA 3 [rockstargames.com] and we wind up with a world simulation that has a level of realism approaching reality.

  • What about voxels? (Score:5, Interesting)

    by csirac ( 574795 ) on Tuesday May 11, 2004 @11:37AM (#9117070)
    Back in the day, I had a game on my Amiga called "Shadow of the Third moon" [pisle.com], a space flight sim, that used voxels. It was quite a novelty at the time and I only had 16MB RAM.

    Now that even cheap 3D cards have 128MB RAM on them, average systems have 256MB RAM, where are voxels used now?

    google for voxels [google.com]
    • How do you figure average systems have 256MB RAM?

      Average would be 64 or even 32. Average would be the "minimum system requirements" listing on the box.

      No, just because a 256 meg 9800 XT came out does not mean I leapt into my car to replace my month-old 9800 pro with it's mere "128" megs ram.

      Cheap cards have 128 megs too, but it's useless to them - they aren't fast enough to make any real gaming use of it.

      I have a gfx 5200 with 128 megs ram, it cant play anything with any sort of detail and I'm left scr
      • D'oh, I meant average new systems have 256MB. Further, that 256 number was supposed to refer to system RAM, not video RAM. I'd agree with your observations on cheap cards having too much memory. Probably cheaper to increase sales with a bigger RAM number than actual GPU performance.
      • I have a gfx 5200 with 128 megs ram, it cant play anything with any sort of detail and I'm left scratching my head as to why they'd bother putting that much RAM on, I'd glady sacrifice 64megs of VRAM for a GPU with a little balls. I have an old 64meg Radeon VIVO that runs circles around it in many games.

        It's all about fooling the average consumer by having '128' vs '64' on the box'.

        They added too much ram because people tend to think that size is what matters. Since there aren't benchmarks on the bo
    • I think Worms 3D uses voxels. Or so I have been led to believe.
    • www.sensable.com is using voxels for their professional modeling application, FreeForm. There are still issues with resolution and memory usage that limit this tech.
    • Because NovaLogic have a patent on voxel technology [cdmag.com] as used by Comanche Maximum Overkill and Armored Fist. Patent no. 5,550,959 [uspto.gov] Since the 3D graphics pipeline is essentially in the public domain, it's much cheaper to hire an engineer to design a 3D polygon engine that to license the voxel engine.

      • Voxels aren't used because cards don't support 'em (Score:4, Informative)

        by Paul Crowley ( 837 ) on Tuesday May 11, 2004 @01:13PM (#9118253) Homepage Journal
        I used to work for a voxel rendering company, Voxar [voxar.com]. I developed the fastest software voxel rendering algorithm for opaque surface rendering of its time, around ten years ago. It wasn't used in games - and still isn't - because it'll always be a performance loser for gaming applications for as long as PCs include dedicated polygon hardware.

        Comanche Maximum Overkill does not use voxels. I don't know why they chose that word to refer to the heightfields they do use.
    • All current graphics accelerators that I am aware of don't do voxels. They start with polygons, apply transforms to those, apply textures, lighting and such, and then rasterize that to pixels. Well since they don't support voxels, a voxel based game would probably just suck. Graphics cards way outstrip CPUs in terms of crunching power because they are specialised for what they do. However that means that if you don't do things the way they want, they aren't useful and you are back to pure CPU processing.

      No
    • Didn't the pc games "Outcast" and it's sequel use voxels? I believe they did. They also used some skeletal animation and some interesting bone physics so that when my character strafed next to an incline, on foot would be higher than the other, his leg would be bent, and both feet would be in good contact with the ground. I've not seen another game do this, except maybe MechWarrior, but I don't remember.
    • The last high-profile use of voxels would be Master of Orion III...

      Which shows you why no one takes them seriously.

  • comp.graphics.algorithms FAQ (Score:5, Informative)

    by j1m+5n0w ( 749199 ) on Tuesday May 11, 2004 @11:50AM (#9117183) Homepage Journal

    This is one of the best collections of graphics algorithms on the net I'm aware of:

    comp.graphics.algorithms FAQ [faqs.org]

    Another favorite of mine is Ray Tracing News [acm.org], but there haven't been any new issues in a few years.

    What other people's favorite collections of algorithms?

    -jim

  • Not advanced! (Score:5, Informative)

    by Junks Jerzey ( 54586 ) on Tuesday May 11, 2004 @11:51AM (#9117196)
    This stuff isn't advanced, it's basic. It's more a refresher course on fundamental methods of organizing scenes. There's nothing difficult or amazing about portals, for example. In fact, much of the tech outlined in the article is outdated. Portals and BSPs (for rendering, not collision detection) are of much less use than they used to be. This quote shows that the author is just reiterating Quake-era views and hasn't written a modern renderer: "BSP trees are supremely efficient in rendering indoor environments." This is completely wrong. On a modern graphics card, it's much faster to throw the scene at the GPU and it let it render it all than it is to iterate through a BSP. Much faster.
    • I've not read the article but:

      Portals and BSPs (...) are of much less use than they used to be

      Hmm, Doom 3 makes extensive use of both - that's fairly current tech eh? :)

      • Re:Not advanced! (Score:3, Interesting)

        by Junks Jerzey ( 54586 )
        Hmm, Doom 3 makes extensive use of both - that's fairly current tech eh? :)

        Doom 3 does not use BSP trees for rendering. Neither did Quake 3. It uses BSP trees for other things, like collision detection.

        "Portals" used to mean something other than it does now. You used to clip polygons against a portal, because this was faster in software. Now you just say "please draw the rooms adjacent to the current room." The "clipping" happens automatically on the GPU. "Room based rendering" would be a better te
    • This is completely wrong. On a modern graphics card, it's much faster to throw the scene at the GPU and it let it render it all than it is to iterate through a BSP. Much faster.

      That's because the graphics card is doing some kind of spatial partitioning itself. BSP (or stuff like BSP) is still very useful, it's just going on in hardware now.

      I agree that there is nothing "advanced" to be seen here.

      Whenever this topic comes up, I make sure to point out the following: the amazing graphical techniques we

      • Re:Not advanced! (Score:1, Informative)

        by Anonymous Coward
        That's because the graphics card is doing some kind of spatial partitioning itself. BSP (or stuff like BSP) is still very useful, it's just going on in hardware now.

        The technique is called Deferred rendering [firingsquad.com]
    • Ok, and what does the GPU do? Let me guess ... maybe using one of the well known algorithms? Ah, no, can't be, they are all outdated ... Ah I know: The GPU just throws it at the GPU ...

      • Re:Not advanced! (Score:4, Interesting)

        by Junks Jerzey ( 54586 ) on Tuesday May 11, 2004 @02:43PM (#9119190)
        Ok, and what does the GPU do? Let me guess ... maybe using one of the well known algorithms? Ah, no, can't be, they are all outdated ... Ah I know: The GPU just throws it at the GPU ...

        The GPU just transforms vertices and draws triangles, plus it runs per-vertex and per-pixel shaders. It does nothing involving scene representation or high-level culling. It just draws everything you throw at it.

        BSP trees--for rendering--were useful back when there was a massive expensive involved in rasterizing each triangle on the CPU. You never wanted to draw a triangle, then have another one completely obscure it. But with modern graphics cards this is irrelevant. You just pass a bunch of pre-packaged vertices to the graphics card and it does the rest. You never want to break things down into individual triangles.

        So, no, the GPU doesn't use one of these "well known algorithms."
        • Yes, but surely you still want to get rid of some of the higher order structures. Maybe you don't want to care about individual triangles, but you don't want to draw parts of the world that are in a totally different room. Even with early Z rejection, depth complexity can be a killer.

          And when it comes to complex meshes, it certainly makes sense to decide whether you can actually see the object before calculating several hundred vertices.
          • I'm going to come right out and say it... I'm not the best graphics programmer out there... not even mediocre.

            Now, with that out of the way... I'd like to ask a few questions:
            Whatever happened to the Kyro II? I heard it was real good with ZBuffer stuff... complex landscapes and cityscapes. I also heard that the technology lives on in some form or another - tile based rendering?
            You can draw complex landscapes with today's GPU's without passing in triangles/fans/strips/lists?
            What would be a top reference r
    • On a modern graphics card, it's much faster to throw the scene at the GPU and it let it render it all than it is to iterate through a BSP. Much faster.
      Right, but hardware is not a magic obscure thing that does anything amazingly fast. Advanced graphics cards do use algorithms that are interesting to learn about.

      • Re:Not advanced! (Score:4, Insightful)

        by Mskpath3 ( 764785 ) on Tuesday May 11, 2004 @11:31PM (#9123798)
        No, but the point he's trying to make is that scene organization works at a differerent 'magnification' (for lack of a better term) these days. Back in the days of Quake 1 and Carmack's zero-overdraw schemes, there was a premium on every triangle and every pixel that had to be processed.

        Today, the issue is significantly different. Consider an old 'gigapixel' card. 1 billion pixels per second at 60 frames per second == 16.6 million pixels per frame. Even at 1600x1280 there's only about 2 million pixels onscreen at once. What does this tell you? You can now afford to sink some time into overdraw because it just doesn't matter.

        Also, consider the fact that 1600x1280 == 2.04 million pixels onscreen. Even if you draw a single polygon per pixel @ 60 hz, you're still only looking at 120 million polys/second. That's going to be a pretty reasonable number for next-gen hardware (Xbox2). What does this say? Well, unless you really need 1 poly per pixel, you can afford to draw some extra polygons.

        Now, let's say you've got a scene with 10,000 discrete objects. This is a pretty reasonable number these days. Even on a 3ghz processor, doing distance-to-plane checks for plain jane frustum culling is pretty darn expensive when done 10,000x per frame. Multiply that number by some constant C to do N world space occlusion checks. All of a sudden you're sinking multiple milliseconds into just doing scene graph traversal. Don't forget, you only get 16ms per frame @ 60hz. PVS on triangle strips or individual triangles? Teehee - you'll spend forever trying to process all that crap. Throw a simply quadtree or octree onto a scene, and cull at the object level (where object == say, 1000 to 10,000 polys). Let the video card deal with the little bit of extra overdraw and wasted polys. Point is, -you- have saved, say, 4+ milliseconds of raw CPU time. 4ms is a lot. Send that extra time to Havok or Karma. Send it to a fancy effects system. Don't waste it doing needless old-school culling. Don't forget, if you're doing things right, the 'rendering' is really just DMA slinging verts and textures in the background to the GPU. Paralellism with the GPU. These mega hoopdeedoo X800+ cards can deal with a little excess load.

        The point is, these algorithms are most decidedly not advanced. They're from 2-3 years ago! Quite literally, that's ancient history in the games world. Ridiculous, but true. The real brilliance of these new generation GPU's is not wacky implementation of bizarre obscure culling algorithms. The brilliance is that they are so powerful, they allow you to spend your programming time implementing beautiful shaders and effects. In 1-2 years, graphics programming will have truly morphed from glorified bookkeeping (managing and organizing data has been the hallmark of the 'hardcore' graphics programmer for several years now) into actual effects and shader programming.

        I cannot wait until dicking with exporters and preprocessors, and goofy custom renderers are a thing of the past. With some clever planning, graphics peeps will be able to really sink more and more time into making things beautiful, instead of being forced to be excessively clever to make things happen. There will always be room for 'real' advanced stuff (like modern GPU + CPU shadow techniques, spherical-harmonic lighting, and other esoterics), but the power of these new cards lies in freeing up graphics programmers to actually write graphics code instead of being accountants. That's the real practical results of this next generation of hardware :)

  • no graphics in the article! (Score:4, Interesting)

    by hqm ( 49964 ) on Tuesday May 11, 2004 @11:53AM (#9117219)
    There was not a single illustration in the article. That is kind of ridiculous.

  • I don't mean to troll ... but: (Score:2, Insightful)

    by Anonymous Coward
    This article is like the 10,000,000-foot view of these things.

  • blink (Score:1)

    by wheel ( 204735 )
    Man my 'advanced graphics algorithm' basically stops at 'thou shalt not blink' -- and I forget how I even did that.

    400 poke(32768 + pos +1, 219)
    410 poke(32768 + pos, 32)

    or something like that.

    (now I'm all grown up and all I do is database and web app stuff)
  • Alright! AGA! [emugaming.com]

  • Refresh? (Score:5, Informative)

    by LoreKeeper ( 778912 ) on Tuesday May 11, 2004 @04:22PM (#9120165)
    Heya :)

    I'm the author of the article. So I guess I can explain a few things.

    Originally the article was written 3 years ago as a technical report for a small course I needed to do. DevMaster found this work and asked me whether they could make it available.

    The course took place over 8 weeks, covering each algorithm in a week - and 2 weeks for the report at the end. The actual course work is still accessable at

    http://www.cs.sun.ac.za/~henri/advgfx.html

    And includes pictures and sources to keep everybody happy. ;)

    To those that are uncertain who the intended target audience is - well, originally my supervisor... ;) - hence the somewhat formal and academic style; however, in its current form as an article on DevMaster it is intended for intermediate readers. Those that look for some additional insight into (spatial) graphics algorithms. The article isn't a tutorial and (given its history) is not bothered with technical details, however, it does make reference to useful starting places for those that wish to explore the matter some more.

    Although I agree - pretty pics would've been nice. ;) Those that really need them should go to the website.

    The choice of algorithms reflects not the state-of-the-art, nor the best approaches to solving graphics issues. The algorithms were, however, easily accessable to me at the time - and hence featured in my one-algorithm-a-week plan.

    Somebody mentioned that BSPs are outdated, this isn't true - though they have been around for ages, they are still the work-horse for most indoor engines around. Sure, BSPs are rarely used for the actual rendering process (as mentioned in the article), but in terms of processability of spatial organization they are hard to beat.

    I stand to be corrected but I'm rather sure Doom3 makes use of some form of BSPs as well. That should be good enough for anybody.

  • The title "advanced graphics algorithms" is highly misleading. These algorithms are only really any use for real-time 3D graphics, which is a fairly small subset of computer graphics in general.

    Admittedly, it happens to be an area that's worth a fair amount of money these days (i.e. games), but if you're considering it as a career, the deadlines are tight, the hours are lousy and the pay isn't great. Consider another area of advanced computer graphics instead.

  • what? no pictures?
  • Please excuse ontopic post.

    Article describes basics of ROAM algorithm, I am familiar with it, and I finished coding it long ago. I am aware of fact that ROAM is very CPU intensive, and everyone say that "ROAM should not be used today".

    Has anyone tried ROAM 2.0? [cognigraph.com]?

    I was searching for any other documents related to new ROAM version, but failed, I am still not sure how "AGP Chunking" really works (picture of triangulated patch would help much) and how to fast operate on diamonds (instead triangles). Could yo

Slashdot Top Deals

BLISS is ignorance.

Close