I’ve sent it.
Thanks
Bruno
Hmm…yes perhaps there are z-buffer problems in Q3 if you move very far away of objects(in those really big levels) but it happens in my engine even in smaller rooms…It is not nearly is extreme as in brunos viewer and I still think it is not the same problem as Brunos.And I do already use a 24-bit z-buffer and 32-bit color depth…
What exactly happens in my engine is the following:
If you are for example in the small room with that impressive bezier-tongue in Q3DM1 and look at those two lionheads left and right of the tongue you´ll see the problem:
If you are near the heads everything looks correct however if you move in one of the doorways and look at the heads you´ll see that the connection of the heads with the wall begins to “swim” if you move a little nearer or farther away…
Any ideas?
Greets,XBTC!
Ok, I just looked at Bruno’s code and from what you describe XBCT, you have a problem similar to what Bruno was having. In this case the precision was not being lost due to zNear and zFar but due to the other planes of the view frustum. All I did was use some code to set the projection matrix using fov, aspect, zNear, and zFar (essentially gluPerspective) and his code snapped into working order. So you might want to check all your planes of the view frustum to see if they really make sense.
Don´t think there´s anything wrong with my frustum-code:
I use gluPerspective with the following params:
fov=45;
aspect=width/height;
zNear=-1;
zFar=7000;
Thanx anyway!
Greets,XBTC!
[This message has been edited by XBCT (edited 07-28-2000).]
Do you want to try DFrey code??
It works perfectly with me…
Bruno
XBCT, Znear should never be negitive. Try changing that to a positive no zero number.
Why shouldn´t zNear be negative?
Anyway I´ll try it and tell you if it worked…
Thanx for your reply…
Greets,XBTC!
XBCT-
Why would you want your viewpoint to be a negative number? You wouldn’t want to see
that which is behind you
sixb0nes www.xpression.org
Sixbones:Yes it makes no sense,but it still shouldn´t make errors in a big distance from the viewer.
Greets,XBTC!
Sorry…I looked at my code today and saw that I have zNear=1 in my code.However now I set zNear to 10 and all problems are gone…Any ideas why?
Greets,XBTC!
[This message has been edited by XBCT (edited 07-29-2000).]
That is exactly what everyone’s been saying. The RATIO between zNear and zFar is what matters. You can have zFar at 100,000, if you put zNear at 100 – that gives a ratio of 1:1000. If your implementation uses wBuffering instead of zBuffering, it is somewhat less sensitive to z depth, but only somewhat. Let’s call it “differently sensitive” 
You can actually easily calculate what your zNear should be. Assuming you let the player come no nearer to a wall than r and your FOV from center is f then your zNear should be min(r * [i]cos/i / [i]sin/i , r) (draw it out on a piece of paper and it’ll make sense). This guarantees that walls will stay “solid” on the sides of the screen, but doesn’t make the zNear smaller than necessary.
PS: If you know what kind of z ratio you need to maintain, you can easily find zFar by just multiplying zNear by the ratio. The higher the ratio, the more things will “swim” or “stipple” as you move further from them. Also make sure you’re not accidentally using a 16-bit or (scary thought!) 8-bit Z buffer.
[This message has been edited by bgl (edited 07-30-2000).]
[This message has been edited by bgl (edited 07-30-2000).]
blg:Thanx for replying,your idea seems to be the way to go…
Thanx again!
Greets,XBTC!
I am working on a bsp reader render also but am still laying the ground work. I was just curious, but why use r/w depth buffering when rendering? The BSP will automatically order the polys for you. Wouldn’t it be best to render the map with the depth buffer in write only mode than render the entities with the depth buffer in r/w mode? Since the depth buffer sucks up a significant portion of video RAM bandwidth it should help speed things up by only doing writes instead of read compare and then write. I would think so anyway. This is not argument against the wise advise of limiting the near to far ratio to get the greatest depth buffer resolution. However, if you are rendering the map in write only mode you shouldn’t see any artifects due to lack of z-buffer precision. Am I way off on this???