Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Jacco Bikker, posted on October 18, 2000




Image Description, by Jacco Bikker



Here we have a couple of screenshots from the visibility algorithm that I am developing here at Davilex. The algorithm is a combination of an adaptive octree for spatial subdivision and a c-buffer for occlusion testing. About the shots: The first one (top left) shows the scene, rendered normally. The one in the top-right corner shows the c-buffer: 'Red' means occluded. Note that I don't just draw every single polygon in this buffer, but just the large occluders. Also note that I normally use a lower resolution c-buffer, but that doesn't look as good for an IOTD. :) The green lines are the boundaries of the adaptive octree nodes, the blue lines (hard to see) are the bounding boxes of the detail meshes. The two images on the bottom side of the image show the scene rendered in wireframe mode, with and without culling. This is a conservative culling algorithm; as soon as a part of a mesh is visible, it's drawn completely. This ensures minimal culling costs, resulting in optimal performance on today's hardware. For software rendering, you might want to try a slightly less conservative algorithm.

Jacco Bikker, a.k.a. 'The Phantom',
Davilex Software (www.davilex.nl)


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Willem

October 19, 2000, 10:25 AM

My

bool IsOccluderByOccluder(occluder, vertexList)

is basically just a 'test a mesh of vertices against a polygon (occluder)'-algorithm, which is would be nice if it could be handled by a parallel graphics processing unit, that way saving CPU cycles. This is basically an extension of a z-buffer (pixel stage), by testing one level higher (polygon stage), which would save transformation calculations (if it could be done in worldspace).

I'd like to see parallel access to UMA by both the CPU and the GPU, which implies that the frame-buffer, z-buffer, any-buffer can be accessed by the CPU (or maybe another, to geometry manipulating, processor) at any time, without the need to transfer it (via a bus, which is the only way now). That would be cool. But co-ordinating this would be a hell of a task.

 
Ian Romanick

October 19, 2000, 11:58 AM

I realize Jacco that you're probably the last person who wants to hear someone say "Carmack says...", but I bring this up simply because he has indeed shipped a very fast hardware-accelerated game.

However, one should point out that Carmack's current occlusion algorithm (which is basically a portal system, as I recall), doesn't support highly dynamic environments. That is, you can't blow a hole in a wall, in the general case. This brings things back to the old performance vs. flexability trade-off.

 
Arne Rosenfeldt

October 19, 2000, 02:22 PM

Hello Marco Al

I do not like this wich is called Reprojection in the interesting (thanks) paper anymore.
I wanted to get frame/time coherence (lokal in 3d), but noticed, that this will give only little speed improvement.

The thing that make me stop coding, was that
with my method I would have tested a hight detail coverage buffer (Triage buffer...whatever) against low level portals, wich I think is not optimal. Also splitting and merging the coverage buffer all the time is no good. I think this is also true for the paper.

(I already wrote from scratch subpixel-correct drawTriangle with edge-list like frustrum culling and scene in a BSP)

 
Marco Al

October 19, 2000, 02:51 PM

Why would it need to be worldspace? The only halfway feasible method I know is Midnight's, and I have to take that on faith. Where'as for screen-based occlusion culling at least we have the work from Greene et al. If the hardware is able to do culling hierarchically the end effect is the same, you still avoid needles transformations (the world space culling costs will be high too if you cant do it hierarchically, transform or not).

The method Jaap is using now might suit hardware, only it wouldnt need occluders because it can simply render front to back and do occlusion on the fly with a hierarchical Z-buffer.

But thats a bit too specific and unflexible. How about making the display-list a tree where you could add branches which are taken depending on the visibility of a bounding-X? (X = sphere, box, slab or whatever) Almost identical to Jaap's suggestion, only without the ugly feedback :)

Marco

 
Willem

October 20, 2000, 03:08 AM

It doesn't need to be world-space, it would be cool if it could be done in worldspace (we're talking about a separate, to geometry dedicated, processor here) to save the extra transformation cost in case the list really got occluded by the occluder.

 
This thread contains 35 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.