Op 4-6-2021 om 12:20 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> ...but seriously, I would be interested to know how to use voronoi
>> diagrams for this particular project, apart from the crackles pattern.
>> Something where the individual cells (and distribution of them) would be
>> more "controlled" by the user. Beyond the "using voronoi without knowing
>> it", that would completely change the whole granite setup I think.
> 
> Correct, and there has been some interest in exactly that for quite some time.
> 
> I have 2 or 3 implementations of Voronoi algorithms coded in GLSL/Shadertoy that
> I've been meaning to start converting to SDL, in the hopes that I could get
> something reasonably functional.
> 
I did a bit of browsing about voronoi diagrams, in particular MathWorks, 
and it occurred to me (just thinking aloud here) that if we could 
generate a 3d voronoi volume based on a random set of points in an 
array, that volume - intersected by the object we want to texture with 
granite - would give a 2d voronoi granite pattern. At least, that was 
how I interpreted the info given in MathWorks, which somehow seemed to 
click right away with those papers you directed me to.

Perhaps, we do not even need a 3d volume at all, but it seems to me that 
it would be a better, or more "natural", approach to the problem.

> 
> 
> I didn't get to spend ANY POV-time yesterday, but I was thinking about exactly
> what you're talking about, and it occurred to me that one thing we could
> probably do is plug crackle into a function and then operate on the function
> coordinates - like I did with the vortex.  That would give spatial control.
> 
> Then the whole bricks pattern trick would give further control over the
> coloring.
> 
That is an interesting idea... we should certainly follow up that line 
to see where it would get us.

> And, of course Jerome Grimbert has already addressed this in hgpovray38
> https://wiki.povray.org/content/User:Le_Forgeron#voronoi
> 
Ok. I need to look at that.

> I mean, even for now, we could probably just add some gentle black hole warps or
> other warps to the basic granite pattern and introduce a little bit of
> variation.  I'm bad at implementing warps, but maybe the quartz veins could
> benefit from some clever application of them.
> 
Maybe. I am not sure what the black hole warp would really add to the 
turbulence warp already in place. Granites are not very turbulent by 
themselves and rather monotonous in fact.

>> At
>> this moment, beyond the beta and beyond the final version.
> 
> Yes, just looking at the POV-Ray source code for the crackle and other
> voronoi-based pattern shows it to be a little complex, and IIRC, the problem was
> really that it's one of those things that you can do fairly straightforwardly
> with an algorithm when directly shading pixels, but would be difficult or
> impossible to do with straight SDL functions.
> 
> https://thebookofshaders.com/12/
> https://iquilezles.org/www/articles/voronoilines/voronoilines.htm
> https://iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
> https://iquilezles.org/www/articles/voronoise/voronoise.htm
> 
Well, it appears we shall not have time to get bored or idle. ;-)

In the meantime, I have started to write that piece of documentation you 
asked about. Steadily growing.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> That is an interesting idea... we should certainly follow up that line
> to see where it would get us.

We should - but I never really dug into that really great project deeply enough
to understand exactly how it all works.  Maybe it's time.


> > I mean, even for now, we could probably just add some gentle black hole warps or
> > other warps to the basic granite pattern and introduce a little bit of
> > variation.  I'm bad at implementing warps, but maybe the quartz veins could
> > benefit from some clever application of them.
> >
> Maybe. I am not sure what the black hole warp would really add to the
> turbulence warp already in place. Granites are not very turbulent by
> themselves and rather monotonous in fact.

They are, but you have those other patterns which have some size variation.  It
might be nice to have some of that in the pattern as an option.  I'm only
throwing it out there so we can play with it and either decide it has promise -
or discard it as "nope - not a good idea".

> Well, it appears we shall not have time to get bored or idle. ;-)

Always so much to do.   Never enough time, energy, or opportunity.   Better that
than being idle and boring.


> In the meantime, I have started to write that piece of documentation you
> asked about. Steadily growing.

Thanks  :)


Find attached a quick exploratory crackle experiment.  The sum of 2 crackle
patterns of different scales, one with turbulence, then the whole thing with
some turbulence.

Post a reply to this message

Attachments:
Download 'cracklefunction.png' (877 KB)

Preview of image 'cracklefunction.png'

Op 04/06/2021 om 22:08 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> That is an interesting idea... we should certainly follow up that line
>> to see where it would get us.
> 
> We should - but I never really dug into that really great project deeply enough
> to understand exactly how it all works.  Maybe it's time.
> 
I have to dig up my old Geomorph code (2004-2005) in which I used 
patterns (including crackle) in different functions to build isosurface 
landscapes. It might inspire...

> 
>>> I mean, even for now, we could probably just add some gentle black hole warps or
>>> other warps to the basic granite pattern and introduce a little bit of
>>> variation.  I'm bad at implementing warps, but maybe the quartz veins could
>>> benefit from some clever application of them.
>>>
>> Maybe. I am not sure what the black hole warp would really add to the
>> turbulence warp already in place. Granites are not very turbulent by
>> themselves and rather monotonous in fact.
> 
> They are, but you have those other patterns which have some size variation.  It
> might be nice to have some of that in the pattern as an option.  I'm only
> throwing it out there so we can play with it and either decide it has promise -
> or discard it as "nope - not a good idea".
> 
I fully agree.

>> Well, it appears we shall not have time to get bored or idle. ;-)
> 
> Always so much to do.   Never enough time, energy, or opportunity.   Better that
> than being idle and boring.
> 
> 
>> In the meantime, I have started to write that piece of documentation you
>> asked about. Steadily growing.
> 
> Thanks  :)
> 
> 
> Find attached a quick exploratory crackle experiment.  The sum of 2 crackle
> patterns of different scales, one with turbulence, then the whole thing with
> some turbulence.
> 
Interesting result indeed. The "cells" are not looking "natural" enough 
to my taste, but with enough tweaking...

It shows, imo, how we have to be careful with the amount of turbulence.


-- 
Thomas

Post a reply to this message

> Op 04/06/2021 om 22:08 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> That is an interesting idea... we should certainly follow up that line
>>> to see where it would get us.
>>
>> We should - but I never really dug into that really great project 
>> deeply enough

>>
> I have to dig up my old Geomorph code (2004-2005) in which I used 
> patterns (including crackle) in different functions to build isosurface 
> landscapes. It might inspire...
> 
>>
>>>> I mean, even for now, we could probably just add some gentle black 
>>>> hole warps or
>>>> other warps to the basic granite pattern and introduce a little bit of

>>>> veins could
>>>> benefit from some clever application of them.
>>>>
>>> Maybe. I am not sure what the black hole warp would really add to the
>>> turbulence warp already in place. Granites are not very turbulent by
>>> themselves and rather monotonous in fact.
>>
>> They are, but you have those other patterns which have some size 


>> throwing it out there so we can play with it and either decide it has 
>> promise -
>> or discard it as "nope - not a good idea".
>>
> I fully agree.
> 
>>> Well, it appears we shall not have time to get bored or idle. ;-)
>>

>> Better that
>> than being idle and boring.
>>
>>
>>> In the meantime, I have started to write that piece of documentation you
>>> asked about. Steadily growing.
>>

>>
>>

>> crackle
>> patterns of different scales, one with turbulence, then the whole 
>> thing with
>> some turbulence.
>>
> Interesting result indeed. The "cells" are not looking "natural" enough 
> to my taste, but with enough tweaking...
> 
> It shows, imo, how we have to be careful with the amount of turbulence.
> 
> 
To make your turbulence smoother, reducing the octave parameter could 
help. It default at 6. So, maybe try with octave 3.

Next, you can also reduce the lambda. Default of 2. Make it closer to 1.

Finally, the omega could also get adjusted down from the default of 0.5.

A proposition :
octave 3
lambda 1.4
omega 0.25

This should make the turbulence much more wavy and smoother.

Post a reply to this message

Op 05/06/2021 om 16:55 schreef Alain Martel:
> To make your turbulence smoother, reducing the octave parameter could 
> help. It default at 6. So, maybe try with octave 3.
> 
> Next, you can also reduce the lambda. Default of 2. Make it closer to 1.
> 
> Finally, the omega could also get adjusted down from the default of 0.5.
> 
> A proposition :
> octave 3
> lambda 1.4
> omega 0.25
> 
> This should make the turbulence much more wavy and smoother.

Yes indeed, and thanks for the reminder. Presently I have no time to 
deal too much with this, but Bald Eagle will take that up quite probably :-)

For now, I need to concentrate on that part of the docs I mentioned 
earlier, and deal with a couple of little thorns in the macro code which 
have not been dealt with fully to my satisfaction.

-- 
Thomas

Post a reply to this message

Op 01/06/2021 om 14:49 schreef Thomas de Groot:
> Op 31-5-2021 om 03:41 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> - A comprehensive demo scene file
>>
>>> - An investigation/implementation of Real World dimensions (should have
>>> started with that, but you know of it goes...)
>>
>>> - Additional xxxGranite.inc files to be fed to the macro
>>
>> So I was playing with a scene for editing the material's color_map, 
>> and in
>> addition to the inc file stuff, I noticed that you had removed all of 
>> the macro
>> parameters.
>>
>> I think that works really nicely, so far.
>>
>> On the one hand, I like the #undef stuff at the end, but with what I'm 
>> doing
>> with variations on the same theme, I noticed that that causes me to 
>> have to

>> work with
>> that.
>>
> Yes, but it might not be the best solution...
> 
>> But I'm thinking if it doesn't change anything, maybe have it work like
>>
>> Granite_21 (optional parameters_persist)
>> (default is no)
>> and then #if (parameters_persist) would govern macro section 7
>>
> Problem is that the 'optional' parameter is still only version 3.8 of 
> POV. Not desirable for now I am afraid.
> 
Now, with POV-Ray development started in earness again, the use of the 
'optional' parameter may become interesting again. I have to delve into 
its use because I do not entirely understand /how/ it works, but with a 
couple of test scenes I shall get the hang of it I expect.

>> I have some things laid out with to-scale rulers, and with respect to 
>> the SSLT
>> I'm wondering what I should do to indicate the - depth - of the 
>> translucency

>> diagram for
>> calculating / estimating the effect given an rgb 1 light_source and 
>> material
>> thickness.
>>
> After all the commotion about the Granite_file, I still have to plunge 
> into this.
> 
No change here at the moment.

>> I'm going to try to figure out a way to get as much useful visual info 
>> into the
>> scene, but minimize the long render time effect of the SSLT.
>>
>> Perhaps as a lead-in to the documentation, you could just briefly 
>> comment on the
>> layout and purpose of the macro parts - the masks and such?
>>
> I shall see what I can do on short term....
> 
Slow work somehow, but it is growing. I hope it will meet your 
expectations ;-)

>> Thanks,
>>
>> - Bill
>>
>> Attached is highlighting 2 color_map entries in green, and then 
>> replacing them

>> the scene
>> file.
>>
> That could be nice indeed... The original color_maps will need a serious 
> overhaul I am afraid.
> 
That "Granite Editor" of yours, Can you post me a copy? It looks like an 
interesting tool to use in the approach to re-defining the color_maps, 
and I do it intuitively by hand now. Thanks.


-- 
Thomas

Post a reply to this message