## Re: [Algorithms] HOM vs. Hardware

 Re: [Algorithms] HOM vs. Hardware From: Ville Miettinen - 2005-06-27 08:54:57 ```Hi Christian, while I understand that the system works in some cases (and it may be =20= possible to design your 3D content in a way that no visible artifacts =20= occur), calling it "robust" is somewhat an exaggeration, as it is =20 quite obvious from your description why the algorithm isn't, and =20 cannot be, artifact-free. What you're doing is rendering a low-resolution depth buffer (I =20 wouldn't call it a DEB though, as DEB makes sense only in conjunction =20= with coverage info). In order to be conservative, you'd have to =20 modify your triangle rasterization rules so that a pixel in your Z-=20 buffer would be altered if and only if the triangle (or mesh of =20 connected triangles) cover the entire pixel. I didn't see anything in =20= your post or the IOTD description to suggest that you're doing this. =20 Hence, the occluders you create are "bloated" in the screen-space XY =20 direction and cull more than they should. In a similar fashion, =20 you're also doing aggressive culling in the Z direction (you're not =20 computing conservative Z values for the covered pixels, but use =20 whatever Z value happens to be at the sampling point) -- this =20 introduces additional artifacts for interpenetrating objects or ones =20 that are very close to each other (such as objects just behind a wall =20= you're viewing in a steep angle). Doing a conservative rasterization (in screen-space XY dimensions) is =20= a very tricky problem if you want to get decent results, as you =20 cannot just go and shrink your triangles (if you'd do that, there =20 would be thousands of small holes in your objects). You'll need to do =20= full silhouette detection (to determine the actual edges of the =20 objects) and shrink the triangles only in those places. Getting the Z =20= values to be conservative most likely requires some pixel shader =20 hacking. While I do agree that the future of occlusion culling is definitely =20 in HW-based occlusion queries, the rasterization *will* have to be =20 done in full resolution. What we need is a mechanism for querying =20 back the lower-level Z-buffers from the HW (as they're conservative). cheers, -wili -- Ville Miettinen, CTO Hybrid Graphics, Ltd. http://www.hybrid.fi On Jun 27, 2005, at 11:30 AM, Christian Sch=FCler wrote: > > I have some experience with a HOM-style occlusion culling, although =20= > not implementing HOM literally. > > Basically what I did some years ago for an indoor engine was to =20 > draw a tiny (64x64) Z-buffer on the HW, read it back and use this =20 > as occlusion buffer for CPU occlusion queries while rendering the =20 > full frame. To minimize the batch count, only objects that have a =20 > certain minimum screen size, and have not been occluded last frame =20 > are rendered during the occlusion pass (the latter is important to =20 > get true ouput sensitivity). > > > A small image of how it works may still be available here: http://=20 > http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=3D63459 > > In comparison to HOM, this scheme is rather simplistic and has no =20 > coverage map, in fact it is a low-res DEB only (depth estimation =20 > buffer) to go with the terminology of Zhang. > > I found, despite simplicity, the system works great and is very =20 > robust. I didn't need any sort of precomputed visibility, =20 > everything is dynamic (move two boxes together ingame, voil=E1, a new =20= > occluder). > > Don't be too afraid of the depth buffer readback, a vanilla =20 > glReadPixels( GL_DEPTH_COMPONENT ), it didn't matter. Since the =20 > buffer is so small, there's no bandwith issue. Yes, you will not =20 > get 500 FPS anymore when there's a readback command the the stream, =20= > you're locked to 60 FPS max for some reason, but the time is not =20 > wasted, the CPU is free the rest of the frame time to do other =20 > stuff. Plus, you can hide the latency (some 100000's of clock =20 > cycles) between draw and readback with some CPU work. > > > I would be nice if more people used some form of readback so =20 > general readback gets more optimized in the drivers :) > > > > Jonathan: > For indoor, or other densely occluded scenes like cities, you need =20 > some form of occlusion to save CPU work for rendered objects (and =20 > yes, vertex count). Especially when going multipass, like one =20 > additive pass per lightsource. > > > -----Original Message----- > From: gdalgorithms-list-admin@... =20 > [mailto:gdalgorithms-list-admin@...] On Behalf Of =20= > Jonathan Blow > Sent: Tuesday, June 21, 2005 11:13 PM > To: gdalgorithms-list@... > Subject: Re: [Algorithms] HOM vs. Hardware > > > Modern hardware generally uses hierarchical z-buffers to quickly =20 > reject > blocks of pixels. I don't know if any of them actually reject =20 > geometry > as opposed to blocks of pixels, but I don't think this would be > important for many games. Most high-end rendering stuff that I have > seen is bottlenecked by pixel operations, not geometry operations. > > For this reason I think that implementing something like HOM is not a > good idea. It adds this weird squishy feedback loop into your game, > potentially adds rendering errors (if you do the n-frames-later =20 > version > in order to reduce the time you spend waiting for the result). > > Games that want to reduce geometry throughput can often place static > occluders into the world and use them to reject things on the CPU. > Sure, this doesn't work for all cases, but it is okay and the gap > between "okay" and "a slightly better okay" is not worth the =20 > headache of > implementing one of these schmancy occlusion systems. > > > Megan Fox wrote: > > >> Forgive me if I misunderstand, but isn't Zhang's HOM similar to =20 >> one of >> the techniques described in the dPVS papers (or maybe he's the one >> that wrote that portion of the paper) - namely, a tiered zbuffer into >> which is rendered AABB quads, the visibility of said quad capable of >> rejecting the entire mesh from rendering, this sort of system being >> extremely handy for high-level rejections once the largest-pixeled >> level of the buffer starts filling up and you start getting some >> really fast rejections... etc etc etc? >> >> If so, then what hardware alternative are you talking about? Do you >> mean an implementation of this algorithm that uses hardware =20 >> instead of >> software buffers, or do you mean what hardware rendering does >> automatically right now (which, as far as I know, is just by-pixel >> rejection, never anything that would reject the entire mesh in this >> sense)? Or is there another hardware occlusion system that does all >> this automatically which I just have no idea about (which would be >> cool)? >> >> >> -Megan Fox >> >> >> >> >>> Has anyone had experience with Zhang's HOM? >>> >>> I recently read a little on the technique and it's simple but very >>> clever. Does anyone know if a tuned version can beat what we've >>> currently got in hardware? >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration =20 >>> Strategies >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDAlgorithms-list@... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_ida88 >>> >>> >>> >>> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration =20 >> Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDAlgorithms-list@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_ida88 >> >> >> >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=0Cick > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > ```

JavaScript is required for this form.

No, thanks