Re: [Algorithms] Alternatives to backface culling
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] Alternatives to backface culling
|
From: <And...@pl...> - 2006-06-22 18:03:48
|
Right, so in this case the front faces and back faces have different vertices, which is why there's z-fighting, even in a single pass. With no backface culling, if the door had no thickness then either the front or back would always be drawn on top due to polygon ordering, but there would be no z-fighting. Rendering the same poly twice using the same vertcies, same transformation and same FPU, should never result in z-fighting. I believe the original suggestion was do a z-only pass, then a color pass. That will always work, unless there are artifacts in regular rendering, in which case those artifacts will show up in two-pass rendering too. Andy Styles PS3 Lead Programmer NBA Team Sony Computer Entertainment America 10075 Barnes Canyon Road San Diego CA 92121 Tel: 858 824 5968 Fax: 858 824 5634 "Tom Forsyth" <tom...@ee...> Sent by: gda...@li... 06/22/2006 10:46 AM Please respond to Game Development Algorithms <gda...@li...> To "'Game Development Algorithms'" <gda...@li...> cc Subject Re: [Algorithms] Alternatives to backface culling I'm talking about Z-fighting between the back faces of a thin door or wall, and the front faces. It happens even if you only do a single rendering pass. At some distance from the camera, they will have some pixels that have the same Z values. The exact distance depends on how thin the object is and the projection matrix and how many bits in your Z buffer and all that usual stuff. It's especially acute on the PS2 because on most other hardware the back faces get backface culled. Things like bits of paper (e.g. newspapers) that need to have a different picture on each side are a massive pain. TomF. -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of And...@pl... Sent: 22 June 2006 10:01 To: Game Development Algorithms Subject: Re: [Algorithms] Alternatives to backface culling If you draw the same poly with exactly the same vertices and exactly the same transformation, there shouldn't be any z-fighting, surely? Tom, are you talking about when you render a floating polygon over a large polygon? The exception to this is if you are using different (non-IEEE) FPUs between passes, in which case minor precision issues can throw you off. For example, different rounding modes on the CPU vs. GPU, or even going through a fixed function pipeline vs. a custom shader pipeline (a problem with nvidia hardware a few generations back). "Tom Forsyth" <tom...@ee...> Sent by: gda...@li... 06/22/2006 09:39 AM Please respond to Game Development Algorithms <gda...@li...> To"'Game Development Algorithms'" <gda...@li...> cc SubjectRe: [Algorithms] Alternatives to backface culling > Not so, although you do have to be a little careful. If you use > _exactly_ the same vertex positions with _exactly_ the same > transforms, > you won't see any Z fighting. Sadly not true. If the two quantised Z values are the same for front and back faces in some pixels but not others, then you'll get whichever was drawn last. Again, it's the problem with very thin objects like doors. This is also a problem on other machines when doing multiple additive passes (e.g. lighting) where two objects intersect slightly - each gets the same light hitting it in an additive pass, and in some places along the seam the pass from *both* objects gets added, and you get doubly-bright pixels - they're annoyingly obvious. You can fix it to some degree by stencil tricks - but the PS2 doesn't have one of those. You may be able to use the alpha channel to do the same thing. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Jamie Fowlston > Sent: 22 June 2006 02:55 > To: Game Development Algorithms > Subject: Re: [Algorithms] Alternatives to backface culling > > > Matt J wrote: > > Yes, the painters algorithm. I would wager that this is rare in > > practice but can be solved with static models using BSP trees. > > Well, it's the failure case for the painter's algorithm, yes. Fairly > rare in practice; if you've got static models, you can solve it by > chopping up polys in advance, yes. But really, the cases > where it makes > enough difference that it's actually worth fixing are incredibly rare. > > Solving > > it effectively in run-time with arbitrary polygons with arbitrary > > positions, well, that's just plain hard (hard to do quickly) :) I > > would say that one of the limitations of (most) fixed-pipeline > > architecture s is simply the fact there is no nice way of handling > > translucent polygons. I love transparency and glass and the neat > > effects that can be done with it.. so having to jump through so many > > hoops kinda sucks. You would think a nice architecture would simply > > handle it behind the scenes. but....then it wouldn't let you do the > > "cheap and fast" way. > > Not sure whether you're criticizing hardware or software pipelines > there. I don't see it as a problem which can be fixed in software. As > has been pointed out already, there is (quite old!) hardware > which "just > works". Unfortunately it's rare, and because we have > reasonable software > workarounds there's little impetus to solve the problem properly. > > > > > I'm not entirely sure how well all hardware handles vertex sharing > > (due to my lack of experience, i'm still new to this > field), but from > > my conceptual understanding multiple passes are never a perfect > > solution because even if you get the drawing right using multiple > > passes, you still might have z-fighting at the edges of where the > > translucent polygons meet the opaque ones. If that is a problem I > > suppose you can treat the additional passes by biasing the z-value > > like decals, but then you'd have to bias it based on whether it is > > front or back culling, meaning you would need 2 additional passes. > > Not so, although you do have to be a little careful. If you use > _exactly_ the same vertex positions with _exactly_ the same > transforms, > you won't see any Z fighting. > > Jamie > > All the advantages of Linux Managed Hosting--Without the Cost > and Risk! > Fully trained technicians. The highest number of Red Hat > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729& dat=121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
