View Full Version : Rendering error when translating far.

03-29-2008, 05:27 AM
I'm not sure if this has been answered before, but I dont know what I should search for to answer my problem, as Im not quite sure what is wrong.

Simply put, when I move the camera around, whenever an object is within view, it seems like only random faces of it is rendered.
Even gl-lines are rendered randomly, but if the camera is standing still, there is no flickering.

This leads me to belive there are some rounding/calculation/accuracy problem somewhere.
Since the resulting calculation from a specific angle always is the same, there is never flickering when the camera is still.

For this problem, I have tried to switch everything I use from floats to doubles, but with no difference.

My program uses extremely large objects (scaled big, not many polygons).
I use textured Quadric spheres.
I also translate the objects very far away (since they are so big).

This problem arose when I started making the objects really big, and translating them very far away.

My frustrum looks something like this
gluPerspective(60.0, (GLfloat) w/(GLfloat) h, 0.1, 100000000.0);
And, the objects beeing translated are moved something like 50000000000000 (13 zeroes) or 5.0*10^13 if you prefer.

I'm guessing the problem lies here, but I dont know why it is a proble, nor what I can do to fix it.

Another interesting features, is that if objects are close to the centre of my scene (not translated far), they dont have this bug.

Of course, using smaller objects translated shorter is a solution, but it would not be a good solution for me, as I would like to be able to place objects where they are supposed to be.

Anyone got any ideas?

03-29-2008, 05:43 AM
Z-fighting (http://en.wikipedia.org/wiki/Z-fighting)

03-29-2008, 05:43 AM
Commonly known as "z-fighting", the randow flickering you see is due to imprecision during depth testing : faces from behind incorrectly appear in front other faces.
You can reduce this problem by reducing the magnitude of your znear/zfar range. Instead of [0.1, 100000000.0] try to increase the znear as much as you can, and reduce also the zfar if you can.

03-29-2008, 05:55 AM
Interesting reading indeed, Thanks alot.

I am making a space-related scene btw (but I suppose this was already obvious).

From reading about the Z-fighting, I have one other question then.
If I scale everything down quite a bit, would then any ship/cockpit I make, thus equally down-scaled then, have the same problem again, since the new faces would be similarly closer to eachother?

Also, is it possible to increase the Z-buffer depth in some way?

03-29-2008, 06:04 AM
Reducing the znear/far range reduced/solved the problem, albeit I can only see the closest thing.

But there is another issue that is a little strange, I have 2 planets quite far away from eachother, but from the "holes" in one of the planets, I can see the others planets (with the same bug on them too, of course).

But, if I move the camera inside a planet, I see the textures of the apropriate planet, just from the inside.

Why do I see through the planet if the backside faces of the closest planet are fighting the nearest faces?
I'm just wondering since the planet further away, should be so far away that it does not really be any doubt as to it beeing furthest away.

This also goes for some gl-lines I'm using that are also not drawn even if there is nothing behind them...
Is that still Z-fighting, or do I perhaps have multiple bugs at once here?

03-29-2008, 07:57 AM
From reading more about the Z buffer, I realize the problem, and its solution, is more complex than just a single function call.

Still, thanks alot for pointing me in the right direction, at least now I know what's wrong :)

Guess I have to try a lot of different approaches before I find a good solution to this problem.