flipCode - Tech File - Conor Stokes [an error occurred while processing this directive]
Conor Stokes
(aka DirtyPunk)
Click the name for some bio info

E-Mail: cstokes@crytek.com

   05/12/1999, A Couple O Things

Waves and there relevance to a games engine

I think it is possible that many people have referenced using waves previously, for reasons that will become obvious. But, it seems that not many people building engines recognise waves relevance. Water isn't the only thing that is effected by waves. Look at light (pun), light is waves. It has the property of reflecting at the angle of incidence.

I think I will probably write a wave sphere segment engine to simulate some of the effects often found, like explosion damage, some lighting effects to be precalculated, and sound. Hmmm.

Claustrophobic Irony's Lighting

Maybe I should explain a bit about this, as I have a few things going that are pretty different. One of these is knowing the difference between direct diffuse, semi-spectral, full-reflective and in-direct diffuse surfaces. The all diffuse surfaces I was thinking of two ways to pre-generate. One would be lightmaps, the other lighting of vertices by splitting a surface into a quad-tree. Both have benefits. I was going to use complexity and wavelet size to determine what size would be best for a map. A more complex map for a larger surface would be big. A very linear map, or very gradual color shift map would be smaller. This would be altered for the quadtree idea, to cater for adaptions in a full surface. The quadtree has a couple of advantages:
  • It doesn't need a second pass in hardware (big allows for detail mapping and such on low fill cards.
  • Can have adaptive complexity.
  • Dynamic lights are quick to add, and spectral lights can be dealt with (sliding high-lights) quickly.
  • Shadows can be added in realtime.
  • It can be cached in software, just like texture mapping.
  • Doesn't take texture memory.
  • Good for vertex array calls, and always in easy fanning/strip form.
  • It may be possible to reject parts of the polygon using my vis system.
  • Probably no multi-pass banding.
  • Possibly allows for pseudo displacement mapping ;-)
  • Disadvantages
  • Needs extra geometry sent down the bus (Which strangles memory copy, but that is slightly counter balanced (definantly not fully) by skipping lightmap upload).
  • I think by loading all the lightmaps into bigger textures, you can get larger download speeds, but Q3:A has a large geometry rate, so I guess it would be alright.
  • Needs CPU based perspective projection.
  • Lightmaps have a couple of things too:
  • Can be much smaller, or easily compressed.
  • Probably less data
  • Might be better down the bus.
  • Can be cached
  • Disadvantages:
  • VERY VERY slow for dynamic operations
  • Requires extra passes
  • Can't make for part culling
  • Requires texture memory and texture handles
  • Non-adaptive
  • Multi-Pass banding.
  • Some cards don't have a full range of blend modes
  • Doesn't allow displacement mapping
  • Yet another pass will need issuing for spectral lights, unless I use very spaced vertex lighting, which wont look as good. It would make for more texture usage too, if I used mapping.
  • So I will probably go with the Quadtree.

    CI Visibility

    On yet another note, maybe I should say what the latest incarnation of REMPES is. Basically, I am using an advanced version, with more memory friendly features, of the system I suggested last time, with an octree + beam test, which uses a similar theory to a beam tree, but does a single beam at a time. The octree + beam test, which I was going to use for all vis purposes, culls and provides for the perfect set, aswell as allowing for large dynamic modifications of the world.


    I am not getting enough feed-back on the suggestions made. I get one or two, but I don't get many. I don't mind people asking about CI (I should have a very early demo out in two weeks, probably without software or texturing, but a general test of the transform and lighting system). It will be OpenGL based. My latest ICQ is 34777518, under DirtyPunk. My sister took one of my UINs and the other is on a dif machine.

    Conor Stokes (aKa DirtyPunk)

    Quote: "I took your car, and I rammed it into a wall. I had fun and thats all that matters." - >From the TV show, Father Ted.

  • 12/29/2000 - Techfile From Somewhere Different
  • 10/10/2000 - Some Fun, And A Cameo Appearance
  • 08/10/2000 - Déjà vu - And I've Done It Before
  • 07/08/2000 - Various Loose Ends To Hang
  • 05/15/2000 - The Way To Hit A Ball With A Bat. Or Not
  • 03/28/2000 - The Fine Art Of
  • 02/13/2000 - A Life Time of Learning, Teaching and Eating M&Ms
  • 12/09/1999 - Strangeness And Wondering If You Are Taking Innovation A Tad Too Far
  • 11/12/1999 - How to Break Exam Tension? Update Your Techfile
  • 09/14/1999 - Lots of Ramblings, personal things and comments on why SNFU
  • 08/23/1999 - Trials and Tribulations of Being Cerebrally Defunct
  • 07/29/1999 - Quick Update about Stuff and Things
  • 07/25/1999 - I'm Back Baby
  • 07/01/1999 - Is it so? Or am I just a Psycho Babbling Mental Hobo, who's Brain has No Home?
  • 06/25/1999 - Another Couple of Things
  • 06/17/1999 - I Am A Naughty Little Boy ;( But I Have A Way To Make Up
  • 06/16/1999 - What the hell? A new data structure for visibility? I don't know, I haven't heard of it.
  • 06/05/1999 - A Little Right Brained
  • 05/12/1999 - A Couple O Things
  • 05/08/1999 - Pre Computable Nice Visibility Sets
  • 05/04/1999 - More on Volumetrics
  • 04/30/1999 - Generic Update
  • 04/27/1999 - Spherical Volumetric Rendering (Mapping)
  • 04/25/1999 - Fractal Curves, Emulation Of Nature
  • 04/25/1999 - Claustrophobic Irony Level Loading and Manufacture
  • 04/24/1999 - Visibility Ramblings
  • 04/21/1999 - Why Software Rendering Is Not Dead
  • 04/17/1999 - Optimizing For Specific 3D Hardware

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]