This message is a bit technical, so I'm putting it in .programming.
=========

First, I think it should go within the texture, not the interior.  Kind
of a decoupling of color(colour) and transparency.

One forumla that could be used for general transparancy is:

Result_Colur[red] = 
  Pigment_Colour[red] * w1[red]  <op> Colour_Behind_Object[red] * w2[red];

(same formula for green, blue)

<op> is the operator that combines the two (like +, -, *)

Transmit is:
  w1[red] = w1[green] = w1[blue] = 1.0 - Transmit_Value;
  w2[red] = w2[green] = w2[blue] = Transmit_Value;
  <op> = +

Filter is:
  w1[red] = w1[green] = w1[blue] = 1.0 - Filter_Value;
  w2[red]   = Filter_Value * Pigment_Colour[red];
  w2[green] = Filter_Value * Pigment_Colour[green];
  w2[blue]  = Filter_Value * Pigment_Colour[blue];

Of course, other formulas could be used for other effects (dodge, burn,
darken, lighten, etc.)  Notice that with this you have two weights
in the combination formula, which makes the 'amount of transparence'
somewhat ambiguous.  What does 100% additive transparance mean?
What about 0% additive?

I guess for additive/subtractive you could just use:
  w1[red] = w1[green] = w1[blue] = 1.0;
  w2[red] = w2[green] = w2[blue] = Transparence_Value;

For Multiplicitve you might want:
  w1[red] = w1[green] = w1[blue] = 1.0;
  w2[red] = 1.0 / (1.0-Colour_Behind_Object[red])*Transparence_Value+
                   Colour_Behind_Object[red])

  At Transparence_Value = 0, you get
    w1[] = 1,  w2[] = Colour_Behind_Object[],
    therefore ResultColour[] = Pigment_Colour[red];

  At Transparence_Value = 0, you get
    w1[] = 1,  w2[] = 1.0,
    therefore ResultColour[] = Pigment_Colour[]*Colour_Behind_Object[];

Does this make any sense?  Is there a better way to generalize this for
easier use.  There will probably have to be some compromises in how
general it is in order to make it less overwhelming.  Or have some good
defaults with the ability to change them if you so desire.

-Nathan

Post a reply to this message

Is this not similar to 'rgbft' as it is already? (sorry, I had to ask
that :)
You're last example apparently needs the 0 replaced with a 1 (am I
right?)

>   At Transparence_Value = 0, you get    // = 1  instead?
>     w1[] = 1,  w2[] = 1.0,
>     therefore ResultColour[] = pigment_Colour[]*Colour_Behind_Object[];

Anyhow, I'm just a curious onlooker, not much on the technical aspects
of POV-Ray.
I get what you are trying to do though, sort of a mathematical rgb,
however my first question actually should be asked I guess. Using math
on the color vector isn't new, but I can see where this would be a help
in defining the various attributes for ease of manipulation on the
transparency.
Hope someone else here understands it so they can help.


Nathan Kopp wrote:
> 
> This message is a bit technical, so I'm putting it in .programming.
> =========
> 
> First, I think it should go within the texture, not the interior.  Kind
> of a decoupling of color(colour) and transparency.
> 
> One forumla that could be used for general transparancy is:
> 
> Result_Colur[red] =
>   Pigment_Colour[red] * w1[red]  <op> Colour_Behind_Object[red] * w2[red];
> 
> (same formula for green, blue)
> 
> <op> is the operator that combines the two (like +, -, *)
> 
> Transmit is:
>   w1[red] = w1[green] = w1[blue] = 1.0 - Transmit_Value;
>   w2[red] = w2[green] = w2[blue] = Transmit_Value;
>   <op> = +
> 
> Filter is:
>   w1[red] = w1[green] = w1[blue] = 1.0 - Filter_Value;
>   w2[red]   = Filter_Value * Pigment_Colour[red];
>   w2[green] = Filter_Value * Pigment_Colour[green];
>   w2[blue]  = Filter_Value * Pigment_Colour[blue];
> 
> Of course, other formulas could be used for other effects (dodge, burn,
> darken, lighten, etc.)  Notice that with this you have two weights
> in the combination formula, which makes the 'amount of transparence'
> somewhat ambiguous.  What does 100% additive transparance mean?
> What about 0% additive?
> 
> I guess for additive/subtractive you could just use:
>   w1[red] = w1[green] = w1[blue] = 1.0;
>   w2[red] = w2[green] = w2[blue] = Transparence_Value;
> 
> For Multiplicitve you might want:
>   w1[red] = w1[green] = w1[blue] = 1.0;
>   w2[red] = 1.0 / (1.0-Colour_Behind_Object[red])*Transparence_Value+
>                    Colour_Behind_Object[red])
> 
>   At Transparence_Value = 0, you get
>     w1[] = 1,  w2[] = Colour_Behind_Object[],
>     therefore ResultColour[] = Pigment_Colour[red];
> 
>   At Transparence_Value = 0, you get
>     w1[] = 1,  w2[] = 1.0,
>     therefore ResultColour[] = Pigment_Colour[]*Colour_Behind_Object[];
> 
> Does this make any sense?  Is there a better way to generalize this for
> easier use.  There will probably have to be some compromises in how
> general it is in order to make it less overwhelming.  Or have some good
> defaults with the ability to change them if you so desire.
> 
> -Nathan

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

Yes, it should definitely be put in texture, otherwise we couldn't have
layered textures using this feature! It shouldn't go in pigment, because
it can have a pigment, and that might get messy. Maybe finish...

Anyway, I a pattern would be used for the parameters(a normal POV-Ray
pattern gives a value from 0-1 depending on location, and other ranges
could be used with the isosurface functions.) If an effect requires more
than one value, just allow more than one pattern-parameter. This is the
reason for my suggestion of a "solid" pattern, which takes a float
argument which is the return value of the pattern.
(I think this method would be useful for a couple other things as well,
reflection is one of them.)

Post a reply to this message

On Tue, 13 Jul 1999 18:59:27 -0500, Chris Huff
<Chr### [at] compuservecom> wrote:

>a normal POV-Ray
>pattern gives a value from 0-1 depending on location

I guess that means bozo and crackle aren't normal, then. :)

Post a reply to this message

Bob Hughes wrote:
> 
> Is this not similar to 'rgbft' as it is already? (sorry, I had to ask
> that :)

This would give a bit more flexibility, since you could, for example, have
a bozo color pattern (pigment) but use a gradient for the transparancy.  As
I mentioned before, this could be done with a pigment_map.

The main strength is that this allows more possibilities in terms of other
ways of combining color.  Paint programs (like Photoshop or PSP) provide
many ways of combining layers together.  It would not be too difficult to
provide those same features here in POV.

> You're last example apparently needs the 0 replaced with a 1 (am I
> right?)
> 
> >   At Transparence_Value = 0, you get    // = 1  instead?
> >     w1[] = 1,  w2[] = 1.0,
> >     therefore ResultColour[] = pigment_Colour[]*Colour_Behind_Object[];

You're correct.  That is what I meant to type.

-Natahn

Post a reply to this message

Nathan Kopp wrote:

> ways of combining color.  Paint programs (like Photoshop or PSP) provide
> many ways of combining layers together.  It would not be too difficult to

That is just what I thought when I saw your yesterday's
posting, but hesitated to answer. GIMP has a dozen or so
ways of combining layers, and they are documented together
with their formulas in the manual.

In addition, this would be more close to the physical
behavior of semitransparent layers, making the creation
of layered textures less counterintuitive than it is now.

An other way would to allow the user to enter his own
formulas (IIRC they can all be built from "+","*","1",
"0","min"). Since povray has already a parser, this should
not be extremely hard to implement.

Ralf

Post a reply to this message

The isosurface patch includes functions like that, which can be used for
objects or patterns, I don't know why I didn't think of them for the
actual calculation.

Post a reply to this message

I think it would be a good idea to decide exactly what the syntax would
mean. One method would allow multiple effects of a kind(one or more
additive, multiplicative, etc) which would allow quite complex
transparence qualities. The other would probably be a lot simpler to
implement, it would treat each effect as a single attribute of
transparency, however, this would be much more limited in it's
possibilities.
Also, does each effect work on the pigment color(texture pigment or
transparence pigment) or the value calculated up to that time? If each
effect works on the pigment color, how are the results of each effect
combined into one?

Post a reply to this message

Also, I had been thinking of each effect as a parameter like phong_size
NUMBER, maybe a syntax like:
additive {ADDITIVE_PATTERN}
would be better. It would make effects which use multiple parameters
clearer(pun not intended) and would make more sense for multiple effects
of a kind.

Post a reply to this message

Yes, but compared to built-in functions, these are very slow (as should
be expected).  All of the most-used features should be built in, but I
agree that it would be nice if the user could specify their own formula
if they don't mind the slowness.

-Nathan

Chris Huff wrote:
> 
> The isosurface patch includes functions like that, which can be used for
> objects or patterns, I don't know why I didn't think of them for the
> actual calculation.

Post a reply to this message