POV-Ray : Newsgroups : povray.pov4.discussion.general : Ideas. Updated f_wood(). povr branch. Server Time
24 Oct 2021 07:20:35 EDT (-0400)
  Ideas. Updated f_wood(). povr branch. (Message 1 to 10 of 12)  
Goto Latest 10 Messages Next 2 Messages >>>
From: William F Pokorny
Subject: Ideas. Updated f_wood(). povr branch.
Date: 12 Sep 2021 15:42:26
Message: <613e5822$1@news.povray.org>
Roughly a year ago I re-worked the wood pattern and implemented an 
inbuilt function called f_wood() which could mimic it using the same 
basic approach long used for wood. I wasn't very satisfied with the 
result. My thinking was what we really needed was functionality which 
could create growth rings in a more realistic way.

One of the distribution types recently added to f_distribtion() was a 
normal/gaussian. With this in hand, I took another run at an f_wood() 
supporting more realistic growth rings. I left all turbulence and 
displacement to outside actors.

Attached is an image where in the top row the variation is accomplished 
with a random number stream adjusting a nominal ring width for each 
ring. In the second row the random values conform to a normal 
distribution - less often are extreme values seen. The columns represent 
the three return types.

Of note, the color_map for middle and right columns use the blend_mode 3 
feature of v3.8 to get the ring 'steps' to better show.

Bill P.


The documentation text from functions.inc:

Returns 0-1 ramp value within a ring and ring number. Optionally, the 
float portion of the ring number can represent the what fraction of the 
total rings in the tree a particular ring represents.

Values are returned as two 32 bit values encoded in the double space 
where the individual values are accessed via the f_dec2x_f32() function. 
The first 32 bit float is the 0-1 pattern value within the particular 
ring.  The second value is a 32 bit float representing this ring's count 
from the core by the integer portion of the float and optionally a 
[0..1) value representing thisRingCnt/treeRingsCount via the decimal 
portion.

The aim with f_wood is not to mimic the wood pattern, but rather provide 
a function returning growth rings which vary in width, a definable wood 
core and the ring number and fractional position in the wood log. The 
hope is upon this base, more natural algorithmic-ally generated 'wood 
patterns' can be created.

TODO. There are only 6-7 digits of accuracy in that second float! For 
typical ring counts OK, but maybe the user should be able to select the 
second return type?

Example:

#declare Core  = 0.02;
#declare Width = Core/2.0;
#declare Rings = int(((1.0-Core)/Width)+10);
#declare Seed  = 9871.123456;
#declare Mean  = 0.0;  // Used only if type is 1
#declare Sigma = 1/3;  // ditto

#declare Pigm00 = pigment {
     function {
         f_dec2x_f32(
             f_wood(1,f_hypot(x,y),Core,Width,Rings,Seed,Mean,Sigma),
         0)
     }
     color_map {...}
}

Though aimed at creating wood patterns, the function can be used with 
any gradient of values.

Eight parameters required:

1. Type. If 0, a random value stream is used to vary each ring width. If 
1, the random value stream conforms to a more nature like normal 
distribution. Option 1 is slower.

2. Input value. Usually a distance from a center, but any gradient works.

3. The core / starting radius. If positioning wood shapes in the pattern 
away from the core, this can be used to improve performance by skipping 
the ring calculations prior to those needed.

4. The nominal width of each ring in the 'tree log.'

5. The count of the rings in the tree. Used to calculated a stepped 
gradient of each ring from the core to the bark.

6. Seed for random number stream(s). It should be a float other than 0.

7. Mean value of the normal distribution. Used only if the type is 1.

8. Sigma value for the normal distribution. Used only if the type is 1.


Post a reply to this message


Attachments:
Download 'story_f_wood.jpg' (416 KB)

Preview of image 'story_f_wood.jpg'
story_f_wood.jpg


 

From: Alain Martel
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 13 Sep 2021 11:48:00
Message: <613f72b0$1@news.povray.org>
Le 2021-09-12 à 15:42, William F Pokorny a écrit :
> Roughly a year ago I re-worked the wood pattern and implemented an 
> inbuilt function called f_wood() which could mimic it using the same 
> basic approach long used for wood. I wasn't very satisfied with the 
> result. My thinking was what we really needed was functionality which 
> could create growth rings in a more realistic way.
> 
> One of the distribution types recently added to f_distribtion() was a 
> normal/gaussian. With this in hand, I took another run at an f_wood() 
> supporting more realistic growth rings. I left all turbulence and 
> displacement to outside actors.
> 
> Attached is an image where in the top row the variation is accomplished 
> with a random number stream adjusting a nominal ring width for each 
> ring. In the second row the random values conform to a normal 
> distribution - less often are extreme values seen. The columns represent 
> the three return types.
> 
> Of note, the color_map for middle and right columns use the blend_mode 3 
> feature of v3.8 to get the ring 'steps' to better show.
> 
> Bill P.
> 
> 
> The documentation text from functions.inc:
> 
> Returns 0-1 ramp value within a ring and ring number. Optionally, the 
> float portion of the ring number can represent the what fraction of the 
> total rings in the tree a particular ring represents.
> 
> Values are returned as two 32 bit values encoded in the double space 
> where the individual values are accessed via the f_dec2x_f32() function. 
> The first 32 bit float is the 0-1 pattern value within the particular 
> ring.  The second value is a 32 bit float representing this ring's count 
> from the core by the integer portion of the float and optionally a 
> [0..1) value representing thisRingCnt/treeRingsCount via the decimal 
> portion.
> 
> The aim with f_wood is not to mimic the wood pattern, but rather provide 
> a function returning growth rings which vary in width, a definable wood 
> core and the ring number and fractional position in the wood log. The 
> hope is upon this base, more natural algorithmic-ally generated 'wood 
> patterns' can be created.
> 
> TODO. There are only 6-7 digits of accuracy in that second float! For 
> typical ring counts OK, but maybe the user should be able to select the 
> second return type?
> 
> Example:
> 
> #declare Core  = 0.02;
> #declare Width = Core/2.0;
> #declare Rings = int(((1.0-Core)/Width)+10);
> #declare Seed  = 9871.123456;
> #declare Mean  = 0.0;  // Used only if type is 1
> #declare Sigma = 1/3;  // ditto
> 
> #declare Pigm00 = pigment {
>      function {
>          f_dec2x_f32(
>              f_wood(1,f_hypot(x,y),Core,Width,Rings,Seed,Mean,Sigma),
>          0)
>      }
>      color_map {...}
> }
> 
> Though aimed at creating wood patterns, the function can be used with 
> any gradient of values.
> 
> Eight parameters required:
> 
> 1. Type. If 0, a random value stream is used to vary each ring width. If 
> 1, the random value stream conforms to a more nature like normal 
> distribution. Option 1 is slower.
> 
> 2. Input value. Usually a distance from a center, but any gradient works.
> 
> 3. The core / starting radius. If positioning wood shapes in the pattern 
> away from the core, this can be used to improve performance by skipping 
> the ring calculations prior to those needed.
> 
> 4. The nominal width of each ring in the 'tree log.'
> 
> 5. The count of the rings in the tree. Used to calculated a stepped 
> gradient of each ring from the core to the bark.
> 
> 6. Seed for random number stream(s). It should be a float other than 0.
> 
> 7. Mean value of the normal distribution. Used only if the type is 1.
> 
> 8. Sigma value for the normal distribution. Used only if the type is 1.

Very interesting. Mostly useful for wooden objects that are viewed from 
a relatively short distance.

Is there any way to have undisturbed rings in the centre with the 
disturbance increasing as you get farther ?


Post a reply to this message

From: Bald Eagle
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 13 Sep 2021 19:25:00
Message: <web.613fdcdceea58d851f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> One of the distribution types recently added to f_distribtion() was a
> normal/gaussian. With this in hand, I took another run at an f_wood()
> supporting more realistic growth rings. I left all turbulence and
> displacement to outside actors.

This is very cool.   I experimented a bit with the marble pattern to try to get
a more irregular spacing of the veins and a variation in the width.  I'll have
to get back to that once things IRL settle down a bit.

Is it possible to implement this as a function in plain-vanilla SDL, or does it
require some "special sauce"?

Regardless, this is looking great as the basis for some excellent wood patterns.
 Looking forward to seeing this implemented with some black hole warps for the
knots, and a good color map and finish.   :)


Post a reply to this message

From: William F Pokorny
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 14 Sep 2021 09:37:00
Message: <6140a57c$1@news.povray.org>
On 9/13/21 11:47 AM, Alain Martel wrote:
> Very interesting. Mostly useful for wooden objects that are viewed from 
> a relatively short distance.

Thanks. Mostly, Yes. :-)

> Is there any way to have undisturbed rings in the centre with the 
> disturbance increasing as you get farther ?

First, to be clear, the turbulence in the previously posted image was 
accomplished with two 'external' to f_wood() turbulence warps. One for 
fuzz in the rings and another for the log level. The f_wood() function 
doesn't have any inbuilt turbulence - unlike the traditional wood pattern.

In povr certainly a fade is possible, as the Turbulence(1) and vector 
turbulence (DTurbulence) functionality of POV-Ray is brought out as 
inbuilt functions.

If not using that sort of functionality... I think one could probably do 
something like an inward black hole warp(2), apply turbulence, then an 
outward black hole warp. Similar to scaling patterns up (or down) prior 
to applying turbulence and then reversing it.

While, the fade used is the opposite you asked about, attached is a test 
isosurface image based upon f_wood() where I'm using the ring count 
value to fade the rings to nothing in height while moving out from the 
center.

FWIW, the, povr only, core SDL for the isosurface is:

//---
//...
#declare Fn00 = function (x,y,z) {
      f_wood(0,f_hypot(x,z),Core,Width,Rings,Seed,Mean,Sigma)
}
#declare Fn01 = function (v) {
      f_distribution(7,// A triangle distribution. Wikipedia version.
          f_dec2x_f32(v,0),
          A,B,C,ReturnMode,nullArg
      )* ((f_dec2x_f32(v,1)*-0.0035)+0.059) // The fade to nothing.
}
#declare Iso99 = isosurface {
      function { abs(y)-Fn01(Fn00(x,y,z)) }
...
}
//---

Bill P.

(1) - The povr branch has fixed the forever standing Turbulence() 
octaves distribution mean drift issue.

(2) - The povr branch has a black hole type 1 without the clamping 
and/or reaching outside the black hole radius issues of POV-Ray's 
black_hole. The povr type 1 forms would likely be needed for other than 
linear fading / strength 1.


Post a reply to this message


Attachments:
Download 'iso00_f_wood.jpg' (286 KB)

Preview of image 'iso00_f_wood.jpg'
iso00_f_wood.jpg


 

From: William F Pokorny
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 14 Sep 2021 09:40:58
Message: <6140a66a$1@news.povray.org>
On 9/13/21 7:21 PM, Bald Eagle wrote:
> This is very cool.   I experimented a bit with the marble pattern to try to get
> a more irregular spacing of the veins and a variation in the width.  I'll have
> to get back to that once things IRL settle down a bit.
> 
Thanks. Though called f_wood() it can be used with any gradient and so a 
marble if you want.

As you probably know, the marble pattern is just a gradient in x where 
the x position is jostled about by values from calls to Turbulence()(1)

(1) - Which has the distribution drift issue, if not using povr or other 
branches where this is fixed.

> Is it possible to implement this as a function in plain-vanilla SDL, or does it
> require some "special sauce"?

:-) It needs to be inbuilt is the practical answer.

Could you do it in SDL for perhaps patterns only or ,perhaps, as a way 
to pre-bake image maps for later use? Likely yes - but I've not done it.

The whole approach is more expensive than today's wood - especially 
where the random values for the offsets fit a normal distribution. I 
wanted to be able to use it on the fly and with isosurfaces - and for 
that use - inbuilt is the only practical approach I think.

Bill P.


Post a reply to this message

From: jr
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 19 Sep 2021 04:25:00
Message: <web.6146f33feea58d855e0fed26cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Roughly a year ago I re-worked the wood pattern and implemented an
> inbuilt function called f_wood() ...
> The documentation text from functions.inc: ...
> Though aimed at creating wood patterns, the function can be used with
> any gradient of values.
>
> Eight parameters required:

thinking aloud about the simulation, and not having used 'f_wood()' yet, as user
I think I'd like one simple (wrapper) function/macro where, ideally, I'd only
provide an "age" (ie #rings) and some average "annual" growth value to obtain a
pattern, and maybe a rand seed.  (I guess all eight parameters will be needed
when "tuning" some aspect(s) of the render)

unrelated, but I've only found out about two _exciting_ Tcl extensions; thinking
that when 'povr'/POV-Ray compiles, the "library" of backend stuff which is
linked late in the process, I'm fairly certain, could be (mis-)used ;-) with
either of these:
<https://wiki.tcl-lang.org/page/Ffidl>
<https://cffi.magicsplat.com/>


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 19 Sep 2021 06:29:58
Message: <61471126$1@news.povray.org>
On 9/19/21 4:22 AM, jr wrote:
> thinking aloud about the simulation, and not having used 'f_wood()' yet, as user
> I think I'd like one simple (wrapper) function/macro where, ideally, I'd only
> provide an "age" (ie #rings) and some average "annual" growth value to obtain a
> pattern, and maybe a rand seed.  (I guess all eight parameters will be needed
> when "tuning" some aspect(s) of the render)

FYI - I've not published a povr version with f_wood().

Yes, a simpler interface would likely be the more common use case in 
practice. With many of new inbuilt functions, I'm trying out and tuning 
ideas. I want knobs and switches and expect further change

In fact With f_wood been thinking about additional return value pairs... 
Internally, we are always tracking a previous positional sum for ring 
count and the the next sum - so we can do a linear interpolation at the 
value between the two value 'positions.'

My thinking is we can probably create some interesting isosurface 
ladder/net/web like structures by using the leg positions of the ladder 
as seeds and, local to the value, four corner positions. Maybe connect 
up TOK's point to point linear sweeps on the fly.

> 
> unrelated, but I've only found out about two_exciting_  Tcl extensions; thinking
> that when 'povr'/POV-Ray compiles, the "library" of backend stuff which is
> linked late in the process, I'm fairly certain, could be (mis-)used;-)  with
> either of these:
> <https://wiki.tcl-lang.org/page/Ffidl>
> <https://cffi.magicsplat.com/>

Thanks for the pointers. The first rings no bells, but I see from my 
notes I've stumbled across the second site at some point.

I played some - looks like now, way back in 2019 :-| - with:

https://github.com/flightaware/cpptcl

which is based on a much earlier tcl function wrapper package that's 
15-20 years older IIRC. There is too, of course, swig.

With tcl wrappers of C++, I always seem to get as far as a few examples, 
but never much more before I drop the effort for other - less painful - 
play. Someday...

On the practical side, I find I often drop back to to extracting enough 
of the POV-Ray header structure to compile tiny c++ programs when first 
trying bits of code. The compile / link loop is then really quick even 
if I happen to be playing also with the headers. I've got an older two 
core i3. Even with 'make -j4', changed header compiles take a while.

Bill P.


Post a reply to this message

From: jr
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 20 Sep 2021 09:45:00
Message: <web.61488f63eea58d855e0fed26cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> FYI - I've not published a povr version with f_wood().

when will you publish an updated version?  (will '-into' feature?  :-))


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 21 Sep 2021 11:44:11
Message: <6149fdcb$1@news.povray.org>
On 9/20/21 9:40 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> FYI - I've not published a povr version with f_wood().
> 
> when will you publish an updated version?  (will '-into' feature?  :-))
> 

Suppose the answer to that second question, depends some on the answer 
to the first. My best guess is '-into' won't be in the next one, if 
another tarball gets publish relatively soon.

I've been hung up for a while on pushing certain, relatively broad, 
changes I've been playing with over the past few months into the media 
block. How, when - and whether I should go after other media changes 
ahead of next publishing a tar ball.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ideas. Updated f_wood(). povr branch.
Date: 26 Sep 2021 10:21:52
Message: <61508200$1@news.povray.org>
On 9/12/21 3:42 PM, William F Pokorny wrote:
>... I took another run at an f_wood() ...

Attached is an image where I'm starting to play more with the idea of 
the updated f_wood creating patterns/structures not related to tree rings.

I've added two additional return modes, including the sumPrev, sum pair 
one mentioned briefly elsewhere. However, this isosurface is just five 
'z' cylinders and f_wood() applied in four 'z' columns between the 
cylinders so it's not using the two new return modes.

Bill P.


Post a reply to this message


Attachments:
Download 'f_wood_iso3.jpg' (153 KB)

Preview of image 'f_wood_iso3.jpg'
f_wood_iso3.jpg


 

Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.