"Those values you have used for the near and far clipping planes are far too big "

is 10000 really too big ?? I thought 65535 could easily fit into a 16-bit memory space. Anywayz, maybe itz my complete ignorance on near/far plane and the technologies behind Z-buffer which has led me into this.

i''m still in my skool so didn''t get the chance to test all your theories but i will definitely test all ur theories as soon as i get back home.

But i''m still worried about one thing. Just as playmaker said "try to keep it around 100, " if i really keep the far plane around 100 then how the hell i''m gonna render a big quake level.

Seems like i really have to run back home and check the demo again .

quote:Original post by browny
is 10000 really too big ?? I thought 65535 could easily fit into a 16-bit memory space. Anywayz, maybe itz my complete ignorance on near/far plane and the technologies behind Z-buffer which has led me into this.

You''re right for integer value. But I thing that Z-buffering use non-integer value (floating point or fixed point, I don''t remember). Thus 10000 might become too much



----
David Sporn AKA Sporniket

Perhaps this will help you understand the zbuffer better:

From the OpenGL faq:
http://www.frii.com/~martz/oglfaq/depthbuffer.htm

quote:
Now let''s plug in some numbers, for example, n = 0.01, f = 1000 and s = 65535 (i.e., a 16-bit depth buffer)

zw = 1 => ze / we = -0.01000015

zw = s-1 => ze / we = -395.90054

Think about this last line. Everything at eye coordinate depths from -395.9 to -1000 has to map into either 65534 or 65535 in the z buffer. Almost two thirds of the distance between the zNear and zFar clipping planes will have one of two z-buffer values!

---------------------------

I hate have to split some cost of something between three people when you are out to buy something and not being able to do the split correctly due to our inferior base-10 system. -- felonius

Hey guys, it WORKED !!!!, Coool
I really didn''t have an idea that a simple Z-buffer could have some so much maths ( or whatever u call it ) in it.

Even when i changed my far plane to some small value, like 500 , the damn program wouldn''t still work. I was just about to pull all my hair off and then i dont why i suddenly decided to change my near plane from 0.1 to 10 ( maybe outta frustation ), and BOOM !, it worked. So not only the far plane, but also the near plane which is an important issue. So , now i feel that the values that are actually written on the Z-buffer are actually some sorta scaled value between the near and far plane. Whatever, i might be wrong...

Wow, i''m quite amazed at the evolution of thoughts and doubts that went all along this discussion, which actually started with a bizarre texturing problem and ended with solving a Z-buffer problem. Cool isn''t ? We almost had some sorta research paper done on Z-buffer. Now i feel that the topic of this discussion should actually be "when Z-buffer plays prank" . But i guess, itz too late. Time to call this discussion off.

CASE CLOSED !

I love you gamedev
Zahid

If you haven''t read the link I posted above, I recommend that you do, it details exactly the behavior that you just described discovering on your own.

The zbuffer is not linear from the near to far plane, it works much like human vision, giving finer granularity to objects closer to the viewer. That''s why changing your near plane helped when changing the far plane didn''t.

The link I posted above to the FAQ has tons of other good info, and is a great read for those of us learning OpenGL.

Glad you got it working.

---------------------------

I hate have to split some cost of something between three people when you are out to buy something and not being able to do the split correctly due to our inferior base-10 system. -- felonius