|
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.
SEND ME MAIL
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.
|