This one is completely different, it's a medley of the BB car shader and wood2table and a little "trifouillage" for realism, i post it when ready !

Je l'attends avec impatience... :-) hope I got that right. I can see BagginsBill's got another convert! Vive la correction de gamma!

look good.

plus add some AO on the ground. it will make it better.

The Metalic node is not really ready but you can use it ( by connecting it to the Paint_color node ) or set up it if you want !

If you have a map, you can place it on the Value 1 of the Color_Pow_3 node.

Dont forget to rename this file .txt -> .mt5 before placing it in your material folder .

Thank you for that, Anthanasius. I have a BMW that needs a bit of a clean up...

Not to be a pain but does this shader include GC?

Let me verifying !

I think yes, cause if i add GC to the shader it's overexposed with an ibl 50 % and an infinite at 50 % , i need to put both lights to 20 % at this time all the other GC materials are underexposed ...

But may be i'm in the error !

Is there a specific reason you set IBL at 50%? I'm in learn mode...

As to things being over-exposed when you add GC: yes, they will be after you've gamma-corrected your materials. That's because we tried to compensate for Poser's GC shortcomings by setting lights way too high. I've done an exercise on GC which I documented on my blog:
tightbytes.com/wordpress/
The difference is quite compelling.

I've set my ibl at 50 % cause my ibl map was created with the gen ibl but in gc ...

Quote - As to things being over-exposed when you add GC: yes, they will be after you've gamma-corrected your materials. That's because we tried to compensate for Poser's GC shortcomings by setting lights way too high. I've done an exercise on GC which I documented on my blog:
tightbytes.com/wordpress/
The difference is quite compelling.

I know all that :-) only the car shader is surexposed if i add gc to the actual shader not the tyre or the glass

You raise an interesting question, Anthanasius... gamma correction, as I understood it, applies to images (like ImageMap type images) only, right? You wouldn't gamma-correct a pure node-only shader, would you?
See, I'm still in the dark on a lot of this, hun... you know heaps more than I do, a mon avis!

Quote - You raise an interesting question, Anthanasius... gamma correction, as I understood it, applies to images (like ImageMap type images) only, right? You wouldn't gamma-correct a pure node-only shader, would you?

That's an interesting question I never considered. I wonder what the answer is too.

Paging Mr BagginsBill?

No no no, i use GC for all ( now xD )  ...  How to explain that ???????????

I am curious about that as well. My understanding is that gamma correction needs to be applied to images because they conform to sRGB standards and need to be converted to linear colour space (anti-gamma'ed) before maths can be done to them. Since node-based colours and materials are created in Poser, does the same apply to them?

Anti-gamma is applied to images, color parameters - any incoming material that "looks" like the color you want. The numerical value of these is not linear - it is sRGB and does not represent the true numerical ratios of luminance of R, G, and B.

Then all the shading should be done.

Then the final summed color must be gamma corrected. Doesn't matter how you got that color or whether you used images or not.

I didn't have time to look at the shader, but if it is overexposed by changing the lights, you may have done something wrong. Is Reflect_Lite_Mult turned on? Because it should not be. Is Reflect_Kd_Mult turned on? Because it should not be.

If all your shaders are GC, then the value coming in through a Reflect node is not linear - it is sRGB. Which means the reflect node has to be treated like incoming material. It has to be anti-gamma corrected.

Anti-gamma correction is x ** 2.2

Gamma correction is x ** (1 / 2.2)

Quote - Anti-gamma is applied to images, color parameters - any incoming material that "looks" like the color you want. The numerical value of these is not linear - it is sRGB and does not represent the true numerical ratios of luminance of R, G, and B.

Including colours you create with nodes? Sorry to keep pressing the point, but this is still a burning question... say I make the following node:

baseTone = IColor(244, 244, 255)
setComplexion = Spots(
    Base_Color = baseTone,
    Spot_Color = ltBeige * baseTone,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Complexion")

would this still need to be run through GC?

BTW, this isn't really anything I'm using... just an example... it's bogus, really...

Quote - I've set my ibl at 50 % cause my ibl map was created with the gen ibl but in gc ...

When you've made your IBL with the IBL generator isn't your new IBL's light intensity supposed to be 100-200%?

Quote - > Quote - Anti-gamma is applied to images, color parameters - any incoming material that "looks" like the color you want. The numerical value of these is not linear - it is sRGB and does not represent the true numerical ratios of luminance of R, G, and B.

Including colours you create with nodes? Sorry to keep pressing the point, but this is still a burning question... say I make the following node:

baseTone = IColor(244, 244, 255)
setComplexion = Spots(
    Base_Color = baseTone,
    Spot_Color = ltBeige * baseTone,
    Spot_Size = .1,
    Softness = .35,
    Threshold = .7,
    Noise_Type = 2).labelled("Complexion")

would this still need to be run through GC?

BTW, this isn't really anything I'm using... just an example... it's bogus, really...

If the way you arrived at the RGB value was you picked it from a color picker, then yes, it needs to be anti-GC'd.

However, I happen to know this excerpt from your shader and these are not colors we picked based on how they look. They are tints which you use to multiply with the incoming colors, which is a very different thing. We're not looking at these colors, we're using them as ratios. You do not need to gamma correct or anti-correct ratios.

Quote - > Quote - I've set my ibl at 50 % cause my ibl map was created with the gen ibl but in gc ...

When you've made your IBL with the IBL generator isn't your new IBL's light intensity supposed to be 100-200%?

If you use Gen-IBL to make it, it will hold the exact amount of RGB that it got from sampling your environment. Which means if you want to match the environment, you should be using 100%. If you were using the trick I showed where you scale the incoming data by half, in order to compress it to fit more dynamic range into the LDR image, then you use 200% to match. (Twice a half is the original amount, but more fits in 8 bits.)

However, for artistic reasons, where you're just using an IBL as a controllable light distribution, it is perfectly valid to use any intensity you want to get the effect you want.

Only when precisely matching a sampled world do you have to use it at a specific intensity.

Of course, if you're having sloppy issues with shaders, particularly if they are not all perfectly balanced, you may feel the need to hack your lights.

With poser pro and Gamma Correction on, for a colour coming from the colour picker you would have to anti-correct the colour. Will poser then correct the colour or does that only apply to texture maps?

Quote - With poser pro and Gamma Correction on, for a colour coming from the colour picker you would have to anti-correct the colour. Will poser then correct the colour or does that only apply to texture maps?

Poser Pro anti-corrects any color you enter in the material room. It still reads back as the RGB you selected, but the actual value used is the linear representation. You don't have to do anything with it.