   What's texture borders, how to use them and why?
  i know this sounds extremely like a beginner, but i''m not.i''ve been working with ogl for a while and i didn''t feel anything missing until i heard about these borders, so i just wanna know what''s that..   xee.. 
  Well, it''s just a border.. never found any use for them, guess they can be useful in more industrial kind of development or CAD...;  Basically, it''s a pixel border around your texture. Initially, they were designed to allow for seamless connection between texture tiles. That was at a time, where high resolution textures did not yet exist. Today, that usage has lost its importance. Modern 3D cards include many more filters than just the simple nearest and bilinear filter. For example bicubic, anisotropic, etc. Each of them would need special circuitry in the 3D chip to support borders. Some filters can''t support borders at all (eg. spline, admittedly not yet available on consumer level hardware). So generally, borders are best avoided today. If you want to seamlessly tile large textures, you can still do so by adjusting the normal texcoords.There is one exception, though. Instead of supplying per-pixel border data, you can also specify a constant border colour. If your texture repeat mode is set to CLAMP (not CLAMP_TO__EDGE !), and you have a GF3 or above, then the bilinear/anisotropic filter will sample the border colour at edge pixels. This guarantees, that the texture border will always fade to a constant colour/value, regardless of the texture''s actual pixel data. That''s useful to create certain special effects, especially combined with depth maps for shadow mapping. It lets you specify a constant depth value at the border, which will then be applied to all the parts of the geometry, that are not included in the depth texture projection. Very convenient.;  Almost all hardware today will not accelerated texture borders.  The drivers will punt to software rendering.  So don''t use them unless you''re not expecting real-time frame rates.quote:Original post by Yann L  There is one exception, though. Instead of supplying per-pixel border data, you can also specify a constant border colour. If your texture repeat mode is set to CLAMP (not   CLAMP_TO__EDGE !), and you have a GF3 or above, then the bilinear/anisotropic filter will sample the border colour at edge pixels. This guarantees, that the texture border will always fade to a constant colour/value, regardless of the texture''s actual pixel data. That''s useful to create certain special effects, especially combined with depth maps for shadow mapping. It lets you specify a constant depth value at the border, which will then be applied to all the parts of the geometry, that are not included in the depth texture projection. Very convenient. ATI cards have always supported GL_CLAMP this way.  nVidia cards were basically broken with this respect from prior to the GF3.;quote:Original post by DannerGL  ATI cards have always supported GL_CLAMP this way.  nVidia cards were basically broken with this respect from prior to the GF3.I know, that''s why I only mentioned the GF3. Actually, ATI chipsets were always closer to the OpenGL reference pipeline than nvidia. For example the handling of user clipping planes. The only problem with ATI were the bad drivers, but thankfully that seems to be a thing of the past now.[slightly offtopic]Although, if you think about it, I''m not entirely sure if the ''broken'' behaviour of GF2- with respect to GL_CLAMP was unintended. Frankly, the way the OpenGL specs define GL_CLAMP is simply retarded. Keep in mind that back then, GL_CLAMP_TO_EDGE didn''t exist. Most people would expect a clamp_to_edge behaviour from gl_clamp, and that''s what early nvidia chipsets did (just as D3D & Glide, where it was/is standard compliant behaviour). Of course, it violated the standard, and lead to compatibility issues with compliant hardware, such as ATI chipsets. I personally think, that nvidia''s stance at that time went something like this: "look, we know we aren''t compliant, but we implemented the functionality as the developer would expect it. At the same time, we''re going to minimize costs, as we don''t have to implement the border sampler, that noone is going to use anyway". That much in nvidia''s defense: I primarily blame SGI for an early OGL design flaw [/OT];  Funny, that must be why sky boxes in ID software games are broken on ATI cards and not NVidia. They must''ve used clamp that will "correctly" cause black lines along the edges on ATI... ;quote:Original post by Anonymous Poster  Funny, that must be why sky boxes in ID software games are broken on ATI cards and not NVidia. They must''ve used clamp that will "correctly" cause black lines along the edges on ATI...   That''s correct.;  Hmm, getting even more off topic with this question but why not...Is there a "list" or anything any where that states which features of openGL was basically artifacts from the past before "everyone" had decent 3d accelerator cards?And also a list of features that really are of no use to game programers...Basically, after working with openGL for past 2 years, I''ve noticed it has a lot of features/functionality that seem to have no use with modern 3d cards (and by modern I mean as old as geforce 2), and also some that just seem completely oriented towards things other than game dev.Some that come to mind for me are:- Immediate mode - Nurbs- texture borders- Feedback mode, and even selection (except for level editors)- Indexed color mode- the entire quadrics stuff- tesselators- edge flagsI loaned my redbook out today or I''d list some more I feel are basically pointless for game devs...  anyone else got any they''d add to that list or argue against the ones I did include?Jeff;quote:Original post by duke   I loaned my redbook out today or I'd list some more I feel are basically pointless for game devs...  anyone else got any they'd add to that list or argue against the ones I did include?Other than Direct3D, OpenGL was never intended for game development.  It was originally designed for use in professional simulation and visulization systems, and that's still where its primary field of application is: industrial applications, medical imaging, flight simulation, military uses, architecture, CAD/CAM, virtual reality, CAVE/RAVE systems, etc. Carmack started to abuse it for games years ago (thankfully I'd say ), but it was never intended for that.But anyway, there is one thing you have to keep in mind: OpenGL was developed with hardware support in mind, from the beginning on. That was at a time, where the normal user didn't even know what a 3D chip was, but OpenGL was used on million-dollar SGI graphics supercomputers, that did very well feature hardware acceleration for most features.About your list: immediate mode, atlthough not very powerful, can be very convenient to quickly test certain things. Under certain circumstances, it can even be faster than VA/VAR/VBO !Nurbs + tesselators & co: are you kidding ? HOS are the future in game development, my friend. The only problem being, that modern 3D cards are not yet modern enough for the really interesting parametric geometry. That will definitely be popping out more and more in the next couple of years.Texture borders, index mode and edge flags are definitely relicts of the past. No use for them anymore.Feedback mode is, uhm, Evil™ In my opinion, that is, and in the one of hardware developers (feedback and selection mode are a nightmare to consistently implement with all other parts of OpenGL).[edited by - Yann L on July 1, 2003 9:13:15 PM];  Some way to select objects is absolutely necessary in games. Whether you''re picking up an object in an RPG or selecting units in a strategy game by clicking on them, it''s much faster and easier to use the API functionality than to code your own solution. (Not that the implementation couldn''t be improved) 