About 18:50.
Seems extremely useful for getting correct albedo/roughness maps etc in srgb/linear values.
ha…interesting idea. It was pretty handy in SP having that.
Indeed, we’ve just started an SD+SP trial. It’s pretty amazing. We have tons of Vray materials in our library, it would be good to go through them all and take them through this process.
Wonder how something similar could be implemented in Vray? maybe a render element?
I’m not sure i understand it: why would a value of 30 in sRGB be “too dark”?
All this PBR lingo and approach sounds so arbitrary to me. There, i said it.
Other than that, you can furnace render (Ganzfeld light, whatever you want to call it. White-dome render) a sphere with the shader attached to ensure you are energy preserving when creating unbound additive blends (able to go above 1.0f).
Any value in that render exceeding 1.0f will be wrong (unless you’re emitting, ofc., or performing complex multiple scattering which produces caustics somewhere.).
Notice i spoke of no lower bound, with the only wrong value really being 0.0f (and that would come out as 0.0 in the image.).
Notice i didn’t use conditional tenses like in the video above: 0.0 and above 1.0 are wrong, as they do not exist in nature. Anything else within those bounds is valid and plausible.
This is quite simple to script, but likely it would not be quick to execute (particularly as image/sample sizes grow).
I see no way in which a tool like this would know of anything at all about a BRDF’s true character, and much less so help in producing plausible shaders, particularly under the kind of dynamic ranges we subject them to (where the results of multiplying lighting by the BRDFs can be *well* beyond the visible, and not forcefully bound to an upper value, like in most realtime applications.).
I stand, of course, to be corrected.
p.s.: why does anyone need sRGB validation? Are you people not under LWF, or scene-referred linearity, yet?
Agreed.
LWF works straight out of the box and has done for quite some time now. Not sure why people are going about changing this?
Also that video (20:47) shows a comparison of “correct” and “incorrect” albedo - though both look good, there is no reason for one to be correct and the other incorrect other than artistic preference.
I don’t have substance but it looks like you can set the color space and critical values yourself.
Since its substance which targets also realtime engines, srgb is still a thing. They’re using 8bit formats that get automatically corrected under the hood of the engine.
At least in Unity the user is bound to use srgb for that reason.
I think I’d love a heatmap like RE that’s able to judge the albedo scene-lighting independent. The user could set min and max values himself.
The great thing about this video, is that it actually sets some guidelines/
I’ve yet to come across a concrete, certified, validated by Chaos group method of creating a shader correctly, with all the maps within that shader adhering to specific guidelines. I’m all ears, if you can point me in the right direction.
Literally, a video, or web page, that takes you through the correct process setting up a brick material for example, something simple. Such a guide would take you through each step in the shaders creation, ensuring each map is taken through a process ensuring energy preservation amongst other things. I’m sure there are some on the tinternet’ somewhere, just the problem with that is, its not Chaos group endorsed, and can I trust it is the correct way, if it isn’t?
I just wan’t certainty, clarity, and not all this doubt hanging over my head, this at least gives me something to go off.
Other than that, you can furnace render (Ganzfeld light, whatever you want to call it. White-dome render) a sphere with the shader attached to ensure you are energy preserving when creating unbound additive blends (able to go above 1.0f).
Any value in that render exceeding 1.0f will be wrong (unless you’re emitting, ofc., or performing complex multiple scattering which produces caustics somewhere.).
Notice i spoke of no lower bound, with the only wrong value really being 0.0f (and that would come out as 0.0 in the image.).
Notice i didn’t use conditional tenses like in the video above: 0.0 and above 1.0 are wrong, as they do not exist in nature. Anything else within those bounds is valid and plausible.
This is quite simple to script, but likely it would not be quick to execute (particularly as image/sample sizes grow).
I followed that, fairly well 
But to be certain, would you have some time perhaps to go through this in a quick video? I’m sure there are others reading this that would appreciate it too.
I see no way in which a tool like this would know of anything at all about a BRDF’s true character, and much less so help in producing plausible shaders, particularly under the kind of dynamic ranges we subject them to (where the results of multiplying lighting by the BRDFs can be *well* beyond the visible, and not forcefully bound to an upper value, like in most realtime applications.).
So are you suggesting their method is wrong? Or that it cannot apply to Vray considering it is not a real time environment?
Corona actually seems to have something similar.
Excellent!
So we have something even closer to Vray (in fact, the same company) doing something similar.
This is precisely why I don’t understand the fuss about albedo values. The vray material is energy preserving whether your albedo is 0 or 255; you don’t need to “compensate” and use a higher or lower value to make sure that it doesn’t break the laws of thermodynamics as all of this happens automatically within the shader.
And still, white is often surprisingly dark and black surprisingly bright. Just because a material isn’t emitting light doesn’t mean it’s realistic.
I think the point is to get a tool that makes it easier to view the total Albedo to help keeping the materials in realistic ranges.
I use the raw diffuse element when I inspect scenes I didn’t create. But that will only work with the vraymtl and it’s sometimes hard to see the differences between a bunch white objects or black objects.
I think this would especially be useful as many people use third party assets and many of them are very wrong in terms of bightness. And yes, I actually sometimes even see materials of third party assets that emit light due to mindlessly created additive blend materials.
Going through a scene with 100th of Objects and put every material in a new, empty scene with a dome light to then render and test the values using the color picker would be a very long and exhausting process.
This…
Even in corona It’s set at an arbitrary 220 white for “too bright”.
I would think we’re faced by two different issues here: one is of knowledge (ie. what makes a good shader Albedo value, and so on), and the other is of tools.
I wholly agree on spreading knowledge, will try and help with that myself, within reason.
I can’t wrap my head around tools like these (even if they are in Corona. Not even married couples agree on everything, and we don’t even live under the same roof! ^^).
I’m not sure how an albedo element will help; for example, I had a user scene where their grass material and their ground materials were way too bright - not 220 bright, but too bright for grass and soil (if you look f.e. http://www.intelligence.tuc.gr/renes/fixed/info/reflectanceinfo.html). I’m not sure how V-Ray can detect what you are trying to render. Having a preset library will probably help, comparisons against VRscans too, but for custom-created materials it’s not straightforward.
Best regards,
Vlado
Btw Autodesk has a cool white paper on how to measure reflectances yourself, just need to find it…
Best regards,
Vlado
Presets would be a good way to go. Dialectrics and specific metals, providing a baseline from which to start with. SD has a number of them, all of the technical jargon and science is bundled into each leaving you to just get on with things.
I’m just wondering why, if it’s an irrelevant tool, we see it in Corana and SD?
I remember a similar response to baking LUT presets into frame buffer imagery, and how this was a terrible idea. But that line of thinking seems to have reversed.
double post
How is reducing the dynamic range of your albedo going to alleviate this? If your blacks are too bright, increasing them to rgb30 is only going to make them brighter, conversely with whites.
Oh I hope it’ll be found!
Its more about to correct values that are to low (for blacks) or to bright (for whites).
Srgb 30 is still very very low in linear space probably too low…
Of course such an element would only make sense in vray if it would be linear and the user could set the values that get highlighted if exceeded himself.
Its the Idea behind it which I find interesting not the crappy way they(both) did it.
But I guess I’m wrong having vlado and lele both saying its pointless XD