Occlusion culling

Started by
12 comments, last by tiutiu 20 years, 8 months ago
Hmm... I think I will leave occlusion culling for awhile and move to triangle reduction.

Oh and by the way the terrain crashed after moving. Everything sort of started turning into red and crahsed.
Advertisement
Im with Captain Goatse, i think ill focus on triangle reduction and using GeoMipMapping (i got a paper on it). I''ve been looking to your source code Trienco and its a bit weird hehe.

In that paper they say to have N copies of each patch (with N=Number of geomipmaps) so you render the copy for each LoD for the patch, obtained with camera distance and other parameters.
The problems are the cracks in patch junctions with different LoD. The paper says that to solve this we use traingle fans for the links between patches. Is that what you do in your source code? I see LinkPiece and BodyPiece clases, are they the links between different geomipmap levels?

Hmmm i hope you could explain a bit your implementation of geomipmapping, cuz i didnt know of that kind of terrain management.

Cheers
quote:Original post by Captain Goatse
Hmm... I think I will leave occlusion culling for awhile and move to triangle reduction.

Oh and by the way the terrain crashed after moving. Everything sort of started turning into red and crahsed.


hmmm.. i thought there might be the usual wild memory writes but purify didnt find anything. turning into red is wanted for a short period when the sun sets, but it doesnt sound like this kind of turning red. what card and driver are you using? whats confusing me is that moving will change nothing but the modelview matrix. damn, i need more different machines to test. for example if changing to overhead view with s will also crash, or if disabling occlusion culling with o would solve it. another problem is of course, that the default movement speed is so high, that youre reloading 3 of 9 sectors every .5 - 1 seconds. if this version was still distributing it over a few steps and your machine is really fast it might end up needing a reload before the old one finished (i could only get that a few times and then decided that the new map format and compressed textures loaded so fast, that it doesnt make sense to divide into smaller steps anyway).
f@dzhttp://festini.device-zero.de
quote:Original post by tiutiu
Im with Captain Goatse, i think ill focus on triangle reduction and using GeoMipMapping (i got a paper on it). I''ve been looking to your source code Trienco and its a bit weird hehe.


hehe, and its completely uncommented, optimized at weird places and still shorter and cleaner than the original "building site" (where you just add more and more stuff with the mess getting bigger and bigger)

quote:
In that paper they say to have N copies of each patch (with N=Number of geomipmaps) so you render the copy for each LoD for the patch, obtained with camera distance and other parameters.


i dont have different copies of the patch itself (in fact the way i got the geometry now is more confusing but meant to save memory). just different index arrays for different lods that skip unneeded vertices. as this array is the same for every single patch (only the offset into the vertex buffer changes) you need one for every lod and variant. typically thats those 16 per lod (. is a missing side):

xxx xxx xxx xxx x.x
xxx xx. xxx .xx xxx
xxx xxx x.x xxx xxx

x.x x.x x.x xxx xxx xxx
xx. xxx .xx xx. .x. .xx
xxx x.x xxx x.x xxx x.x

x.x x.x x.x xxx x.x
xx. .x. .xx .x. .x.
x.x xxx x.x x.x x.x

quote:
The problems are the cracks in patch junctions with different LoD. The paper says that to solve this we use traingle fans for the links between patches. Is that what you do in your source code? I see LinkPiece and BodyPiece clases, are they the links between different geomipmap levels?


i didnt like the fans. in some situations a fan connecting all vertices to the corner looks plain ugly (imagine this point being high up while the points at the opposite end are rather low.. you end up with ugly edges).

the body pieces are different versions of the body with parts left out that are replaced with linking pieces. the linking pieces are the worst code i''ve ever written, because all those variables for different levels and the weird indexing are making it hard to follow. what its doing is this (two examples, because i was always pis.. when they''d only show it for a difference of one level):

x-x x----x
|/| |././|
x.| x../.|
|\| |./..|
x-x x....|
|/| |.\..|
x.| x..\.|
|\| |.\.\|
x-x x----x

not as simple as a fan but more regular. or you just imagine it as a couple of fans along the edge (2 in this case).

quote:
Hmmm i hope you could explain a bit your implementation of geomipmapping, cuz i didnt know of that kind of terrain management.


hm.. i start by not telling that im not using any kind of quadtree. i played around with it to speed up culling and other things but ended up being either slower or at least not faster than doing it brute force.

all in all its your basic geomipmapping with a few small changes to save memory and avoid redundant data. lod is selected via precomputed error per patch and lod divided through squared screen distance.

if you have any specific questions about certain parts of it, just ask ,-)
f@dzhttp://festini.device-zero.de

This topic is closed to new replies.

Advertisement