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

   06/25/1999, Another Couple of Things

First of all... If you read this, you may think, hmm some interesting ideas. I hate to be a p1mp, but having a techfile, and filling it with such (possibly useless) information actually generates interest, some of which you may find very nice. I have had a few games job offers (please remember I am an Australian, US jobs are out of the question, unless they are small advisory ones), I have had a "off the record" discussion with a IT journalist from an Major Paper in Australia, although I think that was more of a Crystal Space thing. But I do say, keep it coming ;-) Comments always welcome at cstokes@tpgi.com.au. THIS MEANS YOU!

Second, I have created a new 3d theory mail list, pro_3d_theory. This is not a newbie, comp.graphics.algorithms style list, this is for people who know what they are talking about. It is about getting a tighter net community of 3d coders. And, if you are a newbie, you will see the much dispised "trickle down" effect. Eg Things discussed on the list come to you, filtered, optimised, purged and laundry fresh (I love the smell of Napisan in the morning ;).

What this list IS for is for people with good 3d theory knowledge to have a supportive environment in which they can announce ideas/algos and get comments, analysis and be told the pros and cons of the idea. Also commentary, help with new personally developed algorithms and such.

We already have some very talented people on the list (Some of them People who have techfiles here) and we already have the odd new idea floating around, and it isn't even a week old ;)

The list subscribe address is pro_3d_theory-subscribe@onelist.com. The send address is pro_3d_theory@onelist.com. Guess the unsubscribe address (no, no, not cheese_and_biscuits@boring.com)... pro_3d_theory-unsubscribe@onelist.com .

Got that? Good. You never know who is watching these things. Maybe we'll end up with John Carmack on the list, (although if he is reading these pages, why hasn't he written and slammed me as a CrackPot yet?) or something equally as much that would make you take the list as high farce. Speaking of which, I approve the subscriptions personally, so I know who is joining. Don't think I am stealing your soul, more that I am gaining the right to send you crappy mails selling photographic mouse pads.

Anyway, enough of the Tom-foolery. On to the Tom-TechfilesStuffery...

I got the night alone tonight and I plan to get the compiler for the potential set, octree and mini-bsps up to a high and mighty level of near working. I plan to add some visualisation of the compilation process in. Although, I probably wont for the potential set calculation. Far to slow. Martin seems to think the system will take forever to calculate. The way I am calculating it, it should hopefully be at most 1000 cycles per test. At the number of tests that will happen, this should mean less than a minute on a 400mhz machine for MASSIVE sized 200000 polygon world, would take around half an hour, without optimisations. I am hoping to push the level down a whole lot. Especially considering the new systems I have worked out, and the special easy optimisations you can do ;-) I may even get to hand tuned assembler level if I think it is still too slow.

Notice, that having a rather fast secondary culler, we can use non-potential levels, and make the worlds very dynamic, without the need for visibility compilation. Infact, at this speed, the levels could be loaded in RAW form and simply compiled at load time. Around a 20 second wait at maximum. But, the potential set should push the triangle rate up by a reasonable amount, making more detailed worlds with many static components, such as Q3:A style maps much larger.

My potential set does have a limit, just like the quake(x) ones, but my limit should be a lot higher. Quake 3's one is still only 30000 polygon worlds (at potential level, more in the game of course). The interesting thing is though, that my set will work for much more generic scenes, should compile faster and most probably alot more accurate in some favourable circumstances. Although, notice the secondary culler will take up the slack, and pump out a honed set.

In moving to the c-buffer/octree node + large occluders beamtree test sets though, there is one thing I am worried about. In a plain beam test with hierachy culling, down to the polygon level, I could get the perfect set, although slower without doing any rotation or perspective transforms, let alone a full polygon setup.

I mean, in an engine with a software renderer this is a big plus, and virtually free. In an engine aimed at hardware, such as CI will probably end up being (software is less appealing... SGI's win Dll may offer a last hope) we can say much of this will be wasted. Triangle setup happens at hardware level on any card less than 2 years old. New cards will introduce transform and rotation acceleration. As it is, most OGL ICDs are 3dNow, and soon Pentium 3 optimised, and probably faster than the stuff I could write, with out spending much of the time optimising these things, and neglecting things like lighting.

This is the main reason I am keeping the large occluders beamtree. The tests are fast, and it saves rotation, perspective projection, polygon setup and c-buffer setup. This is a lot considering the polygon will not be rendered. That a reasonable percentage of the invisible polygons will be saved from this process feels good.

Lighting is another thing I have been scrutinizing. The system I have previously mentioned, I am defining, and it should be possible to see some realtime dynamic soft shadows. And not just crappy dark blobs on the ground. Multiple shadows, corresponding correctly to the lights, harder when closer to the shadowed surface, softer further away. Harder when the light is close to the surface, soft when the light is further away. A slight shadow mask using an alpha blended extra pass, when the surface is close to the camera is something I have considered, but dropped. The LOD should be enough.

Conor Stokes (aKa DirtyPunk)

"He sits and stares and looks up At the crack lines on the cieling Nothing moves, not even him

He thinks of friends and wonders why They seem to have such better lives And He feels so left behind." - Snfu, "The Great Mind Eraser" from "Something Green and Leafy This Way Comes".

  • 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]