I debated for a long while on whether to keep the marble pattern in yuqk 
given the base pattern is just 'gradient x' with a 'triangle_wave' value 
modifier.

For the record I suppose. I decided, given the new to yuqk internal 
turbulence (_it) keyword support, it was worthwhile to keep around. Many 
of us use marble too in old scenes as quick texturing.

In the attached image the basic pattern in the upper left.

In the upper right adding 'it_frequency 1/3'

In the lower left adding 'it_frequency 1/3' and 'it_scale 3'

In the lower right adding 'it_frequency 1/3' and 'it_scale 1/3'

---

Note! I missed adding the it_scale support to 'marble', 'spiral1' and 
'spiral2' when the general scaling capability was added to the internal 
Turbulence() code. The 'it_scale' above is a parse error with marble 
until the next yuqk release (R17).

Reminder. The patterns 'agate', 'marble','spiral1', 'spiral2' and 'wood' 
are touched by the (noise centering drift on omega values) issue fixed 
now a long while ago in the yuqk fork.

Bill P.

Post a reply to this message

Attachments:
Download 'marbleupdtstory.png' (308 KB)

Preview of image 'marbleupdtstory.png'

William F Pokorny <ano### [at] anonymousorg> wrote:
> I debated for a long while on whether to keep the marble pattern in yuqk
> given the base pattern is just 'gradient x' with a 'triangle_wave' value
> modifier.

FYI:
I noticed in the comments for the crackle source:
"// Highly turbulent (with moderate displacement) makes a good marble, solving
// the problem of apparent parallel layers in Perlin's method. (The perlin
// method being the noise generator used with POV-Ray's 'turbulence'
// implementations)"

I don't know if anyone's tried this out yet and compared it to our current
"marble".

tl;dr

It would be great if people could pick a simple pattern/texture and really flesh
it out like TdG with the granite pattern, and I made some headway on with
Marschner's wood texture.

Yes, the danger is that those would be the default and become "overused", but at
the same time, people wouldn't have to be left to ascend the learning curve and
code 397 lines of fundamental computer graphics to get something that looks
better than the usual newbie/lazy 5 lines of "marble".
Just #include "v40textures.inc" or something . . .

- BW

Post a reply to this message

On 11/14/24 09:33, Bald Eagle wrote:
> FYI:
> I noticed in the comments for the crackle source:

The comments in the code ahead of the crackle code itself come from the 
original authors. I found them interesting - and like you, I wondered if 
some were still true.

A few weeks ago I played with the idea of using crackle as base for a 
wood texture. It was just a quick test, but see the attached image. 
Aimed for pine, but ended up with something more like tulip poplar I 
think. :-) The code used is simple and I believe it would work with the 
crackle in official releases of POV-Ray too.

     plane { -z 0
         pigment {
             crackle
             ip_solid
             color_map {
                 [0.0 AppleBlossom ]
                 [0.2 AppleGreen  ]
                 [0.4 AppleGreen1 ]
                 [0.6 AppleGreen2 ]
                 [0.8 AppleGreen3 ]
                 [0.9 AppleGreen4 ]
                 [0.90 rgb 0 ]
                 [1.00 rgb 0 ]
             }
             scale <1,1/12666.6667,1>
             rotate z*33.333
         }
         finish { emission 1 }
     }

> Just #include "v40textures.inc" or something . . .

I agree with your aim.

I believe POV-Ray has long been self-hindered with respect to developing 
good libraries of textures. Too many features on which textures / 
materials are based behave in unstable ways. Much of my effort with the 
yuqk fork has been to tune up the old core of code; To make existing 
features more stable and more flexible (You've helped - 'quilted' and 
'radial', for example). I'm still on that tune up bit...

Bill P.

Post a reply to this message

Attachments:
Download 'crackle_plainsolid_grain.jpg' (122 KB)

Preview of image 'crackle_plainsolid_grain.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:

> A few weeks ago I played with the idea of using crackle as base for a
> wood texture. It was just a quick test, but see the attached image.
> Aimed for pine, but ended up with something more like tulip poplar I
> think. :-) The code used is simple and I believe it would work with the
> crackle in official releases of POV-Ray too.

Now that _is_ interesting!
When I have the opportunity and energy, I ought to try incorporating that into
Marschner's wood texture and see if that improves things.

I'll bet this would also look great if rendered with SSLT.
You'd probably have to use actual displacement mapping - maybe with a
heightfield or isosurface to get the variations in geometry and thickness.

> I believe POV-Ray has long been self-hindered with respect to developing
> good libraries of textures. Too many features on which textures /
> materials are based behave in unstable ways. Much of my effort with the
> yuqk fork has been to tune up the old core of code; To make existing
> features more stable and more flexible (You've helped - 'quilted' and
> 'radial', for example). I'm still on that tune up bit...

Well, we have a lot of basic patterns that serve as the basis of actual textures
- given the proper inclusion and setting of a wide variety of (incompletely
understood) switches and knobs.

I think that the approach that Thomas took - generating a proper, fully-formed
texture with a macro is a very promising approach.

Certainly a lot of often-encountered inefficiencies and errors could be avoided
if we had some macros to handle sanity checking and the proper implementation of
feature settings for all those fun things like radiosity, floating point math,
etc.

- BW

Post a reply to this message

On 11/15/24 10:40, Bald Eagle wrote:
> I'll bet this would also look great if rendered with SSLT.
> You'd probably have to use actual displacement mapping - maybe with a
> heightfield or isosurface to get the variations in geometry and thickness.

SSLT - maybe I'll give it a go. My todo list always grows longer when I 
interact with you... :-)

SSLT is one of those features still on yuqk's 'not sure what to do with 
it' list. There are issues. Not the least of which is the feature was 
never really polished off in the code. On other than simple geometries 
I've found it a little funky to use - this could be me not understanding 
it well. It's slow on my little i3, so it's hard for me to experiment.

The yuqk fork's solver fixes / improvements help its behavior quite a 
bit. I was able to pull out some hacks specifically for the feature in 
the blob code, for example.

I don't know... Down my list a ways. It's relatively complicated code. 
Uses too a boost feature I've not seen elsewhere. Anyhow...

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> SSLT - maybe I'll give it a go. My todo list always grows longer when I
> interact with you... :-)

:D   My to do list gets longer when I finally get some time to myself and I can
think about all the things that I have to or want to do.

I think that implementing a more collaborative approach to scenes might help
people like us (too busy + too many ideas) make progress and complete more
scenes / experiments.  The old coding circles and code pong type stuff.

"Here's my basic / incomplete scene, here's what I want to do, here's what I
have, and this is what still needs coding / developing / fixing."

A scene can be made very modular using include files, #switch/case blocks,
macros, etc.
Unimplemented parts of the scene can just have placeholders that can be edited
as the scene develops.
It's easy enough to paste links to POV-Rayfeatures, images on the web, code that
needs to get translated to SDL, etc. into the scene as comments.

Then anyone at any time can pick it up and run with it, and then post how far
they've gotten.

Because we all know that sometime the difference between complete poop and a
great looking working scene can be editing a single line of code, changing a
single value, or just implementing one feature that makes it WORK.


> SSLT is one of those features still on yuqk's 'not sure what to do with
> it' list. There are issues. Not the least of which is the feature was
> never really polished off in the code. On other than simple geometries
> I've found it a little funky to use - this could be me not understanding
> it well. It's slow on my little i3, so it's hard for me to experiment.

Yes, as I recall, it was complicated to merely implement in a scene as well.
TdG managed to get it to work fairly well in the granite texture - maybe you can
just steal a block of code from there and see what you can get to work.

Or post your crackle-wood code, with specific ideas to convert it to geometry,
and someone can work that out and apply the SSLT if they have the time and
nothing specific of their own to work on.

- BW

Post a reply to this message