I posted the poll on Twitter and here on DevTalk. You can always run your poll if you want, though i’m sure you will get similar if not equal results.
It has already been discussed before, the post after answers it:
I still have to see @brecht and @StefanW opinions about the Sun Elevation 0 compromise… people seem to find it a good solution but we never talk about it seriously.
1 Like
I now understand why having a Strength multiplier for the sky texture could be confusing, as it would be on top of the already existing Background strength.
The Sun Elevation 0 sounds like a good compromise to not burn out the render by default.
3 Likes
You say it’s UI clutter. And leave it at that. I hardly call that ‘has been discussed’ or ‘answered’
It’s only 1 extra slider. I don’t see the problem with that, tbh. HDRI’s have a strength parameter as well. I personally would like a way to set the strength of the sky. Physicality be damned. My renders are not always intended to look physically correct.
But it’s your baby and I don’t want to take away from it, however it will be decided I look forward to using it.
All I’m trying to say is, don’t get too emotional. Take a step back and decide how important one extra slider is to you in the grand scheme of things. Your new sky is fantastic. Don’t let your mood be spoiled by such a (smallish) UI detail.
2 Likes
One extra slider is a big issue if it duplicates functionality. Have you actually taken a look at the screenshot two posts above yours? You see that strength multiplier, don’t you? Why would you want multiplier of a multiplier?
It’s a big issue in grand scheme of things because it establishes precedent that cluttering UI with duplicate functionality is fine, which it is not. Every time this rule is broken, it creates additional excuse to be broken in future, until you end up having software with extremely poor UI and UX. The best pieces of software out there in terms of UI and UX are so popular because they don’t consider these decision lightly.
I am responsible for most of Corona Renderer UI/UX design since early alpha version up until about version 1.5 (I then left to pursue game development). While Corona did not have much on Vray in terms of actual performance and rendering features, what made it so popular was the superior UI and UX which was the consequence of thinking carefully about even as little things as if there should be one more parameter or not.
In fact people often said they feel like Corona is both faster and higher quality, and that’s why they like it. But under the hood, both Vray and Corona did mostly the same math. What made people feel this way was that we reduced the parameters enough to prevent them for making stupid things (by reducing possibility of incorrect combinations, or removing parameters that were usually set up by some rule of a thumb which could be decided automatically under the hood).
Now these days, if you look at https://evermotion.org/ frontpage featured renders, and click on each of them, about 70% of them says “Corona Renderer” somewhere in the description. Just 5 years ago, that was not the case. This is a great example of a product that dominated market by something as simple as putting UI and UX in front.
Other than that I agree that 0 elevation is perfect compromise. It doesn’t require internal hack to downexpose and at the same time it doesn’t provide blown out image out of the box.
13 Likes
Hit the nail on the head! That’s how I feel about the recent UI decisions for the modifiers
2 Likes
Well, I understand that at least two of the main members of the UI team are two good Artists rather than developers. (Just clarifying this, sorry for the offtopic)
I did some initial renders comparing ACES and Blender Filmic output in preparation for investigating if this is properly color managed. Note that in the below shots, exposure might vary slightly as I didn’t manage to keep those exposures exactly the same.
Also note that this is a build using the patched “physically-correct” version of the sky model.
Filmic:
ACES with explicit XYZ D60 space:
ACES with no explicit XYZ space:
My OCIO profile roles (see here for more information on how Blender interacts with OCIO profiles):
roles:
color_picking: Output - sRGB
color_timing: ACES - ACEScc
compositing_linear: ACES - ACEScg
compositing_log: Input - ADX - ADX10
data: Utility - Raw
default: ACES - ACES2065-1
matte_paint: Utility - sRGB - Texture
reference: Utility - Raw
rendering: ACES - ACEScg
scene_linear: ACES - ACEScg
texture_paint: ACES - ACEScc
XYZ: Utility - XYZ - D60 // disabled in non-explicit XYZ tests
The Macbeth color chart was set as Utility - SRGB - Texture in the ACES version and SRGB in the Filmic version.
Sky settings are the same in both, and because color_picking is set to sRGB, the material albedo should be the same (as in, I am not picking in ACEScg space, but in sRGB space in all versions).
In conclusion, this looks to be properly color managed as long as the user has an explicitly defined XYZ role in their config.ocio that makes sense in the context of their chosen color spaces. In most common OCIO profiles, this XYZ space is not defined and you might have incorrect render results in those cases. The non-explicit XYZ ACES shots appear to be over-saturated, probably because the XYZ - > Scene Linear conversion is doing weird stuff.
2 Likes
I just want to chime in a second to tell a thing, ACES is completely broken, no matter if it´s used by the biggest companies in the world, it’s broken.
Go to hard light values in a simple plane and you will see what I mean, @troy_s explained to me very well,and once you understand what is happening, it’s pretty obvious.
ACES is not a good reference IMHO.
3 Likes
Sorry but you’re going to have to back that up with more evidence. ACES is currently and has been used successfully for close to a decade and is an industry standard in color management for HDR displays. It’s not “broken.”
Please provide sources or exact steps to demonstrate how broken it is.
A list of productions that have succesfully used ACES: https://community.acescentral.com/t/list-of-aces-productions/23
In addition, it is well supported in many VFX and realtime rendering platforms, mostly through OCIO. What are “hard light values”? Again, please be specific and very clear because you’re basically just throwing baseless shade around with no evidence to back it up.
Do you really think everybody in the VFX/movie industry is so misinformed that nobody understands the basics of color science to see an “obvious” flaw in ACES? Please take a step back and re-evaluate.
The only thing I’ll concede to your post is that ACES is often misunderstood, especially when one does not have experience with it in production.
If you’d like to educate yourself on ACES, I find this resource very helpful: https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/
1 Like
The strange yellowish bar appears at low sun elevations like in the example above… but maybe that’s a model limitation due to single scattering.
Absolutely, one cannot toss out such a claim without evidence to back it up.
ACES has issues with gamut mapping. Specifically, as I understand it, it doesn’t have any gamut mapping. Camera footage with colors outside of the ACES gamut are simply clipped, which leads to artifacts. This causes pipeline issues. Work began in January to address this via the creation of a new work group. See the following thread and forum for more information:
This all is off topic for this thread I believe, except to say that ACES in its current form might not be something that the new Sky Model can be accurately tested with.
2 Likes
This.
In no particular order:
- Discrete 1D lookups will skew the intended colourimetry.
- No gamut mapping. The current VWG is limited to the reference space gamut mapping, and the current approach has equally problematic downsides from an imaging standpoint.
- No gamut mapping in the display rendering transform.
These issues have been around forever. There are receipts too, for those who care to look.
So when evaluating an appeal to authority by a listing of projects that “use ACES”, it is prudent to realize that it does not necessarily imply the full chain. For example, the LEGO movie did not use the entire ACES chain, and rendered in DCI-P3. But anyways, this isn’t the thread for hijacking. Perhaps another would be wise.
7 Likes
Thanks for the insights. I think we can agree it’s a far cry from simply broken.
Anyhow, the purpose of my post was to show how the Sky was stable even when testing using a different arbitrary color space utilizing OCIO to show that color management works and there are no hard coded color space conversions. So, feel free to use it with any OCIO color space.
3 Likes
I’m comfortable with the word “broken” here; it yields pretty ghastly imagery by default, for those folks who don’t have [a] colourist and colour science peep[s] on their side to fix the issues.
Except for the wide gamut examples, which seemingly (?) suggest some rather all-too-sharp ~550nm range, leading to the nasty looking problems?
3 Likes
Can you clarify what wide gamut examples you’re referring to? I just showed an example rendered in ACEScg space, with the proper OCIO configuration, that seems to render just fine.
I believe the XYZ D60 space in the ACES OCIO config is defined for ACES 2065-1, which is AP0 primaries, not AP1. The default rendering space is ACEScg, which is AP1.
Cycles needs an XYZ>AP1 conversion for the sky texture. Troy and I spent some time awhile back trying to figure out what the definition for the XYZ role is supposed to be for ACES in Cycles and we concluded it’s this:
- !<ColorSpace>
name: ACEScg XYZ
family: ACES
equalitygroup: ""
bitdepth: 32f
description: |
The ACEScg to XYZ transform
isdata: false
allocation: lg2
allocationvars: [-8, 5, 0.00390625]
from_reference: !<MatrixTransform> {matrix: [0.66245418, 0.13400421, 0.15618769, 0, 0.27222872, 0.67408177, 0.05368952, 0, -0.00557465, 0.00406073, 1.0103391, 0, 0, 0, 0, 1]}
1 Like
Thanks! This is interesting, I’ll add it to my OCIO and see how it works with my ACES 1.2 config. Any more info you can share regarding this is appreciated.
Thank you Brecht for committing the patch!
Now the sky has no internal hacks! 
https://developer.blender.org/rBd40c39fca0fc3b87d852f672844687eb824c3d42
30 Likes