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


Submitted by Tim C. Schröder, posted on August 18, 2001




Image Description, by Tim C. Schröder



Well, I thought it's time to share some new pics from my current engine. Basically it is a GeForce 3 optimized FPS engine, with 100% dynamic lighting as the main feature. All the shots you see here have a preprocessing time of 0ms, except the 500ms for the Octree during the level compilation;-) I tried to get the lighting model working on GF1/GF2 cards, but I failed. Not possible. At least it screams on the GeForce 3. Well, I guess you want to see the feature list, here it goes:
  • Vertex.. ahh... SMARTSHADER(TM) for basically every triangle on the screen
  • Pixel shaders for the entire lighting
  • DOT3 diffuse + specular per-pixel lighting on every surface (Well, not on the skybox...)
  • Per-pixel normalization cubemap or pixel shader normalization for every surface
  • Tangent space setup done by vertex shaders
  • DOT3 self-shadowing
  • PPA for every surface
  • Realtime general shadow solution, everything shadows on everything including on itself
  • Colored lights
  • Blinking, flickering and pulsating lights through a shader definition file
  • Lights can be assigned to splines
  • Detail texturing
  • Hyper texturing
  • Advanced vertex buffer optimization code to gurantee best T&L performance
  • Light flares + coronas, implemented through vertex shaders
  • Ellipsoid based collison detection / handling
  • Realtime in game light editor, modify every aspect of the lighting without any reloading
  • Configuration system allows you to change basically everything without any code rebuild
  • Basically any damn 3D feature in the world. If it is not supported yet, it will be in the future
  • The engine is incredible CPU limited at the moment, this is my main problem. Rendering brute force is sometimes even faster than performing HSR. I can render 4 quad texture passes without much drop in performance. The CPU code isn't sooo unoptimized, but the GF3 is card that handles everything you throw at it and just screams for more, so my crappy 700Mhz machine can't keep up.

    If you are interested in a discussion about realtime lighting algorithms, you know my mail. Note: A discussion is a conversation between to similar skilled people that learn from each other. So please no "Teach me how to do this !!!" mails. I'm quite busy with my work and writing my engine, so really no time for tutorials / explanations, sorry ;-(

    Anyway, comments welcome.

    Tim C. Schröder


    [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.
     
    Aphex

    August 19, 2001, 05:54 PM

    The point is, essentially, that "revolutions" such as the GF3 happen every 2 or 3 years... the voodoo2 was as revolutionary as the GF3 in its day, the Geforce was also the shit. Hey, my good'ol Sinclair ZX Spectrum was even more revolutionary as all Geforces put together. A computer for under $300!!!

    Being too enthusiastic in one revolution is the best way to be swept away when it fades out. That's what your comments and style made me think. Keeping perspective is the key to survive and improve.

     
    Aphex

    August 19, 2001, 05:58 PM

    and I forgot a second point which is that today's engines, ANY of them, are light years away from being even *slightly* realistic. Get out of those spaceships and go for a walk in the real world ;-)

     
    L.e.Denninger

    August 19, 2001, 06:45 PM

    > The shadows are very subtle, since every pixel is illuminated by
    > multiple lights.

    Which has totally nothing todo with soft shadows :)
    If you calculate shadows from a point-source light, it'll always be hard shadowing.
    Doesn't matter if you add 3 other point-lights - what you need for soft shadows is not more lights but lights with a radius / arealights.

     
    tcs

    August 19, 2001, 07:03 PM

    You have some major problems ;-)

    A V2 is just a faster V1, no difference. A GF3 is an entire new architecture which is completely programmable. Obviously you did not really evaluate the gfx developmet of the last 5 years.

    Sinclair ZX Spectrum, well, looks like you are another one of these "everything new sux" guys. Well, join a large community ;-)


    I think the GF3 is a major breaktrough. The GF1 already was pretty cool, but just like the TNT1 it was just much better, not a real revolution.

    Don't worry about me, I can easily adopt to any future producst at I'm happy to see what comes.

    Well, you seem to be the kind of person that can't. Always living in the past, yous crying about the limitations of current products. I can't understand people like you.

    Tim

     
    tcs

    August 19, 2001, 07:04 PM

    I know that, of course. All i wanted to say is that you don't have such artifical looking shadows.

    Tim

     
    tcs

    August 19, 2001, 07:08 PM

    I currently use carmacks Z reverse for rendering shadow volumes, works quite nice.

     
    tcs

    August 19, 2001, 07:10 PM

    Well, I love every new and cool HW that allows to do cool stuff. Doesn't have to be from nVidia, but I obviously like NV. That's because we saw a lot of innovation from them in the last years

     
    tcs

    August 19, 2001, 07:11 PM

    And now I became an evil HW addict, yes !!! ;-)

    Tim

     
    Aphex

    August 19, 2001, 07:44 PM

    That comment was just plain fun to read... you go very fast making statements you don't really know anything about like "Obviously you did not really evaluate ..." and putting me in the "everything new sux" group. Hey, I have a GeFORCE3 myself, and bought G256 and GF2 as soon as they came out. I bought my Spectrum also as it became available, and used SGI boxes in their heyday, not today (well, except for some high-end stuff that still rocks). I have probably used all new junk as soon as I got my hands on it.

    So, it's ME telling YOU that maybe certain games belong to the past already, and it's about time to try to make the new technology shine with novel ideas. The Crytek outdoors demo made my jaw drop (and Dagoth Moor Zool. Gardens a while back). The Geforce3 is ground-breaking. In fact, so groundbraking it deserves some NEW games, don't you think?

     
    Warren Marshall

    August 19, 2001, 07:52 PM

    Software rendering isn't the future. That's why we have hardware to do it now. Free up the CPU to do other things.

     
    DirtyPunk

    August 19, 2001, 10:35 PM

    Actually I'm talking about a slightly different case (and I should've said the cylinder only has zero volume parts, it isn't actually zero volume in total). Oh well, a bit late now.


     
    Flous

    August 20, 2001, 05:16 AM

    Even in the days before hardware-rendering, zero-overdraw was considered an utopia, since the cost of overdraw was/is relativly low when compared to the cost for your HSR algorithms. Think about it... If software engines were the really as powerfull as hardware engines, why hasn't someone made this perfect software engine already, I'm sure it would sell bigtime, since nobody _likes_ paying all that money for an overpriced graphics accelerator. Maybe a nice challenge for you software freaks. YOU show ME an engine that can do what this one can... No talk, no BS, just do it, instead of saying it would be possible, or throwing cycle-counts at this guy's head.
    And remember, no crap like "it doesn't render this or that, but that's fine for my project". Anyone ready to accept this challenge? (not counting on it...)

    Greetz, Flous

     
    David Olsson

    August 20, 2001, 07:35 AM

    Actually Im working on just a such algorithm, my version only works with a voxel like object and it wouldn't work for triangles.
    My "voxels" has some very interesting properties which makes it possibles to write a very efficient occlusion algorithm. Atleast that is what I hope.

    But in my opinion, a hierarchical zbuffer together with a octree and fast scanline rutines could do wonders for a software engine. Then you can cull nodes as soon as they are invisible in screenspace in the octree instead of working at triangle level. And it would be pixel perfect. You only have do advanced pixel calculations for visable pixels.

     
    cgk

    August 20, 2001, 08:57 AM

    note: this is just my standpoint based on these screenshots. if i saw the thing in action my oppinion might be different, but so:

    >> The dynamic lights surely look 100x better.

    Well, if you think that. I dont think that your screenshots beat the lightmaps of popular games (although that doesnt necessarily have to do something with your tech)

    >> Just the fact that I can do a per-pixel dot product. Lightmaps lack this because they can't reflect the dp lighting.

    Maybe its just me, but i dont think that dp3 lighting does make too
    much difference for static scenes.

    >> I don't know what your point is, but this dynamic lighting model beats lightmaps easily, even for static situations. I think even in the screnshots you can clearly see how the lighting beats Q3 lightmapping f.e. Because it is ultra-low res and it doesn't take dp3 into account

    Well, i dont see that in the screenshots, but this opinion is based from a aesthetic perspective. It just doesnt feel right - yet.
    I dont want to critisize your tech however, as i said, its kinda cool. But i would not say that it does looks better than lightmapping - at least not in this screenshots.

    Another tech thing: how do you handle curved or "supposed to look round" surfaces? Do you precalculate special normalmaps to reflect to this? how do you handle really big polygons and pointlights?
    These things can be handled very smooth with lightmapping. by interpolating normals and the pointlights on big polygons would not be a problem anyways. But i'm not quite sure on how to do that for dp3 lighting.

    ^that are the main problems that i would face if decided to implement bumpmapping.

     
    Fabian Giesen

    August 20, 2001, 10:11 AM

    Sorry, but "this realtime lighting model" isn't revolutionary, it's just plain old phong/blinn shading, that means it's about 20 years old.

    And please stop with your arrogant-without-a-reason comments, it's not that you invented all that stuff or something like that, you're just (although that still means a lot of work, no question) showing some x000 poly quake map with 5 colored pointlights with simple attenuation and sharp shadows.

    You could've impressed people with this image quality if it was 1993, maybe. But it's just a scene lit by a few pointlights, and it looks *exactly* like that. Maybe it doesn't look as good as your "ultralow resolution lightmaps". Well, who cares - those lightmaps belong to quake2, the game you're using the maps from, but not to the games that are in development right now, which you'll have to compete with if you want to make this a FPS.

    Your dynamic lighting can be done *exactly* that way with every GF2, or, to be more precise, lighting effects like those you do where what nvidia used for marketing of the GF2 chip (you remember, that nVidia shading rasterizer stuff?). And with some modifications, I'm quite sure you could do it on a GF256 (with only two texture stages) too. The only difference is that you program pixel shaders instead of texture stages and use vertex shaders instead of doing the setup in software. That saves you some CPU time, yes - but it still doesn't explain why it would need a GF3. Because people certainly *won't* buy a GF3 just to get what they can get with todays hardware. And if you plan on releasing your game 3 years from now, please, per pixel lighting techniques will be old by then and everyone will be used to them.

    I really don't see your point - yes, you worked some months on this, and it looks nice, and yes, it IS really good for dynamic lighting - but still, it doesn't even come near good static lighting solutions (and please, no one is using these ultra small lightmaps you like to refer to anymore). And you shouldn't be getting so high on the fact that you got a GF3. Sure, it's a revolution in 3d acceleration, it's f**king fast, and it gives you a lot more flexibility than everything before, but please stop being so overly enthusiastic about it. Sure, it's a lot faster than every software rasterizer you could ever write on some generic CPU, but it's also a lot less flexible. Hell, you can't even do something as basic as loops in vertex shaders - which is okay, because there is no reason to support them for a task such as this. But a GF3 isn't *better* than a multiprocessor P3 2GHz system - it's just fundamentally different.

    Comparing a GF3 to a generic CPU is just like comparing a generic CPU to a mp3 decoding chipset - the latter will decode mp3s probably 100 times more efficiently and with a lot less power consumption and clock frequency, but you WON'T be able to do something different with it than decoding mp3s.

     
    Lars Birkemose

    August 20, 2001, 01:16 PM

    You have 600KB of code doing _this_ ????
    _NOW_ im impressed !!

     
    Aphex

    August 20, 2001, 03:53 PM

    IOTD for today (the one with the photon maps) is BY FAR more impressive than that. Ok, so maybe it's not sooo technologically advanced (well, in fact it is as photon maps are *significantly* newer and more advanced than dynamic lights and bump mapping)

     
    Helios2000

    August 20, 2001, 04:38 PM

    'A return to software rendering appears inevitable at some point -- an unavoidable consequence of the technology, but it could easily be 10 years before chips grow so fast that a CPU is able to fulfill all your rendering needs as well, from a user's point of view, as a 3D card.'

    'On the other hand, I'll play devil's advocate here and suggest that 3D cards could increase in generality to the point where they subsume CPU's. If NVidia were able to keep up its "Moore's law cubed" rate of progress indefinitely (ok, an unrealistic premise), then they would eclipse Intel and AMD in the course of a few more years. CPU performance is limited by serial code execution, whereas all components of a 3D cards, even the programmable ones, operate in parallel. To me, it's just as credible that massively parallel computing evolves out of GPU functionality than out of CPU functionality, since CPU architectures are limited by X86 backwards compatibility.'

    Quote from Tim Sweeney, Ask Sweeney, voodooextreme

     
    Tomas Arce

    August 21, 2001, 01:02 AM


    I think he means that with dynamic lights you can get specular and with light maps you can't really get that.

    Good job Tim.

    Are you using some kind of CSG to optimize your shadow volumens?

    Tomas

     
    treething

    August 30, 2001, 04:39 PM

    Very nice IOTD.:) I know this is an old thread, but i have a question!

    "Advanced vertex buffer optimization code to gurantee best T&L performance "

    Are you optimising for vertex cache coherency? Or is it something more cunning?

    Chris



     
    This thread contains 140 messages.
    First Previous ( To view more messages, select a page: 0 1 2 3 4 ... out of 4) Next Last
     
     
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.