Chaos Corona Forum
Chaos Corona for Cinema 4D => [C4D] General Discussion => Topic started by: JPeters on 2018-10-11, 12:05:10
-
Hi guys,
Got a question on something that confuses me.
- Using Corona with Cinema4D and the textures are loaded in as Corona Bitmaps as they are UDIM format.
- Textures are made in MARI and saved out as linear tiff sequences.
1) When I plug my linear colour texture from MARI into the diffuse channel of the shader and put the colour profile to Linear (or embedded), everything is fine.
This is normal behavior and works as expected.
2) However lets say I've got a value of 0.55 in the Glossiness with which I get a good result.
If I replace this value with a flat color in Cinema of 55% grey I get the same result as with a 0.55 value in the Glossiness without a color.
Now comes the weird part: If I load in my MARI texture which is 55% grey (linear file format) the texture looks good in the preview but the result in the shader is completely off.
3) I have to then apply an inverse gamma on my texture (Manual Gamma=>0.45 Input Gamma) for it to work properly in the shader. However the texture preview is all blown out obviously.
4) It seems to behave like this on any shader part where you'd normally input a greyscale map (so not diffuse / SSS / reflection color etc.). I personally tried it on Glossiness and Anisotropy
My question therefore is:
Is it a bug that I have to apply an inverse gamma on my linear greyscale textures or is it working as intended.
And if it's working as intended, why is this the case as it's very confusing.
EDIT 1: I've also tried the same with .exr files instead of .tiff (as .exr is the standard file format for texturing in VFX) which gives exactly the same result and also needs an input gamma of 0.45 to work.
EDIT 2:
Here is the scene, and a render.
Cube 1 - 0.55 Glos
Cube 2 - CRN 55% grey
Cube 3 - MARI 55% grey
Cube 4 - MARI 55% grey - Inverse Gamma
-
Hi, could you please upload the scene or a downscaled version of the map for comparison?
It's the first time I hear about this issue.
I can't tell where the problem lies as I don't use MARI(never had to paint a 32k² map ;) ), but having the files could shine some light on the whole problem. At least point towards a direction.
edit: have you tried plugging the map into a corona bitmap shader? It usually resolves similar issues, even though it may not like it would do more than manual selection.
-
Hey Eddoron,
If you are using just one UDIM for a large asset when texturing (why you would hypothetically need 32K) you are doing things very very wrong :D The whole point is that you unwrap your object over multiple UDIM's and thus can use smaller maps (for instance 4K) to get the same effective resolution out of it.
C4D does somewhat support UDIM's but it's not properly implemented, it is in Corona however which is great!
To answer your question, I'm already using the Corona Bitmap to begin with as this is a UDIM based texture and Corona Bitmap is the only way to get those to work.
I've attached a texture which is exactly the same file format and color space as the textures I'm working with, due to NDA I can't share the actual maps.
-
Hi,
I know that C4D supports UDIMs indirectly. I was just joking because that high map size seems to be one of MARI's better-known features.
However, If you had to map a planet using a singular spherical map, 8k barely does the job.
I'll take a look at the file later. The dev's, if they haven't left into the weekend, should also have a look at it.
-
Just a small update:
I have tried the same thing with .exr files instead of .tiff and it gives exactly the same result, I have to apply an input gamma of 0.45 for it to work.
-
My coffee is still about to kick in, so please bear with me.
The problem is with the tiny 2d preview, not the "shaderball" 3d preview of the material, right?
A pic says more than a thousand words. It's just that either, I don't have, see or understand the problem bc I tried the map and it looked as expected.
edit: ok. Did some testing. I created a small file in PS. a square with the top left, pure white, bottom, right pure black and the rest 50% gr @16bit linear.
The CRN Bitmap shader gives the correct output. (small 3d&2d prev.) The embedded color looks the same as choosing linear. (still prev views) The render fucks up. There's a visible aberration of the desired glossiness.
To me, it looks like a bug, but I'd wait for others to try it before creating a bug report.
-
No, the problem is that I need to apply a 0.45 "Input Gamma" to a linear map to function the same way as a flat color inside C4D would, or a flat value without a texture.
I tried to explain it as best as I could in the first post but basically it seems that Corona doesn't function the same way any other render engine I've used (Mental Ray / Vray / Clarisse).
For instance, let's say my glossiness in the shader has a value of 0.55 without any map in the slot. This gives me a certain result.
If I then plug a flat C4D color in the map slot with a greyscale value of 55%, I get the same exact result as above. Which is as expected and as it should be.
If I then load in my MARI texture (instead of the flat C4D color) which has a greyscale value of 55% I get a completely different result. I have to change the Input Gamma for this texture to 0.45 for it to look the same as the 0.55 value or the 55% flat C4D color.
This last bit is my problem because that is not how it should normally work. There seems to be some kind of bug in Corona (it also happens with the standard C4D bitmap) which makes greyscale maps function in a weird way.
As I said in the first post, the COL map I made in MARI I can plug into a Corona Bitmap in the diffuse channel just fine and it functions perfectly if I set it to Linear. Once I plug 16 bit linear maps into any other slot that isn't color related though, thing seem to go awry.
-
yup, I mentioned it in my edit. (this post was just in case you didn't see it)
-
yup, I mentioned it in my edit. (this post was just in case you didn't see it)
http://prntscr.com/l5bec4
-
trips means pics?
-
Any devs that can look into this or comment?
-
all seems fine on my side (except a bit darker representation of crn_BITMAP in OGL viewport) - with texture you provided above
post a simple scene showing an issue! (possibly with imagery, results)// cuz your post is confusing, you're confusing - keep it simple
-
The issue is not when you plug that greyscale map into the COL (diffuse) slot of the texture and put it to linear, it's normal then.
The problem arises when you try to use that greyscale map to control a value of the shader, say the "glossiness". If you plug it in such slot and put it to linear, the result is different from what it should be.
To put it in the most *basic* description possible:
A linear texture from MARI which is 55% grey plugged in for instance the glossiness value of the shader does not behave the same as a flat C4D color of 55% grey or a value of 0.55 (the last two do), and it should behave exactly the same.
It does so in Vray, Mental Ray and Clarisse.
In Corona you for some reason have to apply an inverse gamma (manual gamma on 0.45) to get it to work as it should out of the box in any other render engine.
This happens only in texture slots which control values, not in texture slots which control color.
In other words when you set the file format to linear diffuse is fine, specular color is fine but glossiness etc. is not.
-
how do you know what i have done, i followed steps described, why --->> simple scene & images showing the issue, PLEASE!!!
words are useless!!!
-
how do you know what i have done
Because if you did, you'd come to the same conclusion as Eddoron and me, the it's not working as intended.
That being said, I'll prepare a scene when I have time later Today or Tomorrow. Scene posted in the first post and on the next page.
-
Here is the scene, as promised and a render.
Cube 1 - 0.55 Glos
Cube 2 - CRN 55% grey
Cube 3 - MARI 55% grey
Cube 4 - MARI 55% grey - Inverse Gamma
-
Thank you for taking the time to present your issue in simple & readable manner.
Well, it looks like MARI works this way:
- Understanding Mari 3 Colorspace (http://community.foundry.com/discuss/topic/120203/understanding-mari-3-colorspace?mode=Post&postID=1005285)
- Colour Spaces in Mari (http://www.xuanprada.com/blog/2014/12/18/yp1vbfosa6q0h2ewn695h3cosu81xn)
So what you observe, is correct behavior & with that in mind, results are consistent all over, in other apps and engines (although a few adapt shaders automatically ie. Unity:What the shader does for the albedo and specular is "linearize" the maps. It removes the gamma-encoded values from the map in the shader code by applying an inverse gamma to it of 0.4545. In the Unity workflow, this is done automatically and you don't need to flag the images as sRGB.
My conclusion is - It's nothing wrong with Corona (except the need to do this automatically) - feature request! ;)
eg. CentiLeo settings for comparison:(https://i.imgur.com/Dsp7RgU.jpg)
-
Thank you for taking the time to present your issue in simple & readable manner.
Well, it looks like MARI works this way:
- Understanding Mari 3 Colorspace (http://community.foundry.com/discuss/topic/120203/understanding-mari-3-colorspace?mode=Post&postID=1005285)
- Colour Spaces in Mari (http://www.xuanprada.com/blog/2014/12/18/yp1vbfosa6q0h2ewn695h3cosu81xn)
So what you observe, is correct behavior & with that in mind, results are consistent all over, in other apps and engines (although a few adapt shaders automatically ie. Unity:What the shader does for the albedo and specular is "linearize" the maps. It removes the gamma-encoded values from the map in the shader code by applying an inverse gamma to it of 0.4545. In the Unity workflow, this is done automatically and you don't need to flag the images as sRGB.
My conclusion is - It's nothing wrong with Corona (except the need to do this automatically) - feature request! ;)
eg. CentiLeo settings for comparison:(https://i.imgur.com/Dsp7RgU.jpg)
Thanks for looking into this.
It sort of makes sense but at the same time it doesn't. Why does Corona linearize the COL/SPEC COL maps but not any of the others when the embedded profile/setting is set to linear? That is just weird if you ask me, certainly since any other render engine I've worked with (Vray / Mental Ray / Clarisse) does do this properly.
-
Values are not colors, therefor don't get the auto color correction treatment.
What does machine know? Nothing. ;)
-
Well, since they are driven by an RGB map they are clearly colors and should therefore be treated as such right?
-
Well, since they are driven by an RGB map they are clearly colors and should therefore be treated as such right?
Basically (LWF management) (https://community.renderman.pixar.com/article/1206/linear-workflow-color-management.html)... How right has left the building. ;)
-
Thanks for that article :)
That being said, it's still weird that I have to apply an inverse gamma to an already linear image for it to work as a value.
-
Wake up... pay attention
(https://i.imgur.com/7KWm2Ow.jpg)