   Distance problem with models
  hi, while developing my level editor i noticed something weird happening with model rendering. When a model is far away it doesn't render corectly in some cases, like polys are overlaping. But at close distance everything is right. The models are created using 3dsmax and exported through a script i wrote. what i'm asking...might this be a modeling problem or has something to do with rendering. I've added two screenshots from my editor to see what's actually going on. Thanks very much. Far view (wrong)Close view (correct)[edited by - pasman on September 25, 2003 6:29:29 AM]
  Try increasing the z-buffer depth. ;  Something like this can happen when the Depthbuffer (or also named Z-Buffer) isn''t presice enough. In my Engine i''m useing a 32bit-Depthbuffer, at lower sizes (like 16bit) it often comes to the phenomenon, that faces that are definitly behind other faces come shining throu. This is mostly the cause, when you use Depthbuffers lower than 32bit precision. So i think it''s a good hint, to first look at the Depthbuffersize first. ;  ZBuffer-precision is the problem!Increasing precision (16bit -> 32bit) is an easy solution, but it comes with some drawbacks that can be critical.Higher Depth-precision means:-Higher bandwith-requirements-Higher memory-requirementswhat follows is a lower overall fillrate....Better solutions:WBuffering -> Modify your projection-matrix so that it writes the w-component of the transformed 4-comp.-vector, instead of the z-components.  Z=1/W -> That means ''precision'' is higher near the cam as its farther away from the cam. W-values are ''spread evenly'' along the hole clipping-distance.Decreasing Clipping-distance:Moving the near-clipping-plane farther away from the cam and using a ''nearer'' far-clipping-plane helps alot!! because your deapth-bits are distributed on a shorter ''distance''.What if a costumers-pc doesn''t support 32bit-buffers at all?;  if you find a consumercard that actually supports 32bit depth right now please tell me   most common is that in 16colordepth you get 16bit z-buffer, and in 32bit colordepth you get 24bit zbuffer and 8 bit stencil.. (you doenst get 32bit even it you doesnt use stencil)most of the time you have more stuff on screen so that you should have to much to look at near the camera to be bothered about some tiny pixels flickering in the back. If you dont have much in front, then move the zNear plane away from the camer ( as close to the closes object you can actually..) that fixes most of those problems up.;  hi, i placed the near clipping plane further away from the camera and it seems it fixed my problem...so thank you v much ;  hi again, i didn''t want to open another thread since this is also model related. I''ve got a tree modeled and for a branch i use a quad and an alpha-masked texture. But in some cases when i blend the branches(using glBlendFunc(GL_ONE,GL_SRC_ALPHA)) some of the objects behind are hidden by the ''invisible'' part of the texture. But the terrain and sky can be seen. Also some of the brances in the same tree are also hidden. Anyone has an ideea why this might occur? Thanks a lot.Screen shot with the annomaly;  You need to sort the transparent polies by depth, and render them back-to-front.What''s happening is that the front ones are being drawn, and even though they don''t fill the whole quad with color info, they DO fill the whole quad in the depth buffer. When the rear one is drawn, it fails the depth test, and nothing is drawn.Disabling depth testing while drawing the leaves is an easy quick fix, but it''s rather ugly. ;  hmmm...by disableing GL_DEPTH_TEST i get indeed bad results but by using glDepthMask(GL_FALSE) apparently works ok...the leaves are obstructed by closer objects as they should and everything works ok...should i expect bad results in any case for this? thx ;  Hmmm.... the shot-link doesn't work anymore....but maybe alpha-testing should fix depth values at transparent texels, that should be enough, if the other parts of the texture are 'opaque' enough, so that a missing poly behind is not quite noticeable   [edited by - Martin Foerster on February 13, 2004 10:18:11 AM]