PDA

View Full Version : Vanishing spheres...



Edwin
03-08-2000, 03:17 AM
I have a problem with vanishing spheres... I am displaying a large sphere (using gluSphere - radius is 13000, for what it's worth) and moving the sphere away from the viewpoint. My z clipping plane is large (250000000.0). However, the sphere vanishes long before I'd expect it to. I've tried moving the z clipping plane further away, but the same thing happens.

Is this a case of the polygons becoming too small to draw? Or am I doing something silly? Would I, perhaps, be better off using a NURBS for this?

I'm using Mesa under Linux.

Thanks,
Edwin.

AndersO
03-08-2000, 05:40 AM
Well, how small are the polygons in the sphere just before they disappear?.

One pixel?

Maybe the polygon disappears because of all vertices ends up in the same place on screen. (On the same pixel)..

Edwin
03-08-2000, 05:57 AM
Hmmm. I'd be happy if they were just one pixel, but the sphere is still significantly large. The effect I get is that the sphere kind of fades out - as if they were being clipped.

I tried using fewer slices for the sphere, but they still disappear at the same point.

Is there perhaps some kind of maximum for the z clipping plane? I can't find any documentation which tells me anything about this...

Edwin.

Sjonny
03-08-2000, 11:19 AM
yep, I use linux too, and I have the same problem. don't care how far/big I set the fustrum, polygons get clipped really early, so I guess it must be a driver problem?
I use a riva128, so if you use the same nvidia driver, the problem must be right there...


[This message has been edited by Sjonny (edited 03-08-2000).]

paolom
03-15-2000, 02:24 AM
The problem could be the precision of the Z buffer. As I read in another thread, the zbuffer must span across the z-range (from nearz to farz), so when zbuffer has few bits the z-fight conditions increase dramatically, due to the stepping of Z values to represent a large range. The only solution to this, is to find a good compromise between Zbuffer precision and Z range.