Light Distance - Object Distance - Artifacts

OpenGL Development JOGL Development
#1

I’m drawing a 3D textured Earth (gluSphere) and a billboard effect for the sun (gluDisk) and if I don’t set the light distance and the object distance relative close then I get the artifacts that you can see on the first attached picture…the artifacts on the Sun (the black unpainted polygons that change if I rotate the scene). It seems like my near vs far clipping planes are probably part of the problem but I’m not sure…in Java3D I know the ratio of those distances (back to front clipping plane) had to be about 3000 because of the zbuffer but I’m not sure that’s the same in JOGL/OpenGL. Does anyone have a suggestion?

Also, as a second question, the second attached image shows the earth day night terminator/shadow that is very sawtooth looking…I know part of this is due to number of segments the sphere is broken into but is there some blending or lighting call that I should be making to get rid of this sawtooth pattern and instead make it a smooth day to night transition? I know if my sun in not tilted below the earth equator that I don’t see this issue, but once the sun is below or above it at some angle and hence applying the light at some angle, the I do see the sawtooth.

Thanks

Could not attach…folder is full…here are links:

 http://zaczek.com/joglutils/earth1.jpg
 http://zaczek.com/joglutils/earth2.jpg
#2

For the artifacts around the sun, what immediately came to mind was gluperspective()and setting the zNear to zero as done in many online tutorials. But if it’s not that I have no ideas, and similarly for the stair step lighting on the earth, the only thing I can thing of is GL_SMOOTH vrs GL_FLAT.

#3

re: the sawtoothed terminator

Check the attenuation factors for the light source. I have had similar effects with gluSpheres when the attenuation factors were all set to zero.

#4

When I set the gluPerspective near to zero I got even worse results…my earth (which is closer to the eye) becomes horribly speckled like the sun was (http://zaczek.com/joglutils/earth3.jpg)

and when I rotate the view so that sun disk is behind the earth, the two seem to blend together (http://zaczek.com/joglutils/earth4.jpg).

For the lighting I am using GL_SMOOTH.

From reading the Redbook, the attentuation factors are by default:
GL_CONSTANT_ATTENUATION 1.0
GL_LINEAR_ATTENUATION 0.0
GL_QUADRATIC_ATTENUATION 0.0

When I try to change either the linear or quadratic or both to anything but 0.0 I get a dark scene…ie I don’t see any light only the little ambient light lets me view the scene but I no longer have a day/night terminator - and I’m talking about just changing the values from 0.0 to even 0.0001. Mind you I don’t understand any of this attenuation stuff as of yet so I’m just hacking my way through it.

thanks for the help thus far.

#5

I bet you glScale the sphere, which also scales the normals. (!!!)

Invalid normals (especially when they are way too big) tend to be either 0 or 1 when shading occurs (after clamping).

#6

I’m sorry I wasn’t at all clear about that, I was meaning that having the zNear set to zero, as in how many online tutorials show, can cause those sort of problems. As such set zNear to a larger value like one.

#7

I am not using glScalef (any more) for the scene.

I initially started with the entire solar system and I placed all objects in the correct relative distances and sizes using the kilometers as my scale. I did exaggerate the Sun size so it would be better visible but I changed the size within the gluSphere() function and not through a glScalef. When I had the entire solar system the far planets would blend with the scene and I could not figure out how to fix it.

Since then I’ve reduced my viewer to just the Earth, Moon, Sun and the International Space Station in orbit around the Earth. Because I want to be able to be zoomed out around the Earth and also be able to zoom in close to the space station I used gluPerspective with a 0.01 for the near plane and 2,000,000.0 for the far plane…I’ve been messing with all different sizes and I’ve just confused myself. I need to go back and do a parameteric study of the distances I’m using to ensure I’m just no exceed the zbuffer limits (if they exist) - I was told that a light source should not be more than 600,000 units away from an object otherwise the light won’t work correctly on that object.

I’m trying to keep the distances on the objects to be correct relative to each other and to have the sizes of the objects use the same distance scaling (ie if I use kilometers for distance than the object size should be in kilometers). The primary reason is so that I can represent the light angles as accurately as possible both on the earth but also on the moon and any other planets I add. I know I’m screwing something up here and I just need to have the code output for me all values so I can better see the issue. Until then I’ll probably be wasting your time asking this question.

#8

I’m need to keep the zNear to be relative small because I want to be able to zoom very close to a 3DS model of the International Space Station that I have in the orbit and if I keep the zNear at 1.0 that represents a distance of 1.0 km (or 1000m) in the scale that I’m putting everything in and hence it would be clipped out if I tried to zoom to it. I don’t know if I could dynamically alter the zNear distance as I’m zooming in to the object…and even if this would be possible. I would have to figure out which object I’m zooming to and this might not even work anyway because the issue would still pop up if I was zooming to the space station and I had the sun in my background, in which case I would initially be fine (say if it worked) but then when I change the near plane to 0.01 again so that I could see the space station I would again have a bad value with respect to the sun that is in the background --gosh I hope that made sense.

#9

Yeah, theres no chance you’ll be able to do that really. Even 32bit floats aren’t going to give you enough precision for an entire solar system (and I’m not sure doubles would either). And on top of that depending on the graphics card various bits of the rendering pipeline may only be 16bit anyway, so you’re going to get serious issues.

The typical approach to solar-system style rendering like this is to render each body (earth, moon, sun, etc.) individually in their own coordinate system to a texture. Then as a final step you use these textures as billboards to make your final scene. You’ll probably also need some kind of hiraical coordinate system to keep track of everything at the solar system level.

#10

Thanks for that info…you are absolutely right and I was hoping that by now the graphics cards would have improved to the point where this would be possible. I was mainly trying to avoid doing these advanced concepts and hoped that I could get away with things in a simple manner. Well, at least I reduced my current task down to just the Earth, Moon, Sun and ISS…I’ll probably need to add Mars at some point but I definitely will need to learn some of these graphics “tricks” first…I’m just an impatient person so I want everything now. :slight_smile:

#11

It’s actually less a graphics card issue, but more of a floating point issue. You have a near infinite range, but very poor precision as you get far from the origin.

#12

You are also correct that the floating point issue is the cause…I really should have been clearer with my criticism. The fact that OpenGL is still using floats instead of higher precision values is what surprises me but I suspect there is a valid reason or valid limitation.

#13

All gfx-cards use 32bit floatingpoint natively these days. Any more bits and you’ll lose a LOT of performance.

#14

Well for stuff like this, even 64bits won’t get you much further before the same artifacts start popping up. At which point you’re using 2x as much memory, and either 2x as much time or 2x as much hardware, to produce the same result.

Also here’s a specification page on gluPerspective (even though it’s for Python the spec is the same, only the generic GL version has formatting errors on some of the formulas), where in the “Notes” section it talks about why you don’t want zNear being small and the resulting loss of precision.
http://pyopengl.sourceforge.net/documentation/manual/gluPerspective.3G.html