GL shadowing

Discussion forum for Celestia developers; topics may only be started by members of the developers group, but anyone can post replies.
Topic author
ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 19 years 7 months

GL shadowing

Post #1by ElChristou » 19.11.2007, 13:12

Chris, here is a basic comparison between some real time OGL rendering; 2 are from 3D softs from the main viewpoint (real time window), the rest is a sequence within Celestia.

We can see how within Celestia, a lowres dish get some poly artifacts depending the light direction. The problem is that this kind of artifacts are almost (soft B) or never (soft A) visible in other apps (I've tested 2 more app). So the question is if this part of the rendering can be improved.

Actually of course the only way to eliminate these shadowing artifacts is to increase greatly the number of poly, but clearly it's not a very cool option if one need the smaller possible poly count...

Image
Image

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 7 months
Location: Seattle, Washington, USA

Post #2by chris » 19.11.2007, 18:28

First thing: the lighting in both images from the 3D modeling software is much softer. There's a large amount of ambient light in the scene, which will tend to mask artifacts from low tessellation. Try turning down the amount of ambient light in the modeling programs and my guess is that you'll see similar results as in Celestia. I can already see tessellation artifacts in the top two images.

Any other differences may be attributed to vertex normal generation during the conversion from 3DS to cmod (or 3DS directly to Celestia's internal mesh format.) There could be some sort of bug here. The modeling software knows that the object was created from a section of a sphere, so it can calculate the exact vertex normals to use. These normals are unfortunately not saved in the 3DS format, so they need to be regenerated from face normals when the model is converted to a cmod. This is unfortunate; it would be nice to save to a format that preserved the vertex normals, and then convert this to a cmod. Or have something like Selden's script for Anim8or that lets the program write a cmod directly. Still, I put most of the blame on the softer lighting in the modeling software. Vertex normal generation from face normals isn't perfect, but it should be good enough.

Finally, the ultimate source of these artifacts in both Celestia and the modeling programs is that lighting is calculated at vertices and the resulting color linearly interpolated across the polygonal faces. This is only an approximation--for more accurate results, the surface normal should be interpolated (NOT linearly), and lighting should be computed at every pixel. Celestia already does this for specular highlights in the OGL 2.0 path. Specular lighting tends to be much more non-linear than diffuse lighting, so it provides a very obvious benefit for coarsely tesselated models. In fact, models with specular materials probably look much better in Celestia's OGL 2.0 path than they do in your modeling software. The difference with diffuse lighting is much more subtle, but as you've shown in your images, there's still some room to improve.

--Chris

Topic author
ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 19 years 7 months

Post #3by ElChristou » 19.11.2007, 19:07

chris wrote:First thing: the lighting in both images from the 3D modeling software is much softer. There's a large amount of ambient light in the scene, which will tend to mask artifacts from low tessellation. Try turning down the amount of ambient light in the modeling programs and my guess is that you'll see similar results as in Celestia. I can already see tessellation artifacts in the top two images.

True, there are some artifacts on the top examples but smooth enough to not being visually too perturbing... Now, actually I had to fight quite a lot to obtain the Soyuz as it is now (some meshes are really low) because you have to tessellate by hand the zones too problematic within Celestia to reduce the bad shadowing... (and still the result is far from being perfect...)

chris wrote:...In fact, models with specular materials probably look much better in Celestia's OGL 2.0 path than they do in your modeling software. The difference with diffuse lighting is much more subtle, but as you've shown in your images, there's still some room to improve.


I cannot say yet for OGL2, but on others paths it's not the case, on the contrary adding spec tend to increase the artifacts...

Anyway, if you add a note to improve this somewhere in your ToDo list it would be great!
Tx for the above explanations.
Image

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 7 months
Location: Seattle, Washington, USA

Post #4by chris » 19.11.2007, 20:01

ElChristou wrote:
chris wrote:First thing: the lighting in both images from the 3D modeling software is much softer. There's a large amount of ambient light in the scene, which will tend to mask artifacts from low tessellation. Try turning down the amount of ambient light in the modeling programs and my guess is that you'll see similar results as in Celestia. I can already see tessellation artifacts in the top two images.

True, there are some artifacts on the top examples but smooth enough to not being visually too perturbing... Now, actually I had to fight quite a lot to obtain the Soyuz as it is now (some meshes are really low) because you have to tessellate by hand the zones too problematic within Celestia to reduce the bad shadowing... (and still the result is far from being perfect...)

The main (and possibly only) reason that the top images are smooth is because of the different lighting conditions. With a single direct light source (typical in Celestia), the linear interpolation artifacts are most visible. Reproduce the same lighting setup in the modeling software, and you'll get similar results as in Celestia.

chris wrote:...In fact, models with specular materials probably look much better in Celestia's OGL 2.0 path than they do in your modeling software. The difference with diffuse lighting is much more subtle, but as you've shown in your images, there's still some room to improve.

I cannot say yet for OGL2, but on others paths it's not the case, on the contrary adding spec tend to increase the artifacts...

Right, because on the other render paths, the results of all lighting calculations are linearly interpolated across triangles, and specular lighting tends to vary extremely non-linearly across pixels. Without OGL 2.0, the only way to improve the appearance of specular highlights is to add more triangles the to mesh.

Anyway, if you add a note to improve this somewhere in your ToDo list it would be great!
Tx for the above explanations.


There's nothing that can be done except:
1. Preserve normals in the conversion to cmod (it *might* help)
2. In the OGL2.0 path, compute diffuse lighting per pixel instead of per vertex--but this comes at some performance cost, and on for most hardware, you're probably just better off adding some extra triangles to the model.

--Chris

Topic author
ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 19 years 7 months

Post #5by ElChristou » 19.11.2007, 20:28

chris wrote:The main (and possibly only) reason that the top images are smooth is because of the different lighting conditions. With a single direct light source (typical in Celestia), the linear interpolation artifacts are most visible. Reproduce the same lighting setup in the modeling software, and you'll get similar results as in Celestia.

Now that you say that, seems to me that my above comparison is plain wrong because most softs use cubemaps to fake their lightening for better realtime performance... So actually I cannot be sure to reproduce the same environment... Now if I shot a still in basic OGL shaded path I still have a quite smooth result (no major artifacts) even with 1 light (no more the real time lightning but a spot playing the Sun's role)...

chris wrote:There's nothing that can be done except:
1. Preserve normals in the conversion to cmod (it *might* help)
2. In the OGL2.0 path, compute diffuse lighting per pixel instead of per vertex--but this comes at some performance cost, and on for most hardware, you're probably just better off adding some extra triangles to the model.


1. Do you think it worth trying?

2. In this case of course I agree.
Image


Return to “Ideas & News”