Everyone who has written here complained about usability of material UI.
So, one problem of black rendering without running IPR is one thing and will be solved.
And let's think about another problem of layouting it. I need the help of D K, Alexey Brin and pBarrelas regarding this problem.
First, I suggest to make standard button (>) for each shader slot which if non empty also creates a direct button to existing shader/texture and (...) to select bitmap. But if there are several nested shaders, they are unrollable and there could be some bugs with values updating which I saw with other engines too. But need to test it again.
Using this standard button will also consume more UI space vertically. But they are unrollable which is good.
And this button will mix our shaders with others in a menu and we will to at least pre-bake Cinema shaders to support them at least as pictures.
Do we need a checkbox together with each row with constant property and shader/texture? That checkbox can determine what is used a const value or shader for given property. Right now if shader is applied then const value contolled by slider is not used. If you want const to be used again then you need to clear the shader/texture value.
Material UI design brainstorm
good to know that you're considering to make the Material Editor more intuitive and user friendly!
Regarding the Material Editor preview window, besides only updating when the IPR window is open, it still shows the effect of all the channels even if they are off. This makes extremely difficult to make some quick material tweaks.
1-I do agree that the standard button for each slot is better than the current implementation.
2-Having that check box would make the Material Editor more versatile. This way we can chose to use either a colour or a shader, without having to disconnect that shader.
3-Please add more Reflection Coating levels.
4-Please add a dedicated Mask channel for the entire material.
5-Turn the material channels animatable.
6-Add Emission channel.
7-Ability to use chose a certain UV Tag to be used on that channel. I honestly don't know if this is a C4D SDK limitation.
Here's a possibility I worked up in PS:
Regarding the use of different UV Tags at the channel level, just by have 3 available would be great. I suggested the use of a link field, that could be named UV Tag, because we're used to this kind of drag n'drop behavior in C4D. Then, the name displayed on that field
, once populated, would be the name of the UV Tag itself rather than something, from a drop down menu, like UV1, UV2..
It just looks more intuitive to me. But, like I said, this just my personal view.
This is a feature I asked Maxon to be implemented but sadly it hasn't yet.
Modo's shader tree is very flexible because you can use whatever UV set to control the texture placement at channel level. Sadly we can't do this in C4D.
Correction: in Modo, we go even deeper than channel level, we can use a different UV set per texture. As an example, in the Diffuse channel, we can have 2 layered textures and each one can use a different UV set to control its placement, without any limitation.
Maybe 3 is too small? Anybody uses more?
Such things are by default in Max too (despite of it's non drag&drop nature and long geometry preparation time). E.g. Max gives us geometry at 10n time, where Cinema gives it at 2n time and CentiLeo gets it in around 2n time.
1) Can Reflection Color brightness be higher thatn 100%? Maybe should we use 0..1 range in place of 0..100% ? 0..1 is easier to undestand when all the shader input/output are in these absolute values (not percentages). I believe it would be easier with this considering existing math shaders and more future shaders especially when node based shader GUI will be out.
2) What invert checkbox is doing? Is it an indicator that switches between constant and shader property?
3) All the properties will be with shaders/textures including Fresnel IOR and Aniso rotations. Cool things can be done with that.
4) Displacement will not be here but probably in another material like current multi-material or separate "geometry_shader" which will be assigned as tag for an object.
5) Will highly likely add the dropdown selection of mixing mode for material layers: "stack based" (like now, higher layer override lower layers) or "weight based" (like people used to, everything is relative to each other).
1-The colour slider shouldn't go higher than 100%.
The only colour parameter that should and must is the one from the Emission channel.
I'm OK with having it between 0-1 instead of 0-100% if that facilitate your work. Others might have different opinions, though.
2-The Invert checkbox serves to invert on the fly the grey scale images used on certain parameters. This speeds the workflow.
4-Is a current limitation the fact that the Displacement channel, can't be used on the "regular" material?
2) Will think about it. Btw, there is cntlColorCorrection shader where it corrects the input shader and it is possible to make inversion when you put out_rangeA = 1 and out_rangeB = 0.
The same inversion trick works for cntlTexture (imagefile) and cntlNoise.
4) Well, I have limited displacement to one only place (in multi-material) so that it would be easier to evaluate displacement for sufrace (without gathering all the layers). Later that parts became faster and soon they will become even faster. And there will probably be an opportunity to combine many things for displacement slot. However the shaders such as cntlFallof (i.e. based on view angle) seem to be irrelevant for displacement when somebody plays with them.
"surface mask" is the only material property that will remain understanding only cntlTexture. This is so because of performance reasons. It basically enables and disables some surface region based on texture. And it allows unlimited trace depth for this feature for free. But if some shader customization is needed for such things then Transmission with IOR = 1 and shadered masks of the cntlStdMat can be used, but trace depth for this feature will be limited to the number of ray bounces (maximum supported is 30).
I do believe a good render must be
1. artist friendly, delivering the best working efficiency.
2. easy to understand, without reading menu or watching tutorial.
3. with less settings as possible, easy to use, save time of artist.
I think the C4D workflow is perfect for majority, if Centileo render can follow c4d's philosophy, that would be benefit for all c4d user
I like to use c4d's layer based material system instead of using node based (because for middle and small project, node based has no working efficiency) , but if you can give us both of them, that would be perfect.
have a nice day.
Users browsing this topic