Celestia Forums

I've been working lately on improving the Celestia's rendering of meshes, which has for a long time lagged behind planet rendering and modern graphics hardware capabilities. I've implemented a lot of things which will make meshes look a lot better:

- Models can be shadowed by spherical bodies. Eclipse shadows appear on irregular bodies just as they do on spherical bodies. Satellites in low earth orbit will slip in and out of shadow as the orbit over the night side of Earth. Irregular objects will still not cast shadows themselves, however; that's work for the future.

- The specular lighting model uses a local viewer; this slightly improves the appearance of specular highlights. It affects both spheres and models.

- Models can use emissive, specular, and normal maps (emissive maps had been supported before)

- There's a new 'per-pixel specular' mode that greatly improves the appearance of specular highlights, especially on models with sharply curved surfaces or low tesselation. The tradeoff is that it's slower. I haven't decided how this mode should be toggled on and off.

- When per-pixel specular mode is on, specular highlights will be rendered correctly on normal mapped surfaces (prior to these changes, the normal map is disregarded for specular lighting, with the surface modification only affecting diffuse lighting--it's fine for oceans, but not generally correct.)

Here's demonstration of per-pixel specular lighting. This 'glossy Mars' is not meant to present a realistic example, although specular highlights can be very useful for visualization of surface relief. I anticipate that per-pixel specular lighting will be much more useful for meshes of spacecraft; I'm still in the process of creating a good demonstration.

No bump map (basic render path) or specular lighting:


Bump map, per vertex specular lighting (vertex program path)


Bump map with per pixel specular (OpenGL 2.0 path); this image also demonstrates that the new rendering mode works with multiple light sources.


The new effects are only available in the OpenGL 2.0 render path.

--Chris

Cool! The per pixel speculars will be great on icy moons and metal objects. I love that you are posting a preview of things to come here. I wish it would happen more often from the devs so we non-devs can get a grasp on the future. Especially for model/addon builders.

Wow Chris, this improvement looks very interesting, and I suppose that other effects could be achievable after this, now or in the next future.
BTW, I can't wait to see what happens to spacecrafts!
And I fully agree with Buggs, thank you for sharing the state of art of next changes, well done!
Bye

Andrea

Wonderful

Does this improvement is only for planet and spacecraft meshes or it runs for nebula meshes too ?

Thanks
JLL

TX for those improvement Chris!
The specular highlights are really much better!
(a pity I cannot use OpenGL 2... ...but this will change soon )

chris wrote:...
- Models can use emissive, specular, and normal maps (emissive maps had been supported before)...

How do you declare a spec or normal map on models?

What do you mean...specular highlights? More like spectacular highlights! ).
That's looking awesome Chris. It's amazing how much more depth this gives to the contours! Is this likely to be in the next release, or a later one?

Damn! I too, do not have OpenGL 2.0 path.

BTW: Roughly, what's the performance cost of this?

ElChristou wrote:TX for those improvement Chris!
The specular highlights are really much better!
(a pity I cannot use OpenGL 2... ...but this will change soon )

Very glad to hear that! What graphics card are you getting?

ElChristou wrote:

chris wrote:...
- Models can use emissive, specular, and normal maps (emissive maps had been supported before)...

How do you declare a spec or normal map on models?

In an ASCII cmod file, a full material definition looks like this:


All these attributes are also available in the binary format. I think that the 3DS file format may also have a place for a specular mask; if so, I can add it to the 3dstocmod converter so that there's a way to get use specular masks without hand editing ASCII cmod files. Do you have a modeling tool that can work with a specular mask?

--Chris

I'm probably being thick here, but... will this help with the problem of some 3ds models suddenly turning emissive when a planet passes into the field of view?

...John...

Chuft-Captain wrote:What do you mean...specular highlights? More like spectacular highlights! ).
That's looking awesome Chris. It's amazing how much more depth this gives to the contours! Is this likely to be in the next release, or a later one?

Damn! I too, do not have OpenGL 2.0 path.

BTW: Roughly, what's the performance cost of this?

The new lighting will be in the next prerelease.

Per-pixel specular lighting requires a good amount of graphics power, especially with multiple light sources. But newer graphics hardware tears through even quite complex scenes like the third Mars image. My GeForce 7900 GTX renders it at 60Hz (refresh rate) even at the full monitor resolution of 2560x1600.

--Chris

Hi Chris,this work looks a great improvement,can't wait to test it out on some models.Will the ability to use spec,emissive and normal maps be useable for 3ds models also,or only on cmod models?In 3ds Max I can add all sorts of maps to the models-specular,glossiness,self-illumination (emissive?),opacity,bump (normal),reflection,refraction,and displacement,but I dont know if all of these links are exported in a 3ds model file.Thanks for all your great work,Jestr

This looks very promising. I can't wait to have it all implemented in the official version. Nebulae need special attention, too.

Here's what I see on my home system after compiling today's CVS code.
I'm getting 60 fps performance at ~1600x1200.
This is seen when I put the following .SSC file in /extras/



vertex shader render path


ogl2 render path

[edit]
Note the highlights on Valles Marineris in the ogl2 path, which are not visible in the vertex shader path.

System:
1GB 3.4GHz P4-550, WinXP Pro sp2
128MB GF 6600GT, ForceWare 84.21
Celestia from CVS
[/edit]

My 64k Earth looks unbelievable with the new code.

Bye Fridger

t00fri wrote:
My 64k Earth looks unbelievable with the new code.

Bye Fridger

Mars, or Earth ? Can we see more ?

Reeeeeeealy starting to think I should give compiling a try again...

Fridger's pic looks like someone took a scoop out of the chocolate ice cream box!

Well, actually, it looks really, really cool. I can't wait for this to be implimented in the next release (or pre-release) of the program!

...John...

I should add that when using normal maps with specular highlights, you need to be very careful about how you generate the normal map and its mipmap levels. Normal map problems that were invisible with simple diffuse lighting can look terrible when specular lighting is enabled. This not something particular to Celestia: specular highlights are higher frequency than diffuse lighting, which changes very gradually over a smooth surface. There are artifacts visible in Selden's image of Mars rendered with the OGL 2.0 path. These are due to the fact that Celestia's default Mars normal map is actually generated at run time from an 8-bit source height map. We should instead include a normal map generated from 16-bit source data. There are some other guidelines for getting the best results with normal maps. I'll post them in the forum soon (unless Fridger beats me to it . . .)

--Chris

8 bit-based normalmaps are even hard to tolerate without the new code! I spent a long time to optimize my 16-bit normalmaps wrto noise. With my present 64k results I see NONE whatsoever.

Bye Fridger

++++++++++++++++++++++++++++++++++++++++++

Announcement:

Soon, I'll publish in CelestialMatters a set of 4 optimized custom normalmap tools that work entirely with the original 16bit signed integer raw elevation maps.

1) They allow to quickly produce >=64k (!) normalmaps or normalmap tiles of highest quality. Neither special knowledge on image manipulation nor powerful computers with lots of memory are required. A complete set of 64k normalmap tiles is produced on my machine in ~15 minutes only, starting from the /original/ 84k 16bit raw elevation file!

2 ) They will be offered for ALL operating systems (Windows, Linux, and MAC-OS (including MacIntels) ) as ready-to-use compiled binaries and in form of a universal source code

3) All operations like rescaling etc are done entirely at the 16bit level whence extremely noiseless normalmaps result, exhibiting proper texel normalization etc.

4) The tools are the first to include a crucial spherical geometry correction that is missing in Chris' nm16 program, and hence in all present normal maps on ML for ~spherical bodies.

5) The resulting normalmap tiles incorporate proper reduction of resolution towards polar latitudes, without loss of quality, which saves lots of disk space.

6) Monochromatic normalmap tiles are replaced by the smallest 4x4 pixel tiles allowed in DXT format, which saves lots of disk space!

7) The tiles of all levels incorporate proper texel normalization!

8 )The 4 tools adapt to big endian/little-endian storage BOTH for computers AND raw input elevation maps!

9) The 4 tools work with STDIN/STDOUT file handles and thus may be
inter-connected like "pipe fittings" according to individual needs.

10) Besides the tools themselves, interested people will find my detailed tutorial about their use and the inherent algorithms soon in CelestialMatters


The algorithms were developed together with Robert Skuridin, another theoretical physicist from Russia. Dirkpitt's help with big-endian code input (MAC's) and his compilation of the MAC (universal) binaries is gratefully acknowledged! Chris provided some fixes for Windows allowing STDIN/STDOUT redirection for binary files also for Win32.

++++++++++++++++++++++++++++++++++++++++++++

Bye Fridger

This sounds really awesome, I'm looking forward for these tools.

t00fri wrote:6) Monochromatic normalmap tiles are replaced by the smallest 4x4 pixel tiles allowed in DXT format, which saves lots of disk space!

Is it no longer possible to just skip these files? If I remember correctly, a level of a VT does not necessarily have to contain all files. If a certain tile is missing, the image of the next lower-res level is used.
Is this true in general or does this only work on the highest-res level?

steffens