Proposal: Pre-computing shininess in code

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Proposal: Pre-computing shininess in code

Post by chuck_starchaser »

That is, pre-computing shininess using an ad-hoc algorithm, such as the current shader does, but better; and doing it cpu-side, --IF a shininess map is not already supplied or present in the spec-map's alpha channel.


The problem:

1) All the shaders have two shininessMap() functions; one active, one commented out. From my revised shader, out of laziness:

Code: Select all

//float shininessMap(float shininess, vec4 specmap) { return clamp(specmap.a*shininess,1.0,255.0); } // alpha-based shininess modulation
float shininessMap(float shininess, vec4 specmap) // luma-based shininess modulation
{
  float temp = dot( specmap.rgb, specmap.rgb );
  temp *= 0.333;
  return clamp( temp*shininess, 1.0, 255.0 );
}
That first one, commented out, takes shininess from the apha channel of the spec map.
The second one uses an ad-hoc way of coming up with a shininess value based on the specular color (which in OUR shader has been improved).
But the problem is that, although I have a shininess in the alpha channel of my Tarsus' spec map, I cannot use it until ALL the models in PU have the shininess in spec.alpha !!!

2) Using the spec luma -based, ad hoc function sucks.
Well, in YOUR shaders it is based on spec luma alone, and it super-sucks. In OUR (PU's) new shader, it is based partly on luma, partly on chroma, and has a more quadratic linearity, to great benefit. But it still sucks: The assumption that the more specular a material is, the more shininess it has, is simply wrong, and it shows.

I can come up with many counter-examples, but Klauss has proven to be completely stuck on the idea that this is a generally good assumption, and no matter how much evidence I present to disprove it, months go by and I can't make him see the light. And Klauss is one of the most reasonable people I've ever known, so what are my chances?

Well, all I can do is keep trying...

Examples of low specularity but high shininess materials:
a) Glossy paints. Do you have a white fridge nearby? Go take a look at reflections on it. Do it! They are usually pretty faint; and yet, well defined and sharp. Doesn't have to be white paint. Most glossy paints, of any color, show sharp but dim reflections.
b) Glass: Reflects only 6% of light face-on; but whatever light it does reflect, it does so sharply.
c) Shiny plastics, latex suits, leather boots, and other dielectric materials you can see sharp, yet dim reflections on.

Examples of high specularity, but low shininess, materials:
a) Stainless steel. It has no diffuse color at all. Pitch black in diffuse. And it speculates about 70% of the light that hits it. Yet, it would be very hard and expensive to polish, so most stainless kitchen appliances and pans have very low shininess.
b) Cast aluminium: You've got over 90% specularity. Almost white in specular; black in diffuse; and yet the casting process leaves it with the lowest possible shininess.
c) There's gazillions of examples of materials having shininess dispropotionately low, relative to their specularity. Look at your teflon pan: It hardly has a diffuse component at all, --almost purely specular--; and even if it's not too reflective, its shininess is well below what and ad-hoc formula based on specularity would predict.

Heck, I can even come up with one material that occupies both of the categories above, and tramples the ad-hoc assumption two ways:
Metalized paint. (Remember cars back in the 60's?)
Metalized paint presents two layers of specularity: A faint but sharp, fresnel specularity off the outer surface of the glossy base, kind of "alpha blended with" a high specularity but ultra-low shininess reflection off the randomly oriented surfaces of the metal particles in suspension within the glossy base.

But I've given up trying to argue this point with Klauss. His mind will NOT be changed on this subject. In the end, he always says "Yeah, there are exceptions, but generally it's a good formula...", "don't underestimate it...", etceteras.

And yet, I agree with him that an ad-hoc formula needs to be there as a fall-back, because if you can't convince most artists to put a simple ambient occlusion on their textures, despite the obvious benefits, how many of them will one be able to persuade to produce a shininess map, whose benefit is hard to grasp?

But an ad-hoc formula needs to go beyond looking at the specular color. VERY FAR beyond, to be any good at all. Changing the shader from using spec luma to using dot(specmap.rgb,specmap.rgb)*0.33 was a tremendous improvement; and I have tons of ideas for how to improve the ad-hoc formula by yet about another order of magnitude (such as using a front end, ad-hoc formula for separating dielectrics from non-dielectrics by looking at specular AND diffuse color, and then having one ad-hoc shininess formula for each); but the shader isn't the right place to do this: Instruction count is a primary concern, with shaders, first of all. But more importantly, having the shader do it will continue to deny responsible artists like yours truly the right to use alpha based shininess.


The proposed solution:

What I propose is that an ad-hoc formula be used by the CPU, to automatically generate an alpha channel for the specular texture, IF it finds it missing, and save the supplemented texture with a "Created by the VS engine" signature in the header.

I can use Blender nodes to come up with the algorithm; and then I can write the shininess computation part of the code in c++, if someone more familiar with the engine can do the part of checking for the presence of alpha channel, and reading and writing the texture.

Deal?


EDIT:
And, while we're at it, we could also correct texturing snafus, such as diffuse and specular colors for a given texel adding to more than 1.0 in any of the three channels; and write a corrected specular. There seems to be an overabundance of artists out there that don't understand that a material cannot reflect back more light than it receives...
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

does your idea about the channels having to add to <= 1 take into consideration textures that also are emitting light? Like window textures where there is internal light or anything else that may produce a glow ?

Not saying we do anything like that now, but if we're arguing future correctness, would that conflict with your statement?
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

safemode wrote:does your idea about the channels having to add to <= 1 take into consideration textures that also are emitting light? Like window textures where there is internal light or anything else that may produce a glow ?

Not saying we do anything like that now, but if we're arguing future correctness, would that conflict with your statement?
It would not conflict at all. Well, yes and no; let me elaborate...
Actually, yes, it would conflict, totally.
Step by step:

If a surface emits light, then there's no question that it can shoot back more light than it receives, from an accountant's perspective.

On the other hand, how many light emitters do also reflect light?

Say you have a light in a housing, with a glass cover. To the extent the cover is transparent, to let light out, it also lets light in. Whatever light is let in, is not reflected back... *necessarily*. But then again, in a car's headlight, the interior of the housing is reflective, and the light that gets in, most of it gets back out again. Though, this is not a good example of a material behavior, but rather of a whole assembly...

BUT, speaking more from my artistic side, now, bright emitters that have non-black color in diffuse look like crap. And non-black specular color looks like crap on them too, though it might look not so crappy if we had fresnel, so that only shallow angles would show much reflection; but then again, and this gives me an idea... Once I implement the new shaders with fresnel, I'll make sure to modulate emissive light by 1-fresnel reflection (or "fresnel transparency").

Back to the technical side of my brain, the biggest problem with having emissive materials that also reflect light (diffusely or specularly) is that you can get saturation; and saturation looks like a dynamic artifact. Same as when you see a ship where both the diffuse AND specular are too bright and some areas go to full white. If you have a red light on a ship, and red is at 1.0, and its specular color is 0.7, and then a light passes through the right angle and has an intensity of 1, then you should get a final color of 1.7, 0.7, 0.7 (I'm simplifying, of course); but the monitor can't represent 1.7 red.

Or we could try and solve the problem by only allowing a red light to reflect green and blue, but not red. But that would lool pretty weird...

The simplest and best-looking solution is to put diffuse AND specular at black, for lights that have either red, green or blue (or any combination thereof) emissive color of 1.0; and I guess we could enforce that, first; followed by the diffuse+specular check.

Good point!


EDIT:
By the way, a question arises: do we do these checks and corrections for all texture sets?, or only when we find a missing shininess? I suggest the latter: First for simplicity in the coding; but secondly because we could be statistically right in assuming that a texturer who bothered to provide a shininess map is someone with enough brains to use realistic materials.

EDIT2:
And then we'll have LaGrande, which will generate optics-consistent texture sets.

EDIT3:
Yeah, max(glow.r,g,b)+max(spec.r,g,b)+max(diffuse.r,g,b) should never be > 1, for any texel.
And if you think this will turn a lot of textures darker, you're definitely right, and that's as it should be. Probably light will have to be cranked up in the shaders, but that can be done easily in the vertex shader.

But before you ask "what's the net difference, then?", the net difference is that if the lights are kept low enough to allow a material to be white in both specular and diffuse, yet NOT saturate, then you have no way of representing a perfect mirror material (black in diffuse, white in specular), or a perfectly matte white material (white in diffuse, black in specular), because in order for them not to saturate in the 1,1 case, they'll have to each represent 50% grey and 50% mirror at the maximum value of 1. BIG net difference... We NEED the occasional mirrors and the occasional matte white materials. They should not be sacrificed for the sake of catering to bad texturings.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Hell, there's actually a lot more arguments for enforcing the diffuse+specular<1 rule.
Dimming the lighting to allow for white diffuse & white specular materials not to saturate is not only a sacrifice of mirror and white matte materials for the sake of catering to bad texturing in only a rigorous optical sense. It is also a sacrifice for NOTHING from the point of view of materials. There is NO material that is 50% gray diffuse/50% gray specular, in the first place.

EDIT: Well, at least pretty rare; maybe zinc or led?, I'm not sure.

Most materials are either almost purely diffuse or almost purely specular. The former are kind of rare. Mostly just human-made matte paints. The wings of butterflies and flower petals can be very matte also, but not too many more things. Even rocks and bricks are more specular than diffuse; just with a pretty low shininess. I was watching a brick wall across the street from the window of a restaurant around the corner from where I live, the other night. Hell, as cars were coming in from the next block, I could see patterns of light on that brick wall, but it wasn't direct light returned diffusely; it was more like a very large ellipse centered on the reflection point.

Human skin is like 50% subsurface scattering, which is not exactly like diffuse; and the other 50% is split between specular reflection with fresnel and low shininess, and the rest absorbed. There's no diffuse color there almost at all.

It's like 90% of the materials we care about in a space sim are almost purely specular, and what distinguishes them, besides specular color, is really the shininess.

But yeah, to get back to my point, there's no such thing as a 50% diffuse, 50% specular material, so a texturer that puts white or light gray in some spot in both diffuse and specular is not only ignorant about optics, but doesn't even know what material he wants.
Last edited by chuck_starchaser on Fri Apr 04, 2008 7:44 pm, edited 1 time in total.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

And then to get back to the original topic, I'll start building a Blender noodle tonight, to experiment with dielectric detection and shininess generation. Basically, I'm thinking, any material that has chroma in diffuse, but is gray-scale (desaturated) in specular, is a dielectric. This would fail to recognize grey paints, tho... But maybe not: Metals are at least 4 times as specular as diffuse; something with more diffuse than spec/4 could be tagged as a grey paint, and thrown into the dielectrics bin. And any transparent material with non-zero specular is a dielectric also. Dielectrics would get a much higher shininess than metals, all other things being equal. Transparent dielectrics would be maxed out in shininess. I'm also thinking that red and green should have a much greater weight than blue in the computation of shininess for non-dielectrics. Like yellow specular is gold, 24 karat, and very shiny, never mind it doesn't reflect in blue. Transparent materials with zero specularity would be interpreted as alpha testing holes. But the most important part to get exactly right is the low end of the shininess range. That's where most materials fall, and where we need some really snazzy way to identify and characterize what we got...

EDIT:
And, come to think of it, once the engine is able to come up with a semi-acceptable shininess map, maybe there will be more artists willing to take a look at the generated shininess and adjust it to better fit the materials they had in mind. Admittedly, thinking about what the shininess of each material should be is not easy, and I often have to adjust my initial guesses. Having the engine generate a first crack at it would probably be the method I would adopt for generating the shininess map, myself.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Proposal: Pre-computing shininess in code

Post by klauss »

chuck_starchaser wrote:I can come up with many counter-examples, but Klauss has proven to be completely stuck on the idea that this is a generally good assumption, and no matter how much evidence I present to disprove it, months go by and I can't make him see the light. And Klauss is one of the most reasonable people I've ever known, so what are my chances?
You seem to misunderstand my point of that time when we talked about it. Adding the alpha channel uses up memory and bandwidth. My point was that when it was enough, it would be good to leave it implicit and let the shader compute it to avoid that extra memory and bandwidth usage. I was talking from an ideallistic POV.
But, as you said, VS has only one shader. You need all models using the same function. So... to your dismay, either all models use the implicit one, or you start drawing alpha/shininess channels to all specmaps ingame.
I may be able to draw one or two specmaps, but doing them all is beyond my available time, so I decided to go for the implicit one (which requires no such time expenditure). But I'm 100% in agreement that using an alpha channel to convey shininess is a far superior method.

BTW: I won't try again, I'm just reminding you. Diffuse + specular >= 1 is both possible and physically correct. Pixel values are light densities, and scattering can create higher concentrations in some places by depleting others. But try it your way if you want, and let's see how it works out.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Proposal: Pre-computing shininess in code

Post by chuck_starchaser »

klauss wrote:
chuck_starchaser wrote:I can come up with many counter-examples, but Klauss has proven to be completely stuck on the idea that this is a generally good assumption, and no matter how much evidence I present to disprove it, months go by and I can't make him see the light. And Klauss is one of the most reasonable people I've ever known, so what are my chances?
You seem to misunderstand my point of that time when we talked about it. Adding the alpha channel uses up memory and bandwidth. My point was that when it was enough, it would be good to leave it implicit and let the shader compute it to avoid that extra memory and bandwidth usage. I was talking from an ideallistic POV.
Well, I'm idealistic too, and my ideal is to see good graphics, and I set my videocard to max quality settings, even if I have to sacrifice some FPS. And the same applies here: I'm all for optimizing bandwidth; but my weighing of quality versus speed seems to be different from yours. I don't care if I have to suffer a 5% loss of FPS if that was the price for seeing stainless steel that looks like stainless steel, and not latex. And if you and the other VS devs care so much for speed that they won't let me have stainless steel that looks like stainless steel, then PU will have to FORK the damned engine. Hope I make my point strongly enough without sounding like I'm flaming.
But, as you said, VS has only one shader. You need all models using the same function. So... to your dismay, either all models use the implicit one, or you start drawing alpha/shininess channels to all specmaps ingame.
Well, I wasn't suggesting that we go to a two-shader system just for this. We WILL have to go to a two-shader system transitionally when we move to the new texture packing, and that's enough of a headache, I reckon. What my suggestion was and is, as the title of the thread suggests, is to do the shininess computation in code, and that we save it to the alpha channel of the texture. There's many benefits in doing this. First, we can do a better job than in the shader. Secondly, the generated shininess can then be used by the artists as a starting poing in producing the real McCoy.
I may be able to draw one or two specmaps, but doing them all is beyond my available time, so I decided to go for the implicit one (which requires no such time expenditure). But I'm 100% in agreement that using an alpha channel to convey shininess is a far superior method.
Well, I hate to say this, but that was a poor decision, Klauss. A very poor decision. By doing that you basically locked the engine; you "married" it to computing shininess from spec color. Nobody will produce a single shininess map if they know that they won't be used unless ALL models are given shininess maps. It's a deadlock, now. And I'm trying to come up with a plan by which we can break out of this vicious loop. Had you asked me at the time, I could have told you that the way to go was to have the code generate the alpha channels, but you didn't ask me for an opinion.
BTW: I won't try again, I'm just reminding you. Diffuse + specular >= 1 is both possible and physically correct. Pixel values are light densities, and scattering can create higher concentrations in some places by depleting others. But try it your way if you want, and let's see how it works out.
You're reminding me of something you said which was, is, and forever will be, WRONG. If you use a 255 diffuse value to represent 100% matte white, and a 255 spec pixel value to represent a perfect mirror, there is NO MATERIAL that has a color wher diffuse + specular > 255. PERIOD. What you CAN have is ***LIGHT*** of any magnitude, far exceeding the expected range of representation. But when we're talking about diffuse and specular TEXTURES, we're talking about material characteristics.

EDIT:
Sorry if I sound angry, Klauss, but I am. Partly I'm depressed over other things, partly I'm piss drunk, partly your saying "So... to your dismay, either all models use the implicit one, or you start drawing alpha/shininess channels to all specmaps ingame" as if this was an immovable condition I must learn to accept. I do NOT accept that. I need shininess from alpha, AND I also need computed shininess for models while they wait for their real shininess in alpha. And I didn't come here just to complain and cry about it; I came here with a solution I put on the table.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Sorry for the "to your dismay". It should have been "to our dismay", for the intended meaning was: if we want alpha-based shininess, we have to get alpha-packed specmaps. And that's quite a task.

Now... building them with a script as you suggest doesn't sound that bad, I must accept. But I'd make it a script, please, pretty please. Don't further convolute the engine with this kind of stuff. You know the mess which autogeneration of spheremaps ended bringing up.

EDIT: I must admit after your explanation the thing about diffuse+spec kind of makes a bit more sense. I know where you get the idea from, now, at least. I still believe there's something wrong. First because I've seen papers that make total sense and accept the possibility of an BRDF (bidirectional radiance distribution function) taking values >1 (an BRDF contains both diffuse and specular - in fact, the division among diffuse and specular is a way of compressing the BRDF into a few values, as BRDF are really complicated functions - one cool thing to have is a true BRDF shader, that takes a BRDF texture instead of diffuse/specular colors, you should try it). But not only that. There's white glossy paint, you know. White shiny cars. White shiny plastic. But you do have a point. I'm certain there's a catch somewhere, one catch that gives you and me both some credit. I can readily think of a situation where white spec + diff would be madness, so there IS a catch. Probably in the way specularity happens. Hm...
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Ah, for sure!, I don't care whether it's part of the engine or something that runs off line separately. I just thought the engine would be better in the sense of people not having to remember to run a separate program; but if putting it in the engine is problematic, I have no major issue with it being separate.
I'm still going to need a bit of help, though; in that I've no idea how to read or write DDS. And I've no idea how to write code to traverse a folder system recursively. What I CAN write is the algorithm part.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Don't read DDSs, I'd suggest the changes would have to be made on the masters, probably a python script would suffice. Then someone converts the masters to DDS (again - what a painful task), and tada!
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

klauss wrote:Don't read DDSs, I'd suggest the changes would have to be made on the masters, probably a python script would suffice.
Then someone converts the masters to DDS (again - what a painful task), and tada!
That won't happen unless we also write a script to do the dds from masters thing. IOW, it won't happen.

The first and most urgently needed thing is something that reads and writes dds, so that data4.x can be changed at once, so that the shader's comments can be switched.
However, a masters-side semi-solution is going to come first, in the form of a Blender noodle. Of course, that won't be batch-mode.

I can't write Python; I can give you C++. Actually for reading/writing PNG's I do have code already, which I used in the texturizer. Maybe I can write a command line thing, and you can write a script that calls it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

The most difficult part of all this is data. NO data. I've searched so much for material color tables I almost broke Google....
I found spectra for a couple of metals. The rest was posts by modellers and artists expressing their *opinions* of what's the best color for this or that. But hard data in terms of diffuse and specular, --let alone shininess-- is like forget it... It don't exist. Which is understandable, since "diffuse" and "specular" are just simplified models. Concepts that belong in computer graphics more than in material science. But still, enough people should need data to fit these models for someone out there to have set up some lights, a camera, and colored reference materials, and made measurments... but nope.

Well, at least I know exactly what the shininess, specular and diffuse are for stainless; as I think the material on the engines of the Tarsus looks exactly like stainless.
http://deeplayer.com/pu/temp/newshader.jpg
Ehm, except for the excessive dithering in shininess, which would be more typical of aluminium.
Last edited by chuck_starchaser on Fri Apr 04, 2008 11:56 pm, edited 1 time in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Search for BRDFs instead, maybe you'll find more (and more authoritative). You'll have to convert the BRDF into diffuse and specular, though. That could be yacky.

EDIT: yep and more

BTW: cmdline is fine. A bash script can always handle the rest. In fact, a bash script should be able to handle converting the masters back into dds form (given a compressor), for input into data4.x
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Nice link, but still, no data; and now I've added another 3 or 4 hours to this fruitless search. I find it so hard to believe that with so many billions of gpu's sold that use the diffuse + phong model, there wouldn't by now be libraries or diffuse rgb, spec rgb and shininess fitted BRDS data for all materials known to man, and some yet to be. How is this information famine even possible?

Heck, I googled for "BRDF materials library" and I find links to university sites that just talk about how marvelous their damn libraries are, but the libraries are never on line.

I'd be willing to pay for a good materials library, but there seems to be nothing commercially available either... :(
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

My dielectric detection noodle has failed to find any dielectrics in the Tarsus...

Image

...which is as it should be; --haven't got any.
In fact, the only non-black areas are background, where there are no UV islands.
The reason it's detecting possibly dielectric stuff there is that the backgrounds are filled with arbitrary color, prior
to padding around islands using blurs; so there's color there.
By the way, the formula here is,

Code: Select all

1-(specularsaturation+0.01)/(diffusesaturation+0.01)
This is only part of dielectric detection. The other parts will be:
a) metal detection, which is kind of working already, will be a vote against a texel representing a dielectric
b) detection based on transparency, which will probably be overriding.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Alright! Progress!

No shininess production yet, but the most difficult part is done: Dielectric Detection.
Here's the diffuse texture of the Tarsus:

Image

and the specular:

Image

And here's dielectric detection at work:

Image

All that's being detected so far is the windows and the lights. There's a simple reason for that: I did not intend to have any other
dielectrics on it. Well, not for this temporary, rough texturing, anyways.
But I'm going to put a bit of dielectric material on it, just for testing:
Just selecting a rectangle on a gray material in the diffuse texture, and injecting uncorrelated noise.
Uncorrelated noise means that red, green and blue are scattered independently of one another.
That causes many of the texels in that rectangle to acquire chroma...

Image

But when the diffuse texture has chroma, and the specular doesn't, the dielectric detection part of the noodle says,
"Aha! That's a dielectric!":

Image

The gray areas are just background.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

First shininess coming out...

For comparison, I made two shininess maps: First the original shininess from spec luma in the old.. er.. current vs shaders:

Image

This is what the my shader computes, using dot(spec,spec):

Image

And this is the first shininess born of the Blender noodle in progress:

Image

Haven't tested it in-game yet; stay tuned...
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

The noodle is starting to yield promising results. Look at the window
in thest two pics:

Image

Image

Hahaha, no; I'm not claiming to have invented Phong shading... What I AM boasting about is the fact that my
noodle identified the window as a dielectric and gave it top shininess, without any manual input. In fact, it's also forcing its specularity to a minimum of .25 rgb; tho I'm not sure about the wisdom of this.

To give higher shininess to bronze than to stainless, I had to not only average the squares of spec red and green, ignoring blue, but I even had to subtract a bit of blue-squared. Doesn't follow any science or logic, but then again, none of this does; that's why this algorithm is "ad-hoc". It's only supposed to be a lot "righter" a lot more often than the current shader; but it's still an "interpretation" of the artist's intentions.

Now the error is still on the side of too much shininess overall. It seems
I'll have to cube the spec channels...

EDIT:
Klauss, remember we were once talking about the fact that phong shading changes spot sizes but not their brightness? You said you implemented appropriate dimming --as spot-sizes grow in size--, in your shaders. What would be the right formula to use for that?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

I can't give you an exact formula, I tried with Maple and it doesn't produce a closed formula (and I stopped trying to symbollically integrate by hand what Maple fails to a long time ago).

But I can give you an approximate:

specular = 1.0 / ( 1.0 + 1.0/(pow(shininess,1.5)) )

I didn't apply it to any shaders. I doubt I said that... maybe what I said is that the luma-based function for computing shininess achieves some of that and that may be why it looks so much better than nothing at all or even manual input at times.

Anyway... that approximation function I wrote isn't that complicated, it might be put into a shader :D
(I never tried to approximate it, interesting idea you gave me)

BTW: If you check that function, it only makes a difference for shininess 1-5, any higher and the normalization factor is too close to 1 to make any noticeable difference.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

THANK YOU! :D :D :D

I'm going to implement it in the shader right now.

EDIT:
If you're going to implement it in your shaders in parallel, I call to your attention, --just in case you didnt happen
to think about it--, that this dimming should apply to specular light spots; but NOT to env mapping.
Last edited by chuck_starchaser on Sun Apr 06, 2008 4:15 pm, edited 1 time in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

BEWARE: I just tested it for higher shininess values and it fails miserably to accurately approximate the real value.
Let me try to get a better approximation.

Ok, here it comes:

specular = 1.0 / (1.7/(1+shininess/10))^1.7;

It's less accurate on lower shininess levels, but far better overall. It's more complex though (the ^1.7)
Last edited by klauss on Sun Apr 06, 2008 4:34 pm, edited 1 time in total.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Try to use my modified shader for testing. The original function for shininess gives shininesses way too high, so you wouldn't be able to see much of the --more important to get right-- low shininess end of the spectrum.

EDIT2:
Also because of the bug I fixed with multiplication by envLight, the consistency of using the same color for specular and diffuse light, and the multiplication by two of env mapping contribution to compensate for the engine's dimming of the spheremaps. In other words, don't test your formula with a ***broken*** shader...
Except ONLY for the self-shadow thing; --haven't reverted it yet.

EDIT:
And I'd recommend you test with PU and the Tarsus, where there's pretty good material characterizations via diffuse and specular.
If you do so, you need to teleport yourself away from Troy, as Troy is lacking a background, so you get no env mapping there.
A fairly good place is Gemini/Tingerhoff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

klauss wrote:BTW: If you check that function, it only makes a difference for shininess 1-5, any higher and the normalization factor is too close to 1 to make any noticeable difference.
I missed this.
Yeah, and that sounds pretty right to me; not the numbers necessarily, but there just wouldn't be a point in
keeping on cranking up the brightness of spots as shininess goes up, without HDR, anyways.
I'd prefer it to work right in more of a 1-20 or 1-30 range than just 1-5, tho. I'll figure something.

EDIT:
HECK! Shininess itself needs to be limited for light spots!!! Stars are not point light sources!
Higher shininesses than some 20 or 30 should ONLY apply to env mapping.
Last edited by chuck_starchaser on Sun Apr 06, 2008 4:39 pm, edited 1 time in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Take a peek at the previous post, I've added the right formula ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

I have a feeling that he will be using a test mission that he created and committed to the VS trunk yesterday :wink:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
Post Reply