Maya 8.5 Sun/Sky Rendering Bad

#21

Final render stage-2 has a sp1 now and works for maya 8, I would love to test that… the one for maya 7 renders great.

#22

dont use DGS, but the new mia_material with the physical sun/sky
i think this could help you…

#23

ive been playing with the tone mapper too, it seems that lowering the pedistal into a negatve range helps a lot with the contrast. somewhere around -0.5 began to give me good results. hope that helps…

#24

Thank you for all the input, this has turned out to be a good thread. I tryed both of that before, setting the pedistal to negatives, and using all the mia_materials…now the mia_materials do help some… but after hours and hours of testing and tweeking i have to come to the conclusion that mr lighting and rendering in 8.5 with or without sun/sky is no better than it was before… and really isn’t worth the time of all this tweeking and material changes when other renders you can just load the scenes and objects and get an amazing render right off of default.

#25

I too find Mental Rays exposure controls desaturate materials way too much.
I’ve played with the mi_exposure and Max’s logarithmic exposurer in 3dsmax 9.
Both of them create desaturated images. You have to darken the colour and add
saturation to get the correct colour using the Arch&Design.
Makes it pretty tough when your matching colours from colour swatches/palettes.
You have to tweak the Colour swatch so it looks nothing like the original colour.
Lots of test rendering, quite painfully slow.
Since you have to darken the colour so much the final gather no longer bounces
light correctly ( well I think so ). It would be good to have another tone mapper,
maybe the Reinhard tone mapper would work better.
How else is everyone else getting the correct colour of the colour swatch ?

cheers

#26

I know exactly what you mean FuriousD, I know others that say the same thing, I don’t think their is any good way of lighting correctly in MR. thats why theirs other renderers in my opinion, if MR lighting and rendering was great like other renderers then their would be no reason to use another renderer because of the enormous amount of stuff MR supports for rendering… but no matter how much it supports, when it comes down to it, another renderer is gonna give me the lighting quality and the correct color and reflections i need.

#27

FuriousD - beatufully stated
the gamma workflow is seriously impaired in mental ray…i’m struggling with product design
vis at the moment and maya…and i must say (over and over again) that setting up lighting and materials is an exceptionally designed torture machine by maya|mental ray…
nothing is at it’s place, swatches don’t take into account gamma correction, every possible node in the hypershade comes with a brutal load of obscure settings - from filtering to
default colors etc -, the lighting part really gives meaning to saying ‘neverending story’…
at this pace many will be forced to revoke their pledge to maya… you may get the wrong
impression but at the current rate of 50%-75% vis work and only 25%-50% actual creative
design work this isn’t working…autodesk should stop selling a platform more than a software package…

#28

that may help you to fix this ‘desaturated’ or ‘wash out’ feeling :

http://www.xsi-blog.com/archives/133

Don’t be affraid with this XSI oriented article, actualy you can apply these with all the renderer and CG software.

#29

so, is that infact the > gamma node trick for maya?

#30

A possible solution is to render without the tonemapper and render the image in exr format in 32 bits per channel, then you can tweak as much as you want in PS…

#31

Just because you dont get the desired result with ‘one click’ doesnt mean the software isnt capable to get it done. If you’re happy with renderers that apparently support the ‘one-click’ approach, stick with it! However, the problem in your scene arises with the lens shader, which needs special treatment for the textures in your scene. Un-gamma your textures with a gammaCorrect node to encompass the ‘double-gamma’ behavior. [Be aware that the regular 8bit textures as you see them in photoshop are usually already sRGB (gamma 2.2) encoded. That’s why mental ray internally applies the inverse gamma to 8/16bit integer textures when setting the gamma in the framebuffer - not so if you set it in a lens shader, as you did.]
So pipe your textures through a gammaCorrect node with the inverse of the desired gamma (i.e. 1/2.2 = 0.4545 for a desired gamma of 2.2) to avoid the washed-out look. It’s not the software, it’s the user input. Besides, this issue has already been addressed several times in this forum section. Sorry if it sounds like I’m bitching, it’s certainly not my intention. Just wanted to encourage you to search deeper, maybe I’ll post a list of useful threads later this evening.

#32

i was just wondering… since the file node already has a wealth of utterly unuseful settings (for the sverage user) and parameters - wouldn’t it be possible to implement a gamma correct feature inside it? thus ruling out the gamma corect node…
and another thing: i’m sometimes using procedurals (almost all the time infact), and when i’m not i’m relying on simple colors in the diffuse slot etc… but even these seem to lose some of the saturation in a gamma 2.x situation… so how do i fix this?

#33

Hi Floze,
I use to be an XSI user and went through all the gamma correction of textures/bitmaps, etc…
But its just using the colour swatch using the mia_exposure or 3dsmax9 logarithimic exposure
that desaturates the colour. When I was using francescasas tonemapper and XSI I didn’t experience the drastic desaturation as I do with Mental Ray mia_exposure or max’s logarithimic exposure.

#34

That’s probably because actual tonemappers work differently than a simple gamma correction. The tonemappers take into account the actual pixel values to calculate the result, a gamma correction simply scales the values according to the gamma curve - that’s why a tonemapper works on the finished image (as an output shader), not on-the-fly as the lens shaders do. Different story with logarithmic ‘tonemapping’ though, which is similar to gamma correction.

I didnt investigate the mia_exposure too much yet, but it seems to work fine with the gammaCorrect stuff.

#35

You could write yourself a simple phenomenon containing both the filenode and a gammaCorrect. Look into the mayabase.mi, should be there under “maya_file” and “maya_gamma”. Maybe I’ll write that later, it’s really simple.

#36

I’d like to see some sort of post exposure filter, something similiar to the photoshop exr.
Where I could tweak the exposure after using the an exr, also adjust the saturation.
So no longer tweaking render settings, just do it in post.

#37

Ah, the old “why is everything washed out” complaint. :wink:

The answer it; it is washed out because before using a proper color space (gamma):

[ul]
[li]everything you ever used to do was WRONG[/li][li]everything you ever got out of your rendered before was WRONG[/li][li]everything you’ve ever put into it was WRONG[/li][/ul]Back in the day, every shader you used worked in the wrong color space. A classic “effect” of this includes
[ul]
[li]burned out lighting near lights w. decay (causing people to avoid using decay)[/li][li]ugly borders round highlights[/li][li]every place where ‘clipping’ occured things looked baaad[/li][li]adding two values gave a too high sum (a “2+2=10” effect)[/li][/ul]Due to this, many shaders included “special tricks” to work around the problems caused by being in the wrong color space. A classic such “trick” is to blend the specular highlights and the diffuse with something other than pure “add” (something akin to a ‘Screen’ blend mode in photoshop, or by simply turning down the diffuse where there is a specular highlight).

All thos tricks are WRONG, but made the images look "perdy" in the old, incorrect, gamma=1 color model.

The sad thing, also, is that people have - to a certain extent - gotten [i]used[/i] to how software behaves in the old - WRONG - model. 

Take the two "car" images posted earlier (one mr, one fR). While the mr seems to be pushed too hard into the 'compression' part of the tonemapper (whos JOB it is to desaturate overbright to make [i]clipping visually pleasing[/i]), the fR one looks like a horrendeous gamma=1 render.

Your error is to think the fR one is "right" or some form of reference - it ain't. You can clearly see how the reflections are far too strong, and "add" to the cars appearance in a very unrealistic fashion. 

Now the problem; when you switch to a proper color space (in fR, mr, or any renderer), and you keep putting the wrong thing [i]in[/i], you will get error.

Do check that article linked earlier; even though it's about XSI it [b]beautifully[/b] demonstrates the "problem".

The thing is that any time you do a gamma correction at the end, it also means that anything going [b]in[/b] will have to take this into account.

Colors aren't "washed out" due to some "error". Colors are "washed out" becaust you put in "washed out" colors.... the problem is they didn't [b]appear[/b] washed out to you because you watched them in a gamma=1 color swatch on a gamma 2.2 monitor!

I.e. everything you see in every un-corrected color swatch is WRONG. It's not the color it will have in the final image. 

Same with textures; you have a texture which you viewed with gamma 1.0 on your gamma 2.2 monitor. But they looked "right"? Why? Well because every image ever made (especially 8 bit ones, like jpg) have the gamma "baked in". Which means... they are all WRONG (...in [u][b]this context[/b][/u]. There is a [b]very good [u]reason[/u][/b] that they use a 'baked' gamma;  this gamma matches our [i]perception curve[/i], making each level in the file "appear" to be the same, which makes the [i]perfect for encoding images in[/i], because the encoding matches the intensity-resolution of our eyes!! If you write 8 bit files in gamma=1 you lose a lot of information!)

Yes, every single nice digital photo .jpg (story is a bit different with .raw stuff) you saw online or that you ever got from any digital camera are all WRONG (in this context).

Yes. All of them. 

Why did it look "right" before? Because you rendered in the wrong gamma and displayed in the wrong gamma. So while your TEXTURE looked "right", all the "light math" done inside the renderer was done [b]wrong[/b]. 

Some apps have features to correct the color swatches, and to correct incoming filetextures so they get "un-gammaed" into the proper, linear color space. This all is different between apps, and unfortunately is implemented [i]incorrectly[/i] in some cases, or with [i]bugs[/i] in other cases.

Therefore, the only way to be "really sure" is do do your own correction w. color conversion nodes. 

mia_exposure_simple is such a node, which is a SIMPLE tonemapper. (It really is just a brighness/contrast/gamma control w. a tool to compress overbrights such that they do not clip in a ugly way. It's called "simple" for a reason ;) )

Now what one  has to understand is that doing a gamma correction changes the [i]relative weight[/i] between your red, green and blue component, and changing the relative weight is the same as changing the perceived [i]saturation [/i]of the color.

What needs to be done is to put the right color [i]in[/i] in the first place.

[b]
OVERBRIGHTS[/b]

An important job for tonemappers is to handle the overbrights. mia_exposure_simple uses a simple compression, pushing colors above the 'threshold' down until they 'soft clip' to white at a much higher level than where they otherwise would hit "1.0" and hard-clip.

This push-to-white is [i]desirable[/i] and is exactly what happens in film, cameras, CCD's, etc. You may not be [i]used[/i] to it, which may throw you off.

Many shaders have been written in earlier days that have seen this effect in nature (i.e. how stuff that are more lit tends to push towards 'white') and tried to incorporate it in the shading itself, when the 'real' solution is that there is no complicated color shift going on at all in the [i]surface shading[/i], it's just a matter of properly letting high intensities "push towrads white".

(A classic case is skin rendering where weakly lit areas tend towards the redder, and brightly lit tend towards 'white'. Even my own [b]misss[/b] shaders include features to do this; [b]so if you are using any form of 'real' tone mapping with the misss shaders, turn OFF the 'screen_composit' parameter!!!)

[/b]Another thing that throws people off are specular highlights.

In the "old way", specular highlights could blow out very easily, and in a very "ugly" way due to hard-clipping the channels. 

This caused people to make them far to 'weak' (vs. their true "physical" intensity) because even the "weak" value ended up "looking bright". Why? Because "adding" light in this WRONG space a nonlinear add. 

Think of it as "2+2" not becoming "4" but "10" !!

So if "2+2=10", and you [b]want[/b] it to be "4" (coz your eyes says "that looks correct"), then you notice by trial and error that "2+0.5" [u]looks[/u] like "4", so yo use 0.5 instead of 2, and you are "happy".

But when you then put this shading model through a proper tone operator (or even just use plain old gamma correctly), it will indeed look like "2.5" not "4".

This is what has caused many people to throw their hands up and say "this gamma stuff sucks, it worked much better before" and give up on it!!!

When the real error was that your specular highlight was way too low.

The mia_material handles this correctly, and you will quickly notice that if you used it with NO gamma correction or tonemapping, you will most likely perceive it's highlights as "too strong". This is because the shader is [b]right[/b] and you are looking at it [b]wrong[/b]. 

Physical rendering is difficult, [b]mostly due to the fact[/b] that there is such a deeply rooted [i]incorrect workflow[/i] and software written that [b]does it wrong[/b].

People seem to think that renderers like Maxwell etc. are "magic" and much better than things like mental ray, when the [i]simple fact[/i] is that the only [b]major[/b] difference is that those renderers were written with [b]physical rendering ONLY[/b] from day #1, and has no old baggage of 'wrong workflow' and compatibility with decades of "doing stuff wrong" to worry about. 

They can make all color swatches properly corrected, and "uncorrect" any incoming textures automatically because the renreres [b]know for sure[/b] that the output will be viewed in a physical manner, seen through a physical tone mapper, corrected properly for the screen!!


/Z
#38

:bowdown:

It’s a stony and rather long way to the ‘correct’ workflow, I’m happy that I (hopefully) wrapped my head half way around it, thanks to you Master Zap. It’s always good to know what’s actually going on, rather than blaming it on a button that I didnt find.

#39

LOL, floze, yer’ the genius here :wink:

I just realized the “2+2=10” example is almost completely accurate too.

You know that we perceive as “half gray” is actually about 18% gray. We all saw those “18% gray” cards out there.

But this gray which really is about 18% maps to about the middle of our normal sRGB grayscale that we all have on our monitors (intensity 128 on a 0-255 scale or 0.5 on a 0.0 to 1.0 scale)

So when we add two “0.5” (or 128) together and get 1.0 (or 255), we have really done the equivalent of adding 0.18 + 0.18 and gotten 1! Not too far off from the “2+2=10” example.

/Z

#40

I didn’t read all the words that you wrote Master Zap (and for sure, even understood =) but thank you to give us all the time that you spent in this forum!
THANK YOU SOOOOOOOOOOOOOOOOOO MUCH!
Ciaciaaaaaaaaaaaa

Gabba