 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
|
|
