Testing Chris' new, compressed normalmaps (part 2)

[t00fri]

Chris,

while driving into my lab, I was thinking what would happen to the 'plastic' shine, if I'd fill the land areas in the specmap with some Gaussian noise ranginging between 0x00 and 0x40, say?

Bye Fridger

[ElChristou]

The plastic effect comes from the pure white of the spec highlight (good for water, not for land)...

[t00fri]

The plastic effect comes from the pure white of
the spec highlight (good for water, not for land)...

Christophe,

That's too easy an explanation in this case .

The point is rather that the power function in the Phong specular
lighting model will reveal fine details in a normal map that often don't
appear with /diffuse/ lighting. The Phong specular lighting is intended
to approximate how light reflects from a /smooth/ surface.

We know that all this depends strongly on the reflectivity model we
put into the spec map. As soon as land is /black/ in the spec map, as
usual, -> no 'plastic' whatsoever.

I allowed for just a bit of /homogeneous/ reflectivity (0x40 (hex) = 64
(dec)) which gives that great detail enhancement I illustrated above.
The 0x40 is so weak that visually, the reflectivity on land is hardly
perceivable.

NOW...

If I use dark noise (with pixels ranging between 0x00 (black)
and 0x40 dark gray)



instead of my uniform 0x40, previously, the reflectivity model will not
be /homogeneous/ anymore, like polished marble. The dark noise
should be more like diffuse reflectivity. I want to see how the resulting
properties can be tuned with this sort of game.

It's very easy to try. I certainly will, tonight.

Bye Fridger

[cartrite]

Fridger wrote:

The Mars image above is not how my mars texture looks like. It's just a drastic example to illustrate the 'plastic' look

I understood that. What I was suggesting was that mabey 0x40 is still too light for Mars. I was using 0x2e. I also just tried noise between 0x2e and 0x00. But I didn't see much difference between that and with all 0x2e's. Mabey you'll have better luck.

With all 0x2e's the plastic look is slight with some textures of Mars, and not there at all with others. Yet there are still some specular highlights.

cartrite

[t00fri]

...
I understood that. What I was suggesting was that mabey 0x40 is still too light for Mars.

In the Mars image above the spec illumination was MUCH higher than any of the values we are talking about now. 0x40 I took for my Andes shots to demonstrate the quality of my DXT5nm compressed 64k normal map.

I was using 0x2e. I also just tried noise between 0x2e and 0x00. But I didn't see much difference between that and with all 0x2e's. Mabey you'll have better luck.

With all 0x2e's the plastic look is slight with some textures of Mars, and not there at all with others. Yet there are still some specular highlights.

cartrite

Well 0x2e might be somewhat better i.e. less "plastified", although I found that the spec enhancement of the normal map was way superior with values around 0x40. That was the main purpose of my exercise.

While my noise idea had some interesting effects, unfortunately, they were not what I had hoped for.

So forget about the noise.

Bye Fridger

[ElChristou]

The plastic effect comes from the pure white of
the spec highlight (good for water, not for land)...

Christophe,

That's too easy an explanation in this case .

...

Indeed...
I was thinking in a double spec definition, one for water another for land but I suppose this is not so trivial...

[chris]

Phong specular lighting is simply not a realistic model of how Earth's land areas reflect light. While some specular lighting may be useful for visualizing surface relief, it's not the path to photorealism. That said, here are a some guidelines for setting specular lighting parameters:

- The larger the value of SpecularPower, the smoother the surface will appear
- Setting a white specular color will tend to give materials a plastic appearance
- When the specular color is the same as the diffuse color, the material will appear metallic. This is due to a difference in how light interacts with conductive vs. dielectric materials.

I don't happen to know what photometric model is best for the Earth's surface. With so much variety in surface types, I doubt any single function would be suitable everywhere. Certainly the glaciers of Antartica reflect light much differently than the Bolivian altiplano--it's more than a matter of one being white and the other brown. For some regions of the Earth, the Lunar-Lambert model could be appropriate. Unfortunately, it doesn't currently work with specular lighting. If some one can refer me to some papers on the photometry of Earth's land areas, I'd consider adding some new photometric models to Celestia.

--Chris

[t00fri]

Chris,

my understanding of Phongs specular highlight model is about like this:

with diffuse reflection being

Code: Select all

diffuse = Kd * (N dot L)

with Kd=Lambertian relectance coefficient.


Phongs ansatz is this

Code: Select all

diffuse + Ks * (R dot V)^n


with

Code: Select all

  N   = surface normal
  L     = unit vector between point and light
  V   = unit vector between point and view
  R     = light reflection unit vector (mirror of L about N)


So what values of the various surface parameters did you hardcode?

I am aware that there are quite a number of simplifications that avoid the above expensive calculations. Anyway, what ansatz did you take and which parameter values? Also there are other names going along, like Voltaire and Gouraud. As a physicist I know Gouraud shading, of course.

Bye Fridger

[Kolano]

Could non-grayscale specular maps be used to choose an appropriate lighting model? (i.e. red shades=phong, green shades=lunar lambert, and blue/alpha= some other lighting model)?

[chris]

Chris,

my understanding of Phongs specular highlight model is about like this:

with diffuse reflection being

Code: Select all

diffuse = Kd * (N dot L)

with Kd=Lambertian relectance coefficient.


Phongs ansatz is this

Code: Select all

diffuse + Ks * (R dot V)^n


with

Code: Select all

  N   = surface normal
  L     = unit vector between point and light
  V   = unit vector between point and view
  R     = light reflection unit vector (mirror of L about N)


So what values of the various surface parameters did you hardcode?

I am aware that there are quite a number of simplifications that avoid the above expensive calculations. Anyway, what ansatz did you take and which parameter values?

None of parameters in the Phong calculation are hardcoded. The only simplification used is Blinn approximation where the actual light reflection vector is replaced with the half vector (halfway between the light and view vectors.) I may switch to using the real reflection vector in the OpenGL 2.0 path, but it won't affect the appearance much. The Phong calculations aren't really that expensive; your graphics chip is performing them at every single pixel The power function only requires two clocks from one of the four 450MHz pixel pipes on your 5900; the dot products execute in a single clock.

The basic problem is that many surfaces reflect light in ways that can't be modeled with any choice of Phong parameters. In fact, the Phong model is an approximation that isn't physically realizable by any surface, since it violates both the normalization and reciprocity contraints of real-world bidirectional reflectance distribution functions (BRDFs)

The Lunar-Lambert photometric model that I introduced recently makes the Moon and other regolith covered bodies look much more realistic. I'm not sure yet what should be done for Earth. It's something I intend to look into in the future.

Also there are other names going along, like Voltaire and Gouraud. As a physicist I know Gouraud shading, of course.

Gouraud shading doesn't refer to any particular lighting model. It's just the procedure of linearly interpolating the color results of lighting calculations at vertices across the pixels of a triangle.

--Chris

[danielj]

?

[chris]

[quote="danielj"]?

[selden]

This thread has been split into separate parts.

It started with the posting
Testing Chris' new, compressed normalmaps, which see.

Unfortunately, this version of the phpbb Forum software does not include a command to merge threads.


At this point the original discussion got sidetracked into a discussion of command line utilities which got quite confused. That part of the thread had to be moved elsewhere and has been locked.

[chris]

Reposting a message that I sent to the dev list . . .

I just checked what are hopefully the last changes for DXT5NM textures in 1.5.0.

As of this checkin, DXT5 normal maps are not automatically treated specially--they must be stored in files with the extension dxt5nm so that Celestia knows to add the extra bit of shader code to remap the color channels and generate the z component of the normal. It's just a matter of renaming the files from whatever.dds to whatever.dxt5nm. Virtual textures still retain the .ctx extension; you should set the TileType to "dxt5nm" for dxt5nm textures. The reason for this is so that DXT compressed normal maps will still work even if the color channels aren't set up like a DXT5nm texture (so, all the normal maps on the Motherlode will once again work with 1.5.0.)

DXT5nm textures will now work for meshes as well as spheres. Finally, I added a check so that render paths other than OGL 2.0 will ignore normal maps that are in dxt5nm format.

--Chris

[rra]

so, all the normal maps on the Motherlode will once again work with 1.5.0.)

Chris , great to hear that compatibility with the old normal maps is
going to work again. Now I have to find a build of 22 oct or later ....


Ren?©

[rra]

even greater: thanks to Phoenix I can now actually
try it , Phoenix build was dated 23 oct. (today !!) .

Thanks all ,



Ren?©

[t00fri]

so, all the normal maps on the Motherlode will once again work with 1.5.0.)

Chris , great to hear that compatibility with the old normal maps is
going to work again. Now I have to find a build of 22 oct or later ....


Ren?©

But the resulting shading is massively incorrect for all non-equatorial latitudes, as I have emphasized several times...

Bye Fridger

[rra]

Thats true Fridger,
I guess thats the reason why the new normal maps
were created in the first place ?? ,
but for the mean time I can live with the old "bugs" .

What (windows) tooling is available the create the new normap maps ??


Ren?©

[t00fri]

Thats true Fridger,
I guess thats the reason why the new normal maps
were created in the first place ?? ,
but for the mean time I can live with the old "bugs" .

What (windows) tooling is available the create the new normap maps ?


Ren?©

Only our nmtools (executables for Win32, Mac PPC & Intel, Linux + sources, of course). Unfortunately, I still have not managed to finish the tutorial and thus the publication is still pending.

As to normal map tiles, there are in addition various crucial optimizations, like the decrease of tile resolution in polar regions to avoid the simultanous and unnecessary loading of MANY tiles which destabilizes the system (memory!). Also all ocean tiles are replaced by tiny 4x4 pixel ones, which saves lots of storage.
Finally, the code is optimized to do (>= 64k ) monster normal maps just with normal sized home computers VERY fast...

Bye Fridger

[t00fri]

EDIT: .ogg ==> .avi (for Windows fans )
14MB ==> 10.9 MB

Here is an .avi movie I made of Mars (mons Olympus neighborhood) to demonstrate the "entertaining" plastic nature of Mars' surface with the new normalmap scheme.

The movie to me has an attractive artistic component in view of the shiny surface and the changing illumination.

So NO critics please that all this is NOT photorealistic

Enjoy the 11 MB,

http://www.shatters.net/~t00fri/images/mars.avi

Bye Fridger