Work in progress.

Post a reply to this message

Attachments:
Download 'test.png' (115 KB)

Preview of image 'test.png'

On 11-9-2016 20:54, clipka wrote:
> Work in progress.
>

So... what's going on exactly?

[hey! right-handed coordinate system] :-)

-- 
Thomas

Post a reply to this message

On 09/11/2016 02:54 PM, clipka wrote:
> Work in progress.
>
:) I believe such a pattern could be very useful!

Bill P.

Post a reply to this message

Am 12.09.2016 um 09:35 schrieb William F Pokorny:
> On 09/11/2016 02:54 PM, clipka wrote:
>> Work in progress.
>>
> :) I believe such a pattern could be very useful!

That's what I thought, too ;)

It'll also work for isosurfaces, although that's probably less exciting
as it's easy to achieve the same effect with a function pattern there.

I had originally pondered the idea of making the mechanism a function,
but shyed away from the challenge of wading through the function virtual
machine stuff. Implementing new patterns is so much easier! It's as if
someone had already refactored the hell out of that portion of the code
;) [pats himself on the back, then clears his throat]

Can't wait for people to put this to use in emissive media!

And thanks to pattern functions it may also be of interest to the
isosurfers.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 09/11/2016 02:54 PM, clipka wrote:
> > Work in progress.
> >
> :) I believe such a pattern could be very useful!
>
> Bill P.

Very very true!

What are the odds of having a similar isosurface potential pattern?

Extending that even further, I'd like to see, or help develop an engineering
toolkit that would include "elements" like triangles, or meshes, with data
fields for things like weight, temperature, tension, torsion, stress-strain,
charge, etc where one could assemble them together, and do some basic Finite
Element Analyses

Very nice work   :)

Post a reply to this message

On 9/12/2016 12:03 PM, clipka wrote:
> Can't wait for people to put this to use in emissive media!

Thanks, just what I need. Another distraction. :)

It opens doors to the imagination.

-- 

Regards
     Stephen

Post a reply to this message

Am 12.09.2016 um 15:22 schrieb Bald Eagle:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 09/11/2016 02:54 PM, clipka wrote:
>>> Work in progress.
>>>
>> :) I believe such a pattern could be very useful!
>>
>> Bill P.
> 
> Very very true!
> 
> What are the odds of having a similar isosurface potential pattern?

Pretty close to an odd integer value ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Pretty close to an odd integer value ;)

Hey - that's a pretty --- real and rational answer.

:D

(I guess I should have read ahead in this thread)   Yay!

Post a reply to this message

Am 11.09.2016 um 20:54 schrieb clipka:
> Work in progress.

... because something I still have to figure out is what output is most
useful:

(A) the raw blob potential,
(B) the difference between blob potential and threshold,
(C) the distance to the blob surface, or
(D) yet some other metric.


(A) would have the advantage that the sum of any such patterns would
behave just like a combo of the underlying blobs.

(B) would have the advantage that the pattern would be less dependent on
the blob's specific settings, always giving a zero value at the blob's
surface.

(C) would be advantageous for obvious reasons.

(D) may provide yet unforeseen other advantages.


For isosurfaces, the decision is a bit simpler, as any metric other than
(A) or (B) would be specific to the function used, so for concistency's
sake I'm currently leaning towards one of these two.

Post a reply to this message

Le 12/09/2016 à 16:53, clipka a écrit :
> Am 11.09.2016 um 20:54 schrieb clipka:
>> Work in progress.
> 
> ... because something I still have to figure out is what output is most
> useful:
> 
> (A) the raw blob potential,
> (B) the difference between blob potential and threshold,
> (C) the distance to the blob surface, or
> (D) yet some other metric.
> 
> 
> (A) would have the advantage that the sum of any such patterns would
> behave just like a combo of the underlying blobs.
> 
> (B) would have the advantage that the pattern would be less dependent on
> the blob's specific settings, always giving a zero value at the blob's
> surface.
> 
> (C) would be advantageous for obvious reasons.
> 
> (D) may provide yet unforeseen other advantages.
> 


Do you normalize or truncate ? (aka, how do you handle entry above 1.0 or below 0.0 in
various ***_map ?)

(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.

(A) is the most invariant: you can change the threshold without worry.

(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

Of course (B) can be applied to (A) and any (D), reversing the effect at the surface
of the blob.

Post a reply to this message

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

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