Thread: RE: [Algorithms] HOM vs. Hardware
Brought to you by:
vexxed72
From: Chris B. \(BUNGIE\) <cbu...@mi...> - 2005-06-22 19:47:07
|
> -----Original Message----- > From: gda...@li... [mailto:gdalgorithms- > lis...@li...] On Behalf Of Tom Forsyth > Sent: Wednesday, June 22, 2005 12:35 > To: gda...@li... > Subject: RE: [Algorithms] HOM vs. Hardware >=20 > Obviously as soon as you clamber onto a moderately high rooftop, it all > fails, but that's when you start having to get the LOD stuff going. C'est > la > vie. But then, youre attention is probably on more distant objects, so the > LOD is not as noticeable. >=20 Agreed. Grand Theft Auto is not unsuccessful in its approach. -- Chris Butcher Networking & Simulation Lead Halo 2 | Bungie Studios bu...@bu... |
From: Gilbert, T. <Tr...@cs...> - 2005-06-22 21:22:14
|
> Didn't Hybrid put dPVS in Renderware? For some reason, I seem to remember > that GTA:VC used dPVS. Wonder if they did the same for GTA:SA - it's an > ideal case for it. Wow! Finely something I've got expertise on I can contribute to the list! (Thanks for the prompt, Tom!) Criterion does/did exclusively resell dPVS (VisionFX is the product name). It had integration provided for RenderWare (hooks into our scene manager), but it was not integrated into the RenderWare Graphics product as an integral feature. GTA3, GTA:VC and GTA:SA all used RenderWare Graphics, but not any of our other products. The visibility system is their own. I believe it's a pretty vanilla occlusion system using planes, a 2D grid, and two LODs (lo and hi). If you stand on top of a building and see a huge swath of the city (or you're in a plane), you're basically seeing the lo LOD. When you're standing in front of a building at street level, that's the hi lod. In GTA3 and GTA:VC, I believe they always had the lo LOD loaded in memory (and would load in new low LOD when you saw loading screens between islands/cities/etc.) and they streamed the hi lod off of disk (along with textures, sounds, etc.). I wish those guys would write up a GDC talk on their system, because my impression is that it is simple (in concept), yet seems to be fairly successful. BTW, dPVS doesn't really work on the PS2 as a product: the I$ and D$ are simply too small (and the VU/GS's vertex throughput too high relatively speaking) for dPVS to effectively outpace the VU/GS. So, no PS2 titles use dPVS. Hybrid does offer consulting services to selectively apply various dPVS "sub-" techniques on a case-by-case basis (for PS2 titles). On the PC front, EQ2 and Star Wars Galaxies used dPVS. Troy Gilbert Developer Relations RenderWare www.renderware.com > > TomF. > > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...] On > > Behalf Of Chris Butcher (BUNGIE) > > Sent: 22 June 2005 12:47 > > To: gda...@li... > > Subject: RE: [Algorithms] HOM vs. Hardware > > > > > > > -----Original Message----- > > > From: gda...@li... > > [mailto:gdalgorithms- > > > lis...@li...] On Behalf Of Tom Forsyth > > > Sent: Wednesday, June 22, 2005 12:35 > > > To: gda...@li... > > > Subject: RE: [Algorithms] HOM vs. Hardware > > > > > > Obviously as soon as you clamber onto a moderately high rooftop, it > > all > > > fails, but that's when you start having to get the LOD stuff going. > > C'est > > > la > > > vie. But then, youre attention is probably on more distant > > objects, so > > the > > > LOD is not as noticeable. > > > > > Agreed. Grand Theft Auto is not unsuccessful in its approach. > > > > -- > > Chris Butcher > > Networking & Simulation Lead > > Halo 2 | Bungie Studios > > bu...@bu... > > > > > > > > ------------------------------------------------------- > > 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_id492&op=ick > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > 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_id492&op=click > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Mark W. <Mwa...@to...> - 2005-06-24 00:25:05
|
I used occluders in Carmageddon TDR2000 which were manually placed convex polygons and were tested against using the CPU. We'd typically put two of them in a cross formation inside of buildings that you couldn't enter (eg. an X from the top) and placed them under hills to obscure scenes beyond them. This worked quite effectively. I did plan to add occluder fusion, but it didn't really seem necessary nor did I have the time. Each frame we simply collected occluders that intersected the frustum, roughly sorted them from front to back and tested the geometry bounds against them. If the geometry bounds were inside of all of the planes defined by extruding the occluder polygon edges away from the camera point, we simply skipped it. No real magic or fancy stuff, but worked great. HTH, Mark > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Nakunaru > Sent: Wednesday, 22 June 2005 6:17 AM > To: gda...@li... > Subject: [Algorithms] HOM vs. Hardware >=20 > Has anyone had experience with Zhang's HOM? >=20 > I recently read a little on the technique and it's simple but=20 > very clever. Does anyone know if a tuned version can beat=20 > what we've currently got in hardware? >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration=20 > Strategies from IBM. Find simple to follow Roadmaps,=20 > straightforward articles, informative Webcasts and more! Get=20 > everything you need to get up to speed, fast.=20 > http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |
From: <ja...@vi...> - 2005-06-24 17:11:25
|
Hi, The is an article about HW assisted visibility system in GPU Gems 2, which addresses the latency and performance/batching problems of the occlusion query. I don't know how practical it is, but it may spawn some ideas. Cheers, Jarkko -----Original Message----- From: Chris Lambert <cla...@fl...> Subj: Re: [Algorithms] HOM vs. Hardware Date: Fri Jun 24, 2005 7:04 pm Size: 3K To: gda...@li... Hi, We're faced with a situation where pre-computed visibility structures are not an option (random outdoor urban levels built from arbitrarily sized/shaped "tiles" with additional prop objects added during final layout for variety). This means that until load time, I don't know the actual list, count, position or orientation of tiles. Currently, we use a vanilla occlusion query system: When rendering each tile, render either the tile and its contents surrounded by a query or a single invisible (color/depth write off) bounding box surrounded by a query. This works, and yields very substantial batch count reduction and frame rate improvements. Bad things: one batch per invisible tile, frame delay (buffer up to x queries per tile with a non-blocking poll for results each frame), hard to debug (the ultimate Heisenberg problem!). The critical failing is the frame delay. I can track "new-to-frustum" tiles and force them visible until heard otherwise, but the "strafe around a corner" case is unfixable without an alternative or additional culling scheme. I'm looking at the Coherent Heirarchical Culling paper, as well as a non-query-based kd-tree portal-creation scheme outlined in a book laying around somewhere. Has anyone here tackled a similar problem? What sort of system did you choose and why? -Chris -- if ( GetTickCount() % 10000 == 0 ) *(int*)rand() = 0; Miles Macklin wrote: > Hi all, > > We are looking to implement the Coherent Hierarchical Culling algorithm > using hardware occlusion queries as presented here: > > http://www.cg.tuwien.ac.at/research/vr/chcull/ > > Although it might be slightly 'squishy' it sounds promising, does anyone > have an analysis to offer ? > > Cheers, > > Miles > > ----- Original Message ----- > *From:* Bill Baxter <mailto:wb...@gm...> > *To:* gda...@li... > <mailto:gda...@li...> > *Sent:* Thursday, June 23, 2005 11:43 AM > *Subject:* Re: [Algorithms] HOM vs. Hardware > > Ok, for plain vanilla urban scenes with opaque boxes for buildings > where you can get by with 1D occlusion maps then, yeh, I guess > dynamic occlusion culling isn't so bad. That's a pretty special > case, but fairly common, I suppose. I recall reading a papery by > someone that also dealt with the problem varying building heights by > creating a top-down occlusion map by rendering sight-line planes > into a 2D buffer. > > Still, I'm not totally convinced you couldn't do just as well with > some sort of static PVS on those types of scenes. > > On 6/23/05, *Tom Forsyth* < tom...@ee... > <mailto:tom...@ee...>> wrote: > > I'm not convinced that's true. The standard benchmark for > occlusion is the > built-up urban scene. As long as you stay at ground level, there > is a huge > amount of occlusion, but it's very hard for any non-dynamic > occlusion > (portals, static PVS) to do anything useful. You can prtty much > move > anywhere you like, you will always get lots and lots of > occlusion. Sure, you > can look all the way down a street and see lots of houses, but > it's very > rare that you can look straight down more than two streets at --- message truncated --- |
From: <bac...@ne...> - 2005-06-25 16:54:15
|
Hi I'm new to the list, so sorry, if I say something dumb :) I'm using Open GL Occolusion Query, and I have serious problems with it. It has a memory leak. If I call glBeginQuery, at every frame, my soft uses up 20k of memory. If I don't use it, the memory usage holds... I don't know if only I encountered the problem, but I uses exactly the way, the opengl spec sais... Backinside ja...@vi... wrote: > Hi, > > The is an article about HW assisted visibility system in GPU Gems 2, which addresses the latency and performance/batching problems of the occlusion query. I don't know how practical it is, but it may spawn some ideas. > > Cheers, Jarkko > > -----Original Message----- > > From: Chris Lambert <cla...@fl...> > Subj: Re: [Algorithms] HOM vs. Hardware > Date: Fri Jun 24, 2005 7:04 pm > Size: 3K > To: gda...@li... > > Hi, > > We're faced with a situation where pre-computed visibility structures > are not an option (random outdoor urban levels built from arbitrarily > sized/shaped "tiles" with additional prop objects added during final > layout for variety). This means that until load time, I don't know the > actual list, count, position or orientation of tiles. > > Currently, we use a vanilla occlusion query system: > > When rendering each tile, render either the tile and its contents > surrounded by a query or a single invisible (color/depth write off) > bounding box surrounded by a query. > > This works, and yields very substantial batch count reduction and frame > rate improvements. Bad things: one batch per invisible tile, frame > delay (buffer up to x queries per tile with a non-blocking poll for > results each frame), hard to debug (the ultimate Heisenberg problem!). > > The critical failing is the frame delay. I can track "new-to-frustum" > tiles and force them visible until heard otherwise, but the "strafe > around a corner" case is unfixable without an alternative or additional > culling scheme. > > I'm looking at the Coherent Heirarchical Culling paper, as well as a > non-query-based kd-tree portal-creation scheme outlined in a book laying > around somewhere. > > Has anyone here tackled a similar problem? What sort of system did you > choose and why? > > -Chris |
From: Stephen J B. <sj...@li...> - 2005-06-27 13:07:44
|
Balogh P=E9ter wrote: > Hi >=20 > I'm new to the list, so sorry, if I say something dumb :) > I'm using Open GL Occolusion Query, and I have serious problems with it. > It has a memory leak. If I call glBeginQuery, at every frame, my soft=20 > uses up 20k of memory. If I don't use it, the memory usage holds... > I don't know if only I encountered the problem, but I uses exactly the=20 > way, the opengl spec sais... It would help to tell us which hardware/drivers/os you are using - but we've used the nvOcclusion extension quite a bit and it certainly doesn't leak memory for us - over a variety of cards and drivers that support it. I would definitely suspect a software bug on your side before accusing the drivers. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: <bac...@ne...> - 2005-06-27 14:19:51
|
I searched several times the software for bug. The code is simple: glBeginQueryARB(GL_SAMPLES_PASSED_ARB, queries); glBegin(GL_POINTS); glVertex3fv(((xSurfaceFlare *)xtmp)->pos); glEnd(); glEndQueryARB(GL_SAMPLES_PASSED_ARB); GLint available; do { glGetQueryObjectivARB(queries, GL_QUERY_RESULT_AVAILABLE_ARB, &available= ); }while(!available); glGetQueryObjectuivARB(queries, GL_QUERY_RESULT_ARB, &sampleCount); if (sampleCount > 0) sresult =3D true; else sresult =3D false; If I comment this piece of code, and leave only sresult =3D true or=20 sresult =3D false, it works fine. I'm using Ati 9800 Pro with CATALYST=99 Version 05.5 With the previous driver we had no memleak. Stephen J Baker wrote: > Balogh P=E9ter wrote: >=20 >> Hi >> >> I'm new to the list, so sorry, if I say something dumb :) >> I'm using Open GL Occolusion Query, and I have serious problems with i= t. >> It has a memory leak. If I call glBeginQuery, at every frame, my soft=20 >> uses up 20k of memory. If I don't use it, the memory usage holds... >> I don't know if only I encountered the problem, but I uses exactly the= =20 >> way, the opengl spec sais... >=20 >=20 > It would help to tell us which hardware/drivers/os you are using - but > we've used the nvOcclusion extension quite a bit and it certainly doesn= 't > leak memory for us - over a variety of cards and drivers that support i= t. > I would definitely suspect a software bug on your side before accusing > the drivers. >=20 > ----------------------------------------------------------------------- > The second law of Frisbee throwing states: "Never precede any maneuver > by a comment more predictive than "Watch this!"...it turns out that > this also applies to writing Fragment Shaders. > ----------------------------------------------------------------------- > Steve Baker (817)619-2657 (Vox/Vox-Mail) > L3Com/Link Simulation & Training (817)619-2466 (Fax) > Work: sj...@li... http://www.link.com > Home: sjb...@ai... http://www.sjbaker.org >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 >=20 |
From: <c.s...@ph...> - 2005-06-27 08:31:25
|
I have some experience with a HOM-style occlusion culling, although not = implementing HOM literally. Basically what I did some years ago for an indoor engine was to draw a = tiny (64x64) Z-buffer on the HW, read it back and use this as occlusion = buffer for CPU occlusion queries while rendering the full frame. To = minimize the batch count, only objects that have a certain minimum = screen size, and have not been occluded last frame are rendered during = the occlusion pass (the latter is important to get true ouput = sensitivity). A small image of how it works may still be available here: = http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=3D63459 In comparison to HOM, this scheme is rather simplistic and has no = coverage map, in fact it is a low-res DEB only (depth estimation buffer) = to go with the terminology of Zhang.=20 I found, despite simplicity, the system works great and is very robust. = I didn't need any sort of precomputed visibility, everything is dynamic = (move two boxes together ingame, voil=E1, a new occluder).=20 Don't be too afraid of the depth buffer readback, a vanilla = glReadPixels( GL_DEPTH_COMPONENT ), it didn't matter. Since the buffer = is so small, there's no bandwith issue. Yes, you will not get 500 FPS = anymore when there's a readback command the the stream, you're locked to = 60 FPS max for some reason, but the time is not wasted, the CPU is free = the rest of the frame time to do other stuff. Plus, you can hide the = latency (some 100000's of clock cycles) between draw and readback with = some CPU work.=20 I would be nice if more people used some form of readback so general = readback gets more optimized in the drivers :) Jonathan: For indoor, or other densely occluded scenes like cities, you need some = form of occlusion to save CPU work for rendered objects (and yes, vertex = count). Especially when going multipass, like one additive pass per = lightsource.=20 -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Jonathan Blow Sent: Tuesday, June 21, 2005 11:13 PM To: gda...@li... Subject: Re: [Algorithms] HOM vs. Hardware Modern hardware generally uses hierarchical z-buffers to quickly reject=20 blocks of pixels. I don't know if any of them actually reject geometry=20 as opposed to blocks of pixels, but I don't think this would be=20 important for many games. Most high-end rendering stuff that I have=20 seen is bottlenecked by pixel operations, not geometry operations. For this reason I think that implementing something like HOM is not a=20 good idea. It adds this weird squishy feedback loop into your game,=20 potentially adds rendering errors (if you do the n-frames-later version=20 in order to reduce the time you spend waiting for the result). Games that want to reduce geometry throughput can often place static=20 occluders into the world and use them to reject things on the CPU. =20 Sure, this doesn't work for all cases, but it is okay and the gap=20 between "okay" and "a slightly better okay" is not worth the headache of = implementing one of these schmancy occlusion systems.=20 Megan Fox wrote: >Forgive me if I misunderstand, but isn't Zhang's HOM similar to 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 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 > > =20 > >>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 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 >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_ida88 >> >> =20 >> > > >------------------------------------------------------- >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=CCk >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > ------------------------------------------------------- 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 GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Ville M. <wi...@hy...> - 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 > 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: gda...@li... =20 > [mailto:gda...@li...] On Behalf Of =20= > Jonathan Blow > Sent: Tuesday, June 21, 2005 11:13 PM > To: gda...@li... > 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 >>> GDA...@li... >>> 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 >> GDA...@li... >> 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 > GDA...@li... > 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 > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > |
From: <gd...@er...> - 2005-06-27 10:04:06
|
Hi Ville,=20 I'm curious, could you explain why the GL_NV_occlusion_query extension = is=20 not sufficient ?=20 You can use it at full resolution, and if you have a good front-to-back= =20 traversal and deal with the latency by proper interleaving outstanding=20 queries with cpu/gpu work ?=20 Erwin Coumans=20 >>What we need is a mechanism for querying back the lower-level Z-buffe= rs >> from the HW (as they're conservative).=20 Ville Miettinen writes:=20 > Hi Christian,=20 >=20 > 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 qu= ite=20 > obvious from your description why the algorithm isn't, and cannot be= ,=20 > artifact-free.=20 >=20 > What you're doing is rendering a low-resolution depth buffer (I woul= dn't=20 > call it a DEB though, as DEB makes sense only in conjunction with=20 > coverage info). In order to be conservative, you'd have to modify yo= ur=20 > triangle rasterization rules so that a pixel in your Z- buffer would = be=20 > altered if and only if the triangle (or mesh of connected triangles)= =20 > cover the entire pixel. I didn't see anything in your post or the IO= TD=20 > description to suggest that you're doing this. Hence, the occluders = you=20 > create are "bloated" in the screen-space XY direction and cull more = than=20 > they should. In a similar fashion, you're also doing aggressive cull= ing=20 > in the Z direction (you're not computing conservative Z values for t= he=20 > covered pixels, but use whatever Z value happens to be at the sampli= ng=20 > point) -- this introduces additional artifacts for interpenetrating=20 > objects or ones that are very close to each other (such as objects j= ust=20 > behind a wall you're viewing in a steep angle).=20 >=20 > Doing a conservative rasterization (in screen-space XY dimensions) is= a=20 > very tricky problem if you want to get decent results, as you cannot= just=20 > go and shrink your triangles (if you'd do that, there would be thous= ands=20 > of small holes in your objects). You'll need to do full silhouette=20 > detection (to determine the actual edges of the objects) and shrink = the=20 > triangles only in those places. Getting the Z values to be conservat= ive=20 > most likely requires some pixel shader hacking.=20 >=20 > While I do agree that the future of occlusion culling is definitely = in=20 > HW-based occlusion queries, the rasterization *will* have to be done= in=20 > full resolution. What we need is a mechanism for querying back the=20 > lower-level Z-buffers from the HW (as they're conservative).=20 >=20 > cheers, > -wili=20 >=20 > -- > Ville Miettinen, CTO > Hybrid Graphics, Ltd. > http://www.hybrid.fi=20 >=20 > On Jun 27, 2005, at 11:30 AM, Christian Sch=FCler wrote:=20 >=20 >>=20 >> I have some experience with a HOM-style occlusion culling, although = not=20 >> implementing HOM literally.=20 >>=20 >> Basically what I did some years ago for an indoor engine was to dra= w a=20 >> tiny (64x64) Z-buffer on the HW, read it back and use this as occlu= sion=20 >> buffer for CPU occlusion queries while rendering the full frame. To= =20 >> minimize the batch count, only objects that have a certain minimum=20 >> screen size, and have not been occluded last frame are rendered dur= ing=20 >> the occlusion pass (the latter is important to get true ouput=20 >> sensitivity).=20 >>=20 >>=20 >> A small image of how it works may still be available here: http://=20 >> www.flipcode.com/cgi-bin/fcarticles.cgi?show=3D63459=20 >>=20 >> 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 bu= ffer)=20 >> to go with the terminology of Zhang.=20 >>=20 >> I found, despite simplicity, the system works great and is very rob= ust.=20 >> I didn't need any sort of precomputed visibility, everything is dyn= amic=20 >> (move two boxes together ingame, voil=E1, a new occluder).=20 >>=20 >> Don't be too afraid of the depth buffer readback, a vanilla =20 >> glReadPixels( GL_DEPTH_COMPONENT ), it didn't matter. Since the buf= fer=20 >> is so small, there's no bandwith issue. Yes, you will not get 500 F= PS=20 >> anymore when there's a readback command the the stream, you're lock= ed to=20 >> 60 FPS max for some reason, but the time is not wasted, the CPU is = free=20 >> the rest of the frame time to do other stuff. Plus, you can hide th= e=20 >> latency (some 100000's of clock cycles) between draw and readback w= ith=20 >> some CPU work.=20 >>=20 >>=20 >> I would be nice if more people used some form of readback so genera= l=20 >> readback gets more optimized in the drivers :)=20 >>=20 >> =20 >>=20 >> Jonathan: >> For indoor, or other densely occluded scenes like cities, you need = some=20 >> form of occlusion to save CPU work for rendered objects (and yes, v= ertex=20 >> count). Especially when going multipass, like one additive pass per= =20 >> lightsource.=20 >>=20 >>=20 >> -----Original Message----- >> From: gda...@li... =20 >> [mailto:gda...@li...] On Behalf Of = =20 >> Jonathan Blow >> Sent: Tuesday, June 21, 2005 11:13 PM >> To: gda...@li... >> Subject: Re: [Algorithms] HOM vs. Hardware=20 >>=20 >>=20 >> Modern hardware generally uses hierarchical z-buffers to quickly re= ject >> blocks of pixels. I don't know if any of them actually reject geom= etry >> 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.=20 >>=20 >> 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 ver= sion >> in order to reduce the time you spend waiting for the result).=20 >>=20 >> 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 headac= he of >> implementing one of these schmancy occlusion systems.=20 >>=20 >>=20 >> Megan Fox wrote:=20 >>=20 >>=20 >>> Forgive me if I misunderstand, but isn't Zhang's HOM similar to on= e 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 in= to >>> which is rendered AABB quads, the visibility of said quad capable o= f >>> 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?=20 >>>=20 >>> If so, then what hardware alternative are you talking about? Do yo= u >>> mean an implementation of this algorithm that uses hardware instea= d 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 al= l >>> this automatically which I just have no idea about (which would be >>> cool)?=20 >>>=20 >>>=20 >>> -Megan Fox=20 >>>=20 >>> =20 >>>=20 >>>=20 >>>> Has anyone had experience with Zhang's HOM?=20 >>>>=20 >>>> 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?=20 >>>>=20 >>>>=20 >>>> ------------------------------------------------------- >>>> SF.Net email is sponsored by: Discover Easy Linux Migration Strat= egies >>>> from IBM. Find simple to follow Roadmaps, straightforward articles= , >>>> informative Webcasts and more! Get everything you need to get up t= o >>>> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick >>>> _______________________________________________ >>>> GDAlgorithms-list mailing list >>>> GDA...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>> Archives: >>>> http://sourceforge.net/mailarchive/forum.php?forum_ida88=20 >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>> =20 >>>=20 >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration Strate= gies >>> 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 >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_ida88=20 >>>=20 >>> =20 >>>=20 >>>=20 >> =20 >>=20 >>=20 >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategi= es >> 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 >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_ida88=20 >>=20 >>=20 >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategi= es >> 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 >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_ida88=20 >>=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategie= s > 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 > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 =20 |
From: <c.s...@ph...> - 2005-06-27 09:04:54
|
Point taken, 'robust' was not meant to be artifact free, but software robustness, ie. = no singularities in the algorithm, because it is image based. If you can = render it, it can occlude (much like in shadow maps, which are robust, = but not artifact free :_) -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Ville Miettinen Sent: Monday, June 27, 2005 10:55 AM To: gda...@li... Subject: Re: [Algorithms] HOM vs. Hardware 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 > 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 = > 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: gda...@li... =20 > [mailto:gda...@li...] On Behalf Of =20 > Jonathan Blow > Sent: Tuesday, June 21, 2005 11:13 PM > To: gda...@li... > 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 >>> GDA...@li... >>> 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 >> GDA...@li... >> 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 > GDA...@li... > 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 > GDA...@li... > 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 GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Nick C. <NC...@nv...> - 2005-06-27 22:37:39
|
c.s...@ph... writes: > I would be nice if more people used some form of readback so=20 > general readback gets more optimized in the drivers :) In the NVIDIA OpenGL driver, we do actively optimize glReadPixels. The format you use will have a big impact on the perf you see. Also, depending on your usage requirements, Pixel Buffer Objects (PBOs) may be an appropriate optimization to achieve asynchronous, pipelined readbacks. Traditional glReadPixels always implies an glFinish(); PBO removes this necessity allowing for better CPU/GPU overlap. - nick carter / NVIDIA |
From: Bill B. <wb...@gm...> - 2005-06-30 23:20:49
|
Someone pointed me to a recent commercial tool that does PVS-based=20 visibility: http://www.wizaid.com/ Has anyone given it a try? They're a little vague on the algorithm, but it= =20 seems to be cell-based visibility, with an offline preprocessor for=20 determining the cells and what's visible from them. --bb |
From: Tom F. <tom...@ee...> - 2005-06-22 20:46:55
|
Didn't Hybrid put dPVS in Renderware? For some reason, I seem to = remember that GTA:VC used dPVS. Wonder if they did the same for GTA:SA - it's an ideal case for it. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Chris Butcher (BUNGIE) > Sent: 22 June 2005 12:47 > To: gda...@li... > Subject: RE: [Algorithms] HOM vs. Hardware >=20 >=20 > > -----Original Message----- > > From: gda...@li... > [mailto:gdalgorithms- > > lis...@li...] On Behalf Of Tom Forsyth > > Sent: Wednesday, June 22, 2005 12:35 > > To: gda...@li... > > Subject: RE: [Algorithms] HOM vs. Hardware > >=20 > > Obviously as soon as you clamber onto a moderately high rooftop, it > all > > fails, but that's when you start having to get the LOD stuff going. > C'est > > la > > vie. But then, youre attention is probably on more distant=20 > objects, so > the > > LOD is not as noticeable. > >=20 > Agreed. Grand Theft Auto is not unsuccessful in its approach. >=20 > -- > Chris Butcher > Networking & Simulation Lead > Halo 2 | Bungie Studios > bu...@bu... >=20 >=20 >=20 > ------------------------------------------------------- > 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 > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |