Archived

This topic is now archived and is closed to further replies.

What's S-Buffering?

This topic is 5793 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

after reading the faq, it seems kinda of like the powerVR2''s tile renderer which is done in hardware (dreamcast used the pwoerVR2). instead of scanlines it drew in tiles. gives very little overdraw but alpha translucent polys tend to kill performence. though if you have the fillrate this dont matter as much. in essence, thats what this algo is designed to do, reduce fillrate requirments. unfortunatly hardware implementations of this with high fillrates would seem to be expensive. mainly because it is a more complex approach then a z or w buffer. i am a little skeptical that a software implemnetation will come anywhere near a hardware video card. its nice and all for software engines, but the reality is that video cards are quite fast and the bandwidth is so high the overdraw is not too bad. though it would be interesting to see some benchmarks.

Share this post


Link to post
Share on other sites
s-buffering, or span-buffering ar similar cannot compare to a GF3 for example is used without any other algorithm.
if you convert your s-buffer to a line-based-coverage-buffer-with-z (not the exact values, just use the farthest z-value of the poly, no need to interpolate) and use it to cull complete objects away by using it to test if the AABB of the object is at least partially visible, it might be useful.

however, i''m looking for fast occlusion techniques (that dont give me 0% overdraw, but - lets say - cut 1000% overdraw down to 200%-300%) myself.

so anyone who has information about this,
please post a link here.


--- foobar
We push more polygons before breakfast than most people do in a day

Share this post


Link to post
Share on other sites
good reply.
but how do i generate the "mask" / silouette for a given object really fast, and how do i do the "is aabb inside clip-frustrum" test really fast.

this should work for high-poly occluders and without "picking large polys" or defining non-rendered-occluder geometry "inside" the rendered geometry.

if this can be done with beam-trees, i dont actually understand them well.

please post any links you have on good and readable beam-tree info here if you have some at hand - better: anyone who has, please post it here.

thx,

--- foobar
We push more polygons before breakfast than most people do in a day

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I wouldn''t generate the mask for models and smaller occluders. It could be done, but I would think that it woudl be more computationally expensive to construct the beam tree than to just do a hardware Z-buffer check. But for large occluders, it would do some early rejection of geometry. Take objects bounding sphere/box/etc. and check to see if the tree is already solid where it will be dawn. If any of it is visible, just throw it to the hardware and let the Z buffer figure it out.

As for checking an AABB, just clip the faces facing towards the viewpoint into the beam tree using a plane/poly intersection test.

If you are not looking for an algorithm that has to stay away from choosing larger polys or one that evaluates what is a good occluder, beam trees probably aren''t the best choice. Adding many polys into a beam tree would increase time spent inserting and testing other polys against the current tree.


Here''s a few links I dug up just now.

http://www.flipcode.com/harmless/issue01.htm#beamtrees
(basic overview. nothing huge.)

http://www.cbloom.com/3d/techdocs/beamtree.txt

Share this post


Link to post
Share on other sites
In software I''m convinced s-buffer is much better than z-buffer (someone tell me what is a w-buffer). The overdraw isn''t the main problem I don''t think - drawing pixels is very quick. However with z buffers you have to check the value in the buffer then update it if you want to draw there. That''s quite slow (my software engine''s fill rate doubled almost if I turned off zbuffering)
The s-buffer has no overdraw (for what it''s worth) but also no zbuffer checking. You want to make it have a minimum number of spans though (higher on screen here means gets drawing priority)

____________________________________
_________________________________________________

normally would split into

______ _____________________________
_____________________
but could be turned simply to
____________________________________
_____________________
I agree about transparency and s-buffers being a problem, but ain''t it almost as bad with z-buffers. Plus space problems with z-buffers: 24bits for a colour value+8 for alpha but then a list for every pixel which means a pointer too so up to at leaast 8bytes per pixel with no transparency effects.

Share this post


Link to post
Share on other sites