Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] General Discussion => Topic started by: Coxy on 2013-08-05, 23:49:36
-
Hey guys,
I can't seem to find the gamma in the new alpha 5 version, is it the color channels output?
-
Gamma Settings are hidden inside the Corona Settings > About > debug. Do you are going to mess with gamma ?
-
You should never touch gamma. We should have that value locked. ;)
But i understand a temptation of people who do not do post processing and want their renders to come out more contrasty. And Contrast feature in post processing tab does not work...
Well, there is a way :) Simply decrease highlight compression under value of 1... like 0.5 or 0.3, etc... to get the contrast you need. If it gets too bright, you can compensate by lowering Exposure compensation. You should keep in mind exposure compensation can go in negative values... i realize that is not very intuitive, but it will remain that way until real physical camera is implemented :)
-
You should never touch gamma. We should have that value locked. ;)
While I have no reason to change the gamma it would be strange if you guys would start making these decisions for the user. Well in alpha stage, sure, do as you please but I hope this doesn't reflect on how things progress once we get to pay for Corona. I remember a certain developer of a certain unbiased renderer threatening his paying customers with removing the option for ambient occlusion because he didn't like the way some people used the AO pass.
-
You should never touch gamma. We should have that value locked. ;)
No no no no no. Please do not do this, I work in a range of 1 and is vital to me that setting. Please do not do it.
-
You should never touch gamma. We should have that value locked. ;)
I also think that you absolutely NEED to keep the value adjustable (there are people who either need or like to work in something else than 2.2), and that it should be exposed in the common renderer properties and not be hidden.
I for one always work in 1.8, going with 2.2 always looks wrong to me even if it's technically correct...
-
I just hope people will stop touching gamma once some better contrast function is implemented ;)
-
I would not count on that. As long as there are spinners and buttons, there are people spinning and pressing them :D
-
I just hope people will stop touching gamma once some better contrast function is implemented ;)
But then why would you care? once you go commercial, will you be offering a flexible tool for artists or will Corona be a "statement" like some of the commercial unbiased engines that outright refuse to deliver if their unbiased core would be compromised in the process? I think it's an important question and one I would like to have answered - migrating from a render engine to another is tedious work and I'm sure I'm not the only one who's made bad investments along the way. I hope you understand where I'm coming from with this!
-
yes, the problem is that I just sometimes assume people use 2.2, and then when they would use for example 1.0, some unexpected bugs could appear
-
yes, the problem is that I just sometimes assume people use 2.2, and then when they would use for example 1.0, some unexpected bugs could appear
Ah, understood.
-
yes, the problem is that I just sometimes assume people use 2.2, and then when they would use for example 1.0, some unexpected bugs could appear
I use gamma 1 from the very beginning - process is adjusted and no hypothetical errors stop me. I categorically vote for gamma controler existence.
-
Control/Flexibility is always best. :)
-
Control/Flexibility is always best. :)
It is sometimes not easy to explain, bug gamma does not offer any control or flexibility. It is simply a difference between displaying output correctly or not. If pictures with gamma 2.2 look wrong to you, then you should use post processing to adjust them to your liking, or use less than 1 HL compression value as i said.
Gamma correction/LWF is a tool to display what is being rendered on your monitor correctly... you will not get any flexibility or control by changing it, only problems. Yes, many times you end up with your renders being washed out... but gamma is not a thing to change... this has to be changed either in post processing package or via controls in renderer that are dedicated to it. In mental ray for example, mr photographic exposure shader has settings to tweak highlights, shadows and midtones of hour image... vray has similar stuff in it's color mapping settings, and also in VFB... but gamma is just not a good thing to touch.
-
many times you end up with your renders being washed out... but gamma is not a thing to change... this has to be changed either in post processing package or via controls in renderer that are dedicated to it
Or in the scene where lights or materials aren't set up correctly. ;)
I guess adding a levels- or curves-style post processing option would satisfy most users having this urge to experiment with gamma.
-
Just save in 32 bit format like open EXR and you are golden to work in post. But I do agree gamma is probably the most open talked about issue with 3D artists. I personally use 2.2, but a lot of Vray users are going with the set output to 1 and use the Frame buffer to make changes.
-
that can still be technically correct, but I just don't like it, because it violates my workflow "first make the image photoreal, then make it pretty" ;)
-
Control/Flexibility is always best. :)
It is sometimes not easy to explain, bug gamma does not offer any control or flexibility. It is simply a difference between displaying output correctly or not. If pictures with gamma 2.2 look wrong to you, then you should use post processing to adjust them to your liking, or use less than 1 HL compression value as i said.
Sounds like you're understanding gamma as an post-render thing only, while it actually has to be considered pre-render, when textures are handled with a correct de-gamma correction so they look correctly when rendered. That's why you tell max what gamma you're using so input values are passed correctly to the render engine. Am I getting this wrong?
Keymaster, I for one actually would want gamma to be a 'variable' throughout the whole renderer, otherwise you can prepare for seeing 'bug' reports because people actually need flexibility in all kinds of different workflows. While I realize the above posted paradigm is good (!), flexibility doesn't automatically exclude this from being achievable :)