flipCode - Tech File - Alexander Herz [an error occurred while processing this directive]
Alexander Herz
Click the name for some bio info

E-Mail: softcore@web.de



   02/11/2000, Tech File Update


On lionhead board there was a quest about bsp tress..and how to avoid splits. I though I could add my answer here...

I thought about the same thing... though I wonder that your hit is that high(50)... you shouldn't clip polys to octree boundarys...unless you realy have goddamn small octree cells you won't loose much by sending em twice..or let's say I don't know any method to avoid it without wasting too many calcs on it...I still develop on a very old machine..on a fast pII or III with good 3d card you go better with not clipping em...

harmless told me that there is something called kd tree producing less splits...and there is some bsp tech which produces far less splits but nobody figured out how to do coll detection with it...I forgot the name...

If you're afraid of huge amounts of data..I guess you think about savin geometry twice... if so..hell why? just let your tree's leafs point on the uncutted geo..and maybe mark polys if they have been already drawn this frame or not...

I'm thinking about using a similar method.. I want to octree my data and then depending on the data in a cell (if all the normals in one cell are roughly equal it can be trated as landscape->lod..otherwise as indoor->bsp/portal/antiportal.. are the normals partially alligned and partially not I'll continue the octree(weighted)... this might even be done realtime...as octreeing is realy cheap(without splitting) and bsping(+portalizing) small cells shouldn't be a prob..and lod/antiportal is realtime anyways... the only thing I'm concerned about is lighting...I still like lightmaps more than goroud vertex..at least for static data..as it looks far better..with fewer polys...

to get around that I thought abou having an empty ligtmap for each face(maybe some kinda quadree thing to be able to increase detail as needed wthout knowing the needed size before(kinda linked list))..now at run time as soon a room or what ever geo set which has lightmaps(I guess for landscape similar lodded stuff I'll use vertex..)come closer to the user's view(not inside it...yet!!) I'll start with building bsptree/portals...then calcing lighting in several passes each increasing detail...and as soon the cell comes in view it should be done ... if we add one step before this..a cell is only loaded(to mem) if it comes to a certain distance..we can have huge levels as only needed parts are in mem... I guess I'll have it done by another thread in the background..and as everything happens step by step and regularly(if the user doesn't move we just widen the preload area) the impact on framerate should be constant and hopefully acceptable low..

another cool thing about the step by step lighting is that you can get rather detaled maps after a few loopsif the light is static..and if it is dynamic(moving/rotating/what ever) we only do very few passes but the motion keeps it looking ok...(I hope :))

to get on your bsp iussue...I thought about grouping small polys into 'detail objects' and use their bounding box as clip planes... should save ya a lot of splits...and with the antiportals(only big mostly user facing polys are added to the tree) you needn't even add these small objects to the tree...as they don't realy add considerable portals...just do bbox colldetection...or similar like for dynamic objects...

obviously all runtime processed things(lighting,cells/trees/portals/what ever) are cached and only recalced if needed(geo data changes/light moves/...)

here is another thing I'm concerned about.... caching lightmaps ... let's say we have 3 lights in a room..where on is dynamcally rotating..now if I save the combined lightmaps(lm's of all 3 added together..and one changes..(dynamic)..now I had to recalc all the maps..or at least the ones shared with the dynamic one... but the data of the non moved lights are stil valid..so we could save data for each light seperate..but that gives us one lm/light..not realy good..and we have to combine em one's per frame...unnecessary calcing time..bad also...

as we're busy enough loading/calcing other shit I guess I'll give method 1 the try..but I'd be thankfull for any better ideas...

or your opp on my render algo...

Alex

Fell free to use it but pls give credit where due and be shure to show me your result...





  • 07/05/2000 - fastculling
  • 05/15/2000 - parties&fpu fun
  • 04/03/2000 - Tech File Update
  • 02/11/2000 - Tech File Update
  • 01/14/2000 - Tech File Update
  • 06/28/1999 - Rendering Cities
  • 06/24/1999 - Bones Animation
  • 06/22/1999 - Introduction

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