Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Andrew Harvey, posted on November 30, 2000




Image Description, by Andrew Harvey



This is my entry for the OpenGL Challenge, Gears Challenge. I tried to come up with something original and eye catching, with TnL friendly ("clean") OpenGL.

The oglchallenge website seems to be down (?), so "oh well maybe next time".

Some of the code is messy, with plenty of magic numbers.
Some of the code is (IMO) nice & clean.
Comments are for quiche-eaters (Mmmm... quiche).

Download:
http://www.users.bigpond.com/a_j_harvey/gears/gears.zip (193Kb)
http://www.users.bigpond.com/a_j_harvey/gears/gears_src.zip (75Kb)

Features:
  • Display lists (see Note).
  • Fast, fake env-mapping using texture matrix. Fast, fake Phong shading with env-mapping.
  • Interesting blend mode glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). It doesn't saturate as quickly as GL_ONE/GL_ONE. To be honest, its not much different to GL_ONE/GL_ONE at all :)
  • Skydome stars.
  • Billboard particles. They really chew fillrate.
  • 100% procedurally generated meshes & textures. Exe is only 61Kb without C Runtime.
  • * Note: I'm using glGetFloatv(GL_MODELVIEW_MATRIX) several times per frame. This won't be TnL friendly unless the driver keeps a matrix stack in software. If the driver didn't maintain a software stack, it would be very easy for the app to do this.

    Andrew Harvey
    http://www.users.bigpond.com/a_j_harvey
    a_j_harvey@hotmail.com


    [prev]
    Image of the Day Gallery
    www.flipcode.com

    [next]

     
    Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
     
    Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
     
    Khrob

    November 30, 2000, 11:36 AM

    Funky shot!

     
    Patrick Lönngren

    November 30, 2000, 11:54 AM

    I tried the demo - and it's not just a funky shot. It's a funky demo! Makes you dizzy after a while though

     
    bit64

    November 30, 2000, 12:15 PM

    Could you expand on your comment about the driver keeping a matrix stack. It seems you have contradicted your first statement about it with your second statement. I don't really have a clue about any of it though, so maybe some more info would calrify things.

    Nice screenshot. Are the gears generated procedurally or are they modelled? If they are modelled what format are you using?(.3ds, .lwo etc)

     
    D3stY

    November 30, 2000, 12:39 PM

    Yooz.. great job... and funky! :)

     
    sagacity

    November 30, 2000, 12:55 PM

    bit64: To answer your question "Are the gears generated procedurally or are they modelled?" I will copy and paste a bit from the author's description on the top of the page:

    "100% procedurally generated meshes & textures."

    Have a nice day :)

     
    fluffy

    November 30, 2000, 01:23 PM

    bit64: What he means by the matrix stack statements is that if the driver didn't maintain a software mirror of its hardware matrix stack, then there'd be somewhat of a performance penalty in fetching the matrix out of the card's registers. However, the simple workaround would be for the application to maintain the matrix stack, rather than relying on OpenGL. This is actually a very good technique to follow anyway, since it helps you to abstract your renderer away from the underlying API (for example, I do this in my own renderer), and it also lets you defer uploading your matrix to the last possible moment, which can theoretically help out parallelism between the application and a hardware TnL graphics card.

    Really, glGet*() should be used as sparingly as possible, if at all, since it can only be efficient on software OpenGL implementations. :) It also really slows down things on network-transparent implementations (such as on UNIX) because it's not an asynchronous, non-blocking command - it has to wait for a response, and this causes stalls. In the worst case (getting a portion of the framebuffer or texture memory) it pretty much HAS to wait for the current queue of operations to finish, meaning that any command buffers will have to be drained before the response can be formed.

     
    bit64

    November 30, 2000, 03:09 PM

    Not to be nit-picky, but 100% procedurally generated meshes and models, does not mean that ALL the models are procedurally generated, but that the ones that are, are 100% procedurally generated. Thanks for your wonderful insight though, and you too have a nice day.

     
    bit64

    November 30, 2000, 03:09 PM

    Thanks fluffy for explaining that to me. Makes much more sense now.

     
    sagacity

    November 30, 2000, 03:27 PM

    Damn, a loophole! :)

     
    bit64

    November 30, 2000, 04:28 PM

    What is up with your webpage, it says I have a get in Free coupon but it wont let me in!!!!!!
    By the way, I think theres a bug in your system, because my name's not Stevie.

     
    a_j_harvey

    November 30, 2000, 05:19 PM

    Yeah, I agree. Thanks for the great answer, couldn't have put it better myself!

    I'm sure I remember the subject being mentioned in a nvidia/geforce interview/doc, which is why I asked.

    I actually did have the matrix stack mirrored in software, but it turned messy code into really messy code. All the matrix stuff is done twice for the texgen, and 3x was a bit overboard :)

    One reason for doing it the way I did was that its driver independent. I remember the 3dfx minigl used to do its matrix stuff "transposed" as compared to everyone else, which causes you grief if you're directly glLoad'ing or glMult'ing. ALthough, in the end this didn't save anything, because I needed the matrix stuff in gl order, which matches my matrix class & drivers these days tend to follow the spec more or less.

     
    a_j_harvey

    November 30, 2000, 05:23 PM

    Thanks for the comments :)

    BTW, anyone run it on a gf2 or something? Its mainly fill-limited, and I'm wondering 2 things:

    1) Does the matrix stuff kill hw?
    2) Higher framerate = more spark things -> what does it look like at a couple of hundred fps?

     
    a_j_harvey

    November 30, 2000, 05:28 PM

    Oh, I forgot...

    Obviously, the "proper" / "nice" way to do things would be to use glRotate/glTranslate rather than glLoad/glMult. Its just that a dozen matrix ops or so is a bit for one textured quad!

    OR

    You could draw the sparks for each gear at the same time as the gear, but that would mean glBind'ing the textures more often that was necessary.

     
    shrike

    November 30, 2000, 06:47 PM

    I like it. Hypnotic.

     
    Scrambled Monkey

    December 01, 2000, 01:06 AM

    Runs like a bat out of hell on my pIII 866mhz gf2 system. The gears were quite a ways back though, small on the screen for some reason... The particles streamed out pretty much as close as they could.
    Dan

     
    a_j_harvey

    December 01, 2000, 01:52 AM

    Maybe "camera, far" or "camera, fov" ?

     
    Scrambled Monkey

    December 01, 2000, 02:52 AM

    Doh! I ran it from the zip, I didn't realize the *.cfg file... Ok, I ran it at 1024x768x32 with 512 textures, still ran like a bat out of hell with lots of sparks flyin by. Cool stuff.
    Dan

     
    malkia/eastern.analog

    December 01, 2000, 05:32 AM

    Prodigy is back...

     
    Peter Mackay

    December 01, 2000, 06:40 AM

    Hi,

    Very nice! I like the grey stars the best :-)

    Although, I've noticed that on my machine (running Windows NT 4), if you quit the demo using ALT-F4, it stays running and eating processor time, although it isn't displaying anything. Task manager ahoy!

    - Pete

     
    fluffy

    December 01, 2000, 12:04 PM

    Wait, are you doing per-quad geometrical ops on the sparks? That's pretty crappy. Either way, there ARE times when it's easier to just calculate the worldspace coordinates explicitly. :) I mean, it's not like the various Pyro-type screensavers use a matrix stack for drawing the lines of those sparks... :)

     
    Phillip Jordan

    December 01, 2000, 04:11 PM

    Works perfectly at 1152x864, 32bpp, 512x512, 32bpp textures on my Thunderbird 800, Voodoo 5 5500. Didn't work at 1280x960 though :(

    Are you going to make a screen saver from this? :)

    JQ

     
    a_j_harvey

    December 04, 2000, 01:26 AM


    Hehe, yep.

    1) Time. I knew it would just work with matrix ops / spark

    2) T&L. I was thinking that sending a matrix to the card & and calling display list would be nice & fast & cpu friendly. Obviously this is very driver dependendent, but in a perfect world...

    Once again it was mostly a matter of time. The matrix was there for the glGet'ing, so...

     
    a_j_harvey

    December 04, 2000, 01:28 AM


    anyone got a screensaver skeleton ?

    anyone care about a screensaver (I suppose you do :) ?

     
    a_j_harvey

    December 04, 2000, 01:33 AM


    Oops, I'm only checking the ESC key. I'm not processing WM_QUIT. In fact, I'm not processing any messages, they all get chucked.

    Alt+F4 closes the window but not the app.

     
    This thread contains 24 messages.
     
     
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.