|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2016 12:01 PM, William F Pokorny wrote:
>
> Forget the filter/transmit getting turned on - though I think there is
> still something off about the shadows with it on.
>
> Wonder if that is unrelated to the potential pattern.
>
Interesting. The effect is unrelated.
When the plane's pigment is set to color rgbft <1,1,1,1,1> and the
background is set to anything but black, an odd inverted shadow shows up
on the transparent plane. Could be used for special effects I guess.
Does make me wonder if "color 1" should be promoted as it apparently is
in the posted code?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.09.2016 um 17:51 schrieb William F Pokorny:
> pigment {
> potential { BLOB | ISOSURFACE }
> [ threshold BOOL ]
> [ PIGMENT_MODIFIERS... ]
> }
>
> Looking just at simple blob so far I see a few things.
>
> 1) Wondering it the option [threshold BOOL] should be inside the
> potential block syntactically?
No; the braces around the BLOB or ISOSURFACE are just around the BLOB or
ISOSURFACE. Strictly speaking, the syntax is
pigment {
potential { BLOB | ISOSURFACE [ OBJECT_MODIFIERS... ] }
[ threshold BOOL ]
[ PIGMENT_MODIFIERS... ]
}
(for reasons only disclosed to Disciples of the Inner Sanctum), and the
only reason the braces are there at all is to unambiguously mark the end
of OBJECT_MODIFIERS, so that there is no ambiguity for statements that
may be both valid OBJECT_MODIFIERS and PIGMENT_MODIFIERS.
There is a long-standing tradition that pattern parameters are placed on
the same hierarchical level as pigment/normal/texture/whatever
modifiers, and `potential` honors this tradition. (Don't be fooled by
the syntax of the `object` pattern, it is the odd one out and should
never have been implemented this way in the first place.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.09.2016 um 18:39 schrieb William F Pokorny:
> When the plane's pigment is set to color rgbft <1,1,1,1,1> and the
> background is set to anything but black, an odd inverted shadow shows up
> on the transparent plane. Could be used for special effects I guess.
Yes, setting colours to any value with finish+transmit>1 may cause quite
unexpected effects. Most notably, the effective opaque component of any
pigment is (rgb)*(1-finish-transmit), so with finish+transmit>1 you get
an effective opaque component that is /negative/.
> Does make me wonder if "color 1" should be promoted as it apparently is
> in the posted code?
Presuming that 3.7 reacts in the same manner, I'd say it should trigger
a warning.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2016 12:49 PM, clipka wrote:
> Am 13.09.2016 um 17:51 schrieb William F Pokorny:
>
>> pigment {
>> potential { BLOB | ISOSURFACE }
>> [ threshold BOOL ]
>> [ PIGMENT_MODIFIERS... ]
>> }
>>
>> Looking just at simple blob so far I see a few things.
>>
>> 1) Wondering it the option [threshold BOOL] should be inside the
>> potential block syntactically?
>
> No; the braces around the BLOB or ISOSURFACE are just around the BLOB or
> ISOSURFACE. Strictly speaking, the syntax is
>
> pigment {
> potential { BLOB | ISOSURFACE [ OBJECT_MODIFIERS... ] }
> [ threshold BOOL ]
> [ PIGMENT_MODIFIERS... ]
> }
>
> (for reasons only disclosed to Disciples of the Inner Sanctum), and the
> only reason the braces are there at all is to unambiguously mark the end
> of OBJECT_MODIFIERS, so that there is no ambiguity for statements that
> may be both valid OBJECT_MODIFIERS and PIGMENT_MODIFIERS.
>
> There is a long-standing tradition that pattern parameters are placed on
> the same hierarchical level as pigment/normal/texture/whatever
> modifiers, and `potential` honors this tradition. (Don't be fooled by
> the syntax of the `object` pattern, it is the odd one out and should
> never have been implemented this way in the first place.)
>
OK. Thanks.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2016 01:00 PM, clipka wrote:
> Am 13.09.2016 um 18:39 schrieb William F Pokorny:
>
>> When the plane's pigment is set to color rgbft <1,1,1,1,1> and the
>> background is set to anything but black, an odd inverted shadow shows up
>> on the transparent plane. Could be used for special effects I guess.
>
> Yes, setting colours to any value with finish+transmit>1 may cause quite
> unexpected effects. Most notably, the effective opaque component of any
> pigment is (rgb)*(1-finish-transmit), so with finish+transmit>1 you get
> an effective opaque component that is /negative/.
>
>> Does make me wonder if "color 1" should be promoted as it apparently is
>> in the posted code?
>
> Presuming that 3.7 reacts in the same manner, I'd say it should trigger
> a warning.
>
I checked and it does behave in the same way in 3.7.
I almost always specify the full rgbft or srgbft qualifier and values to
not get tangled up.
I got lazy here - and I had it in my head that "color 1" promoted only
to a 3 value vector. It indeed promotes to 5.
To be sure - we are adding the warning on the promotion of color
specified as a single float value >0 getting promoted to a 5 value
vector? If so, suppose this likely work at a skill level I could go
after if you want?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.09.2016 um 19:14 schrieb William F Pokorny:
> To be sure - we are adding the warning on the promotion of color
> specified as a single float value >0 getting promoted to a 5 value
> vector? If so, suppose this likely work at a skill level I could go
> after if you want?
You might give it a try.
Must be in the parser... /somewhere/. Keep your eyes peeled for a piece
of code that has "COLOUR_TOKEN" in it, probably along with "RGB_TOKEN",
"RGBF_TOKEN", "RGBFT_TOKEN", and the whole lot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2016 01:57 PM, clipka wrote:
> Am 13.09.2016 um 19:14 schrieb William F Pokorny:
>
>> To be sure - we are adding the warning on the promotion of color
>> specified as a single float value >0 getting promoted to a 5 value
>> vector? If so, suppose this likely work at a skill level I could go
>> after if you want?
>
> You might give it a try.
> Must be in the parser... /somewhere/. Keep your eyes peeled for a piece
> of code that has "COLOUR_TOKEN" in it, probably along with "RGB_TOKEN",
> "RGBF_TOKEN", "RGBFT_TOKEN", and the whole lot.
>
Think I got it. Please see pull request #91.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/12/2016 04:14 PM, clipka wrote:
> Am 11.09.2016 um 20:54 schrieb clipka:
>> Work in progress.
>
> Source code available now here:
>
> https://github.com/c-lipka/povray/tree/feature/potential_pattern
>
> Integration into POV-Ray proper to follow later.
>
Been playing a bit more. Potential {Blob} with densities and normals
works. An Isosurface as the pattern for a pigment_map.
The isosurface flavor is for me working pretty much as a path to the
isosurface function. Contained_by_box not having any effect that I can
see - meaning the container doesn't cut off the result from the function.
Perhaps how I've coded, but also seeing no effect from the new polarity
option of isosurface or the threshold on/off option of the potential
pattern. Not looked at the code as yet.
With media I tried a multi component blob as both the container and what
was defining the density - really fast with emitting media. Should make
for a good "glows" feature among other uses.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/14/2016 08:00 AM, William F Pokorny wrote:
> On 09/12/2016 04:14 PM, clipka wrote:
>> Am 11.09.2016 um 20:54 schrieb clipka:
>>> Work in progress.
>>
>> Source code available now here:
>>
>> https://github.com/c-lipka/povray/tree/feature/potential_pattern
>>
>> Integration into POV-Ray proper to follow later.
>>
>
> Been playing a bit more. Potential {Blob} with densities and normals
> works. An Isosurface as the pattern for a pigment_map.
>
> The isosurface flavor is for me working pretty much as a path to the
> isosurface function. Contained_by_box not having any effect that I can
> see - meaning the container doesn't cut off the result from the function.
>
> Perhaps how I've coded, but also seeing no effect from the new polarity
> option of isosurface or the threshold on/off option of the potential
> pattern. Not looked at the code as yet.
>
> With media I tried a multi component blob as both the container and what
> was defining the density - really fast with emitting media. Should make
> for a good "glows" feature among other uses.
>
> Bill P.
Please see comment to pull request #88. I think I figured out why
threshold isn't working. More info there.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.09.2016 um 13:00 schrieb William F Pokorny:
> Please see comment to pull request #88. I think I figured out why
> threshold isn't working. More info there.
Nailed it. Thanks for the support.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |