Your thoughts on the current TexMap and Color Mults( Blend)

[Micha_cg]

Your thoughts on the current TexMap and Color Mults( Blend)

The environment options are a special case, but with the above tools you could indeed leave the two multipliers and make it only one.
Texture path x color x intensity x gamma

If texture path is empty, you're using a pure color for environment. If color is white and you specified a texture, the texture is not altered because muliplying with white does nothing.

I don't have a clue how they work now. If you choose a texture, is the color field disabled? Has the color multiplier an effect on the texture?
...

I would not disable the color if a texture is used. The color could act as a color filter for the texture.Could be a nice feature for more render freedom. The intensity option but is only necessary if we get acess for intensities above 1 (important for lights/environments). If the texture control is limited to intensity 1, than the multiplier could be saved out. The intensity could be easy controled from black (0) to white (1).

[flipside]

Your thoughts on the current TexMap and Color Mults( Blend)

I would also not disable color if a texture is used. The last line I was wondering about how it works now, not how I would want it to work.

Why limit intensity on normal textures to 1? You could use an intensity 5 texture as an object light, like for example the screen of a TV. If intensisty is above 1, the texture starts to emit GI light instead of only bouncing it off, and that is a great function.

[Micha_cg]

Your thoughts on the current TexMap and Color Mults( Blend)

I would like to see an unlimited multiplier too.

But I think, the surface dosn't act like an emitter. In some cases it would send more light as it receive. But in other cases, if you use a very dark texture you would got only a bright texture.

[joe_b]

Your thoughts on the current TexMap and Color Mults( Blend)

Currently the way it works is like this.

// apply the color multiplier
color = color * color_mult;

final_color = combineTex( context, color_texture, color, color_texture_mult);

What this does is combine a texture at a given context. The last param of the combineTex function is the blend factor. Currently we blend between the color with whatever multiplier it has, and the texture's color at a given context.

What its sounding like you all would like would actually look more like this.

final_color = combineTex( context, color_texture, color, 0.5 ) * intensity;

The difference here is that the texture and color will always be blended evenly and then an overall intensity will be multiplied at the end. Am I figuring this correctly? Oh, as for gammma, that will be applied to the color_texture prior to combining I believe.

[Thomas An._cg]

Your thoughts on the current TexMap and Color Mults( Blend)

I don't understand for what I should need a blend function? I could wash out a texture with a color.

But why should we use a blend? This question is open.

I would like to get one multiplier and that the texture and the color are multiplied:
multiplier * color * texture

Here you are saying that you don't want a blend function and then you propose a "Color*Texture" method which is essentially the multiplying blend mode in photoshop (or PaintShop). You seem confused.

I think an addition is not so useful in image manipulation. If you add a color, you change the brightness.

With multiplication you darken the image and thus you also change the brightness. Based on your conclusion then multiplication should not be usefull either.

The multiplication of color and texture and intensity works with normalized values.

Addition also normalizes, so what is your point.

I think you are just arguing for the shake of arguing just because you are used to the AIR way of doing things.

The concern is the user friendliness. The method of blending should be discoverable and evident by the users. (If Wouter doesn't even know what the current blending mode is then we have a problem). If you want to keep your multiplying mode ... then fine ... but keep it with two multipliers because it is a more flexible design. It doesn't bother you if it has two multipliers ("ColrMult*Color*TextMult*texture) ... in your case just keep textMult=1 and then the formula becomes your formula ("ColrMult*Color*texture).

What I am proposing is to keep the interface familiar (more people are familiar with photoshop than with Renderman).

Also this way you can add different blending modes in the future.

[Micha_cg]

Your thoughts on the current TexMap and Color Mults( Blend)

OK, let's talk about the basics please. For what do we need this blend function? I have asked it several times, but never have got an answer. I would like to read some practical arguments befor we go deeper in the code. I can not remember that I have missed this blend function.

[Thomas An._cg]

Your thoughts on the current TexMap and Color Mults( Blend)

OK, let's talk about the basics please. For what do we need this blend function? I have asked it several times, but never have got an answer. I would like to read some practical arguments befor we go deeper in the code. I can not remember that I have missed this blend function.

Micha,

This ---> Mult*Color*Texture<--- is your function (from renderman). This renderman function is a blend function. What part of that don't you understand ?

[joe_b]

Your thoughts on the current TexMap and Color Mults( Blend)

OK, let's talk about the basics please. For what do we need this blend function? I have asked it several times, but never have got an answer. I would like to read some practical arguments befor we go deeper in the code. I can not remember that I have missed this blend function.

Micha,

This ---> Mult*Color*Texture<--- is your function (from renderman). This renderman function is a blend function. What part of that don't you understand ?

I think when he says "blend" he means this general function

Color Blend( Color one, Color two, real blend ){
     Color final_color = blend * one + (1.0 - blend ) * two
    return final_color;
}

Now this will make one color more strong than the other(assuming blend is not equal to 0.5) the variable "blend" is limited from 0 to 1 so its just a percentage of each color making its contribution to the final color.

I wouldn't necessarily say that TextureColor * Color * Mult is a "blend" function because there is no such number that would allow equal contributions of both. But I guess, it is technically blending the colors, just not in the same sense that the above function blends.

[joe_b]

Your thoughts on the current TexMap and Color Mults( Blend)

OK, let's talk about the basics please. For what do we need this blend function? I have asked it several times, but never have got an answer. I would like to read some practical arguments befor we go deeper in the code. I can not remember that I have missed this blend function.

I am just a programmer, but I would assume this blend function is for weighing contribution between color and texture color at a given context. I do not know what this means in terms of an artists workflow, however, nor do I know if there are other better ways of doing this, nor do I know the pros and cons of this. That is what you guys are for

[Thomas An._cg]

Your thoughts on the current TexMap and Color Mults( Blend)

Joe,

These are his own words from here: http://www.asgvis.com/phpBB2/viewtopic.php?t=372

It is the old confusing game of the blend function. I would wish to get a single multiplier only. I have asked befor but get no answer: what is the advantage of the blend function? Why not a simple multiply function like in the renderman code language?

surface color = intensity * color * texture

This --> surface color = intensity * color * texture <--- is the multiply mode from photoshop. So he wants a blend function and then he is asking what we need a blend function for ... this is confusing.

[joe_b]

Your thoughts on the current TexMap and Color Mults( Blend)

It seems the way we have it right now is actually the way Micha wants it, except he doesn't want the blend factor. But hear me out here...

When you set the color multiplier it does affect the final outcome, however, not if you have the texture multiplier at 1.0. A texture multiplier as it is now means that the texture color is favored completely over that of the color. Now if you change that to 0.5 then you are blending between (Color * ColorMult ) and Texture by a blend factor of Texture_Mult.

So what I'm saying is, if you have the texture mult at 0.5 then you can actually use the Color Multiplier as the overall intensity. Does that make sense?


[edit]
I do, of course, concede the naming of Texture Multiplier is very confusing at this point. But to be honest, I just realized it's functionality when Micha brought it to my attention..

[edit2]
The light material's texture multiplier is actually a real multiplier right now because I wrote that one differently than how Vlado originally had it...so that is another point of confusion right now....Hence the reason I want to squash this and come to some point of agreeing before I fix all this stuff

[joe_b]

Your thoughts on the current TexMap and Color Mults( Blend)

Joe,

These are his own words from here: http://www.asgvis.com/phpBB2/viewtopic.php?t=372

It is the old confusing game of the blend function. I would wish to get a single multiplier only. I have asked befor but get no answer: what is the advantage of the blend function? Why not a simple multiply function like in the renderman code language?

surface color = intensity * color * texture

This --> surface color = intensity * color * texture <--- is the multiply mode from photoshop. So he wants a blend function and then he is asking what we need a blend function for ... this is confusing.

I'm pretty sure he just doesn't like the currently implemented blend function. Source * 1-Source blending ( the real name of which escapes me at the moment)

[Thomas An._cg]

Your thoughts on the current TexMap and Color Mults( Blend)

I'm pretty sure he just doesn't like the currently implemented blend function. Source * 1-Source blending ( the real name of which escapes me at the moment)

...And he is proposing the "multiply blend mode" from photoshop ?

Before we go on to the details, maybe we should keep the semantics straight:
In PS there are several choices of blending between layers. One of those blending choices is the "Multiply" mode. The multiply mode is basically RGBfinal=(RGB1*RGB2)/255 [where 1/255 is the normalizing factor)

When Micha proposes (color * texture) this is actually (RGB1*RGB2). So basically he wants the multiply blending mode.

[Micha_cg]

Your thoughts on the current TexMap and Color Mults( Blend)

Thomas, I see two ways. The current blend between a color and the texture - the "blend function method". I don't understand for what we can use it.
The other way is to multiply anything like in renderman. It's easy to understand and the user can control color, brightness and texture color shift.

What do we try to decide here?
1. Is the current implemented blend method useful?
2. If yes, please post some CG related examples.
3. If not, what is better to use? Post CG related examples too.

My opinion, the current function is difficult to understand and not useful. I propose to use the renderman standard of multiplication of color, intensity and texture. Useful for color control, brightness control and color shift of the texture. What do we need more?

For me is the simple multiplication of all components not a blend function, because if the user has set a texture, the user can not blend to the color. Why should he do it?

I think, the most user need a color or a texture. If we use the "new" multiplication method, than we get an extra color shift option.

[Thomas An._cg]

Your thoughts on the current TexMap and Color Mults( Blend)

For me is the simple multiplication of all components not a blend function

Micha, you need to understand that this "multiplication" of yours is also a blend function. Why is this so hard to understand ?

There is nothing more I can do for you on this. If you do not understand that Color*Texture is actually a blend function then there is nothing else I can tell you.