 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.09.2016 um 19:17 schrieb Le_Forgeron:
> Do you normalize or truncate ? (aka, how do you handle entry above 1.0 or below 0.0
in various ***_map ?)
(You have to do something about your newsreader; those unbroken lines
keep bothering me again and again when quoting from your posts.)
The pattern does not perform any truncation /per se/, but this can be
overridden by using the `wave_type` keyword.
(Under the hood, this uses a new wave_type that bypasses all truncation;
I intend to review the existing patterns and see if they can be
refactored to allow such a behaviour as well, in which case I'll make
the wave type accessible to the user, maybe along with one or more other
non-repeating wave types.)
> (C) looks simple but are you sure you can get the smallest distance ?
> especially when the strength and radius are different between components, and there
is negative strength in the equation.
> I would not expect (C). It seems easy but fails as soon as there is a negative
strength in the blob, something you cannot forbid.
You may be right: The falloff rate may differ between blob elements.
Another reason to scratch that idea.
> (D) :
> 1. recently, the product of the two max was considered (for something totally
different: bevelled and junctions)
> 2. what about the Max() of contribution (instead of L_1 (sum), it would be another
traditional metric (L_infinity metric IIRC)
> 3. and of course, we could look at L_2 (sqrt(sum(square of contribution))), aka
Euclidian distance. Can be funny or interesting with negative contribution
Those suggestions are all about interaction between two potential
fields, and would thus either constitute change requests for the
behaviour of blobs themselves (interaction of their elements' fields),
or for whatever mechanism would be used to combine two patterns of this
type. Either way they are outside the scope of the pattern.
I've decided to go for both (A) and (B) now, using a boolean setting to
choose between the two.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/16 18:57, clipka wrote:
> (You have to do something about your newsreader; those unbroken lines
> keep bothering me again and again when quoting from your posts.)
>
Le_F, I suspect you know how to do this, but just in case:
There is a line length set by default to 72 characters in about:config.
mailnews.wraplength = 72. This may have been changed. Try resetting it
John
--
It's not about bravery.
It's about doing what I need to do to win
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Syntax for the new pattern is as follows (using pigment as an example):
pigment {
potential { BLOB | ISOSURFACE }
[ threshold BOOL ]
[ PIGMENT_MODIFIERS... ]
}
With `threshold` set to `on`, the pattern will take the blob or
isosurface object's potential minus the threshold; otherwise it will
take the raw potential (the default).
The pattern value is _not_ bound to the [0..1] range (unless you
explicitly specify a `wave_type`).
Applying the "inverse" keyword to the object will cause the pattern to
be reversed as well; thus, when using `threshold on`, for blobs positive
pattern values always indicate inside, while negative values indicate
outside.
Note that by default this is just the other way round for isosurfaces
(which had annoyed me multiple times already); for easier use, the new
pattern is therefore accompanied by an extension to the isosurface syntax:
isosurface {
...
polarity FLOAT
...
}
Setting `polarity` to a positive value causes above-threshold values to
be interpreted as inside, and below-threshold values as outside, rather
than the other way round.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 12/09/2016 à 22:14, clipka a écrit :
>
> Note that by default this is just the other way round for isosurfaces
> (which had annoyed me multiple times already); for easier use, the new
> pattern is therefore accompanied by an extension to the isosurface syntax:
>
> isosurface {
> ...
> polarity FLOAT
> ...
> }
>
> Setting `polarity` to a positive value causes above-threshold values to
> be interpreted as inside, and below-threshold values as outside, rather
> than the other way round.
what would be the difference with "inverse" ?
(just not reinventing the wheel ?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.09.2016 um 22:42 schrieb Le_Forgeron:
> Le 12/09/2016 à 22:14, clipka a écrit :
>>
>> Note that by default this is just the other way round for isosurfaces
>> (which had annoyed me multiple times already); for easier use, the new
>> pattern is therefore accompanied by an extension to the isosurface syntax:
>>
>> isosurface {
>> ...
>> polarity FLOAT
>> ...
>> }
>>
>> Setting `polarity` to a positive value causes above-threshold values to
>> be interpreted as inside, and below-threshold values as outside, rather
>> than the other way round.
>
> what would be the difference with "inverse" ?
> (just not reinventing the wheel ?)
`inverse` flips the inside and outside of the isosurface "worldwide".
"polarity 1" flips the inside and outside of the isosurface only within
the bounds of the contained_by object. The outside of that object still
remains outside.
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.
>
>
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?
1a) I could not seem to get the threshold option to function.
2) See attached image. I think the potential value is turning on filter
and/or transmit as the value approaches 1.0. We should not be able to
see the green y axis below the plane.
3) See attached image. Something odd is going on with the shadows cast
over the >0 blob potential areas - and where the strength is set to 1
especially.
Bill P.
Post a reply to this message
Attachments:
Download 'potentialaspigment.png' (90 KB)
Download 'potentialaspigment.pov.txt' (2 KB)
Preview of image 'potentialaspigment.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2016 11:51 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.
>>
>>
>
> 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?
>
> 1a) I could not seem to get the threshold option to function.
>
> 2) See attached image. I think the potential value is turning on filter
> and/or transmit as the value approaches 1.0. We should not be able to
> see the green y axis below the plane.
>
> 3) See attached image. Something odd is going on with the shadows cast
> over the >0 blob potential areas - and where the strength is set to 1
> especially.
>
> Bill P.
Of course I only think "Did I specify a color_map instead of default?"
after I hit send... I did, blast it.
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.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.09.2016 um 18:01 schrieb William F Pokorny:
> 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.
Most certainly so. The potential pattern is entirely agnostic of
everything else in the scene; all it cares about is the blob or
isosurface, and that it has to supply one particular value for any given
point in space.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
