🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
starnge edges... ( pic included)
Author
ok... I said I would include a pic of what happens to my cube...
I mean it's not always ... Nehe's tuts are fine but I did like a cube with a (-50,50) edge ( maybe this is it ? guess not cause I saw a Nate's example with large obejcts ... damn what am I talking about... no large objects in ogl ? bull...t ( sorry 'bout tahat ) )
In my previous post I asked if it was a problem of counter/clockwise face building with texturing ( in my opp. not ) or a problem with the fact that face has two sides (my opp. - not ) so what is it ??? my card ??? damn ... I've just bought it.
note that i used quads...
anyways here's a pic : link
notice edges and vertices ... !
thanks anyone
Pet
Edited by - Pet on 8/17/00 9:59:17 AM
If the cube is little, is it rendered well ?
Ogl is independent from z-buffer depth and even 16 bit is not low enough to cause this problem.
Try to enable GL_CULL_FACE and disable GL_DEPTH_TEST (a cube can be rendered without z-buffer).
The same ''effect'' can be achieved with bad coordinates (intersecting lines) so try to render in wireframe by disabling GL_TEXTURE_2D and see if everything is OK.
Ogl is independent from z-buffer depth and even 16 bit is not low enough to cause this problem.
Try to enable GL_CULL_FACE and disable GL_DEPTH_TEST (a cube can be rendered without z-buffer).
The same ''effect'' can be achieved with bad coordinates (intersecting lines) so try to render in wireframe by disabling GL_TEXTURE_2D and see if everything is OK.
It really looks like a znear/zfar clipping problem. If you have a 16 bits Z-buffer, check that you have a low (~500) ratio. Try to play with the values to see if it helps to fix the problem.
Y.
Y.
It''s a Zbuffer problem, change it to 32 bits.
It might be the znear/zfar ratio.
I had that problem to, if you want the source to fix it, email-me.
Bruno
It might be the znear/zfar ratio.
I had that problem to, if you want the source to fix it, email-me.
Bruno
ah, yer gettin the shark teeth.
when i get those, i know i''m not culling the backface. try what Andrea said.
a2k
when i get those, i know i''m not culling the backface. try what Andrea said.
a2k
Author
hi... thanks everyone !
you say it''s a znear/zfar clipping problem , heh ?
well, as soon as a check it ( I''m in a work now ... I''m supposed to work ! ) I let you know...
and Bruno... yes I''m interested in a source,but let me fix it myself first
btw... I was going to ask about glPerspective and that cliping.
Maybe you can help me guys...
Does it affect objects or speed somehow ? I mean, what''s the difference between having small objects and small clipping range or large objects and large rang ... or sth like that ?
you say it''s a znear/zfar clipping problem , heh ?
well, as soon as a check it ( I''m in a work now ... I''m supposed to work ! ) I let you know...
and Bruno... yes I''m interested in a source,but let me fix it myself first
btw... I was going to ask about glPerspective and that cliping.
Maybe you can help me guys...
Does it affect objects or speed somehow ? I mean, what''s the difference between having small objects and small clipping range or large objects and large rang ... or sth like that ?
No speed difference...but pay attention if you have small objects with large clipping range because you can get a precision loss!
If Z-buffer is for example 16 bit you have only 2^16 = 65536 different z values...if you have a clipping range of 65536 meters (again it''s an example) your resolution is 1 meter !
If Z-buffer is for example 16 bit you have only 2^16 = 65536 different z values...if you have a clipping range of 65536 meters (again it''s an example) your resolution is 1 meter !
Andrea: with backface culling the problem could disappear, because the pixels of the front faces do not overlap the pixels of the back faces, but basically the problem is coming from the Zbuffer precision.
Also, you are wrong in saying the resolution is 1 meter. The Zbuffer is using floats, which means you have more Zbuffer accuracy near the Znear than near the Zfar. In fact, AFAIR, 2/3 of your space near the Zfar is mapped to the last bits of the Zbuffer, which means that, if you have a Znear of 1.0 and a Zfar of 1000.0, it''s quite possible that a pixel of a Z=1000.0 and a pixel of a Z=400.0 are mapped to the same Z depth = 65535.
Y.
Also, you are wrong in saying the resolution is 1 meter. The Zbuffer is using floats, which means you have more Zbuffer accuracy near the Znear than near the Zfar. In fact, AFAIR, 2/3 of your space near the Zfar is mapped to the last bits of the Zbuffer, which means that, if you have a Znear of 1.0 and a Zfar of 1000.0, it''s quite possible that a pixel of a Z=1000.0 and a pixel of a Z=400.0 are mapped to the same Z depth = 65535.
Y.
I had never seen any Z-buffer problem with a cube of 50x50x50 with a 16 bit Z-buffer.
For the Z-buffer I''m quite sure that Z-near is mapped to 000..000 and Zfar is mapped to 111...111 (in OpenGL). So if Znear = 1.0 and Zfar = 1000 a Zbuffer LSB is equal to (about) 1000/2^N.
In the same manner if Znear = 1.0 and Zfar = 65536 what is the LSB ?
For the Z-buffer I''m quite sure that Z-near is mapped to 000..000 and Zfar is mapped to 111...111 (in OpenGL). So if Znear = 1.0 and Zfar = 1000 a Zbuffer LSB is equal to (about) 1000/2^N.
In the same manner if Znear = 1.0 and Zfar = 65536 what is the LSB ?
Author
hi...
I solved the problem ( sort of ). Didnt change to 32 bit because ,like ,more memory is needed for one pixel , right ( 4bytes ) ?
So it would run faster on 16 bit ? Anyway I had :
gluPerspective(..., 0.1f , 900) and changed it to
gluPerspective(..., 1 , 900 ) and it works ?
Starnge !
thanks for explainig the depth buffer, actually I didnt care much about it ...
so assuming 16 bit per pixel when we have
near-far : 1-900 then 0 binary means 1 dec and 1...1 ( 16 of them ) means 900 ??? all the rest is being cut,right ?
so what about large worlds ? Is fog a solution ( you know add fog far away to avoid seeing the clipping ) ?
What is the good solution for the size of the objects ( ex. in a game ) , what do you think , what are your suggestions ?
thanks again
Pet
Edited by - Pet on August 22, 2000 11:50:58 AM
I solved the problem ( sort of ). Didnt change to 32 bit because ,like ,more memory is needed for one pixel , right ( 4bytes ) ?
So it would run faster on 16 bit ? Anyway I had :
gluPerspective(..., 0.1f , 900) and changed it to
gluPerspective(..., 1 , 900 ) and it works ?
Starnge !
thanks for explainig the depth buffer, actually I didnt care much about it ...
so assuming 16 bit per pixel when we have
near-far : 1-900 then 0 binary means 1 dec and 1...1 ( 16 of them ) means 900 ??? all the rest is being cut,right ?
so what about large worlds ? Is fog a solution ( you know add fog far away to avoid seeing the clipping ) ?
What is the good solution for the size of the objects ( ex. in a game ) , what do you think , what are your suggestions ?
thanks again
Pet
Edited by - Pet on August 22, 2000 11:50:58 AM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
