 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 1-6-2021 om 08:59 schreef Thomas de Groot:
>> So I guess I will have to play with this... is the _GRANITE_FILE_INC_
>> "operating on" the #local Granite_file declaration ...? Does it need
>> the _INC_
>> part then...?
>>
> Now you ask too much ;-) A learned one like William Pokorny may know...
>
>> I'm even more confused by the #local Granite_file =
>> "DakotaRedGranite.inc" when
>> the actual file name isn't capitalized. Maybe I've run out of dried
>> frog
>> pills....
>>
Well... it appears I am in serious need of a fresh batch of the "Super
Strong Extra" frog pills myself. :-/
Don't ask me how or why I completely messed up here, that will be food
for the psychiatrist; I have an inkling but that is for another time.
Your bewilderment was completely right and I got the full bucket of cold
water on my head the moment when I /really/ tested with a new granite
include file. As you can guess ("I told you so") it did not work.
So, after having flogged myself almost senseless, I guess the following
lines should replace the offensive ones in the macro:
#ifndef (Granite_file) #local Granite_file = "DakotaRedGranite.inc" #end
#include Granite_file
Also, to make successive calls of the macro more comprehensive (for
now), add the following line in section 7:
#undef Granite_file
This seems to work correctly, at least for me. Hope it does for you too
of course.
>> You certainly have your own tricks up your sleeves that keep me on mine!!
>>
> Glad to be of help :-)
>
Yeah... my sleeves are full of holes and I often get pretty blind to
them... ;-[
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 31-5-2021 om 03:41 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degroot org> 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
> redeclare any macro parameters before each call. No big deal - I can 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.
> 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
> effect. I'm not sure that I know of an equation / documentation / 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.
> 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....
> Thanks,
>
> - Bill
>
> Attached is highlighting 2 color_map entries in green, and then replacing them
> with black. Just a little macro to make it easier to do from within the scene
> file.
>
That could be nice indeed... The original color_maps will need a serious
overhaul I am afraid.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
> > This is an ancient trick I learned decades ago ;-). The form
> > _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
> > covers all the possible forms of writing (capitals, dots, etc) of which
> > a file name is composed. And it works perfectly well for me.
>
> You're killin' me.
> I have never seen this used before, or even mentioned.
> Is this in the documentation?
>
> > And then...!!!! [thunderclap]
> > So I forgot to give you the proper Line 70, which should be of course,
> > after Line 69, as given:
> >
> > #ifndef (_GRANITE_FILE_INC_) #local Granite_file =
> > "DakotaRedGranite.inc" #end
> > #include Granite_file
>
> So I guess I will have to play with this... is the _GRANITE_FILE_INC_
> "operating on" the #local Granite_file declaration ...? Does it need the _INC_
> part then...?
>
This is a lifting of a "protection" mechanism from the C language (at least
that's where I first encountered it).
The basic form is in your main .c file is:
#include <somefile.h>
#include <someotherfile.h>
Assume that somefile.h also includes other files, and those include others.
Further assume that someotherfile.h also includes other files. If it ends up
that some set of includes is /duplicated/ then you run into problems.
So, to avoid that, in C somefile.h will contain something like this:
/* file: somefile.h */
/* defines some stuff */
ifndef(_SOMEFILE_H_)
#define _SOMEFILE_H_
#declare bob=1
#declare ted=2
#end
The idea is that each include file defines the variable name associated with
that file, so that if that include file is hit /again/ when resolving includes
the first ifndef line will discover that, the include file contents will be
'skipped', and nothing /more/ will happen.
I'm not aware of any 'magic' that happens in povscript WRT defining a
_filename_INC_ variable, but there could be such.
(hope this helps clear up the concept)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jamesf" <nomail@nomail> wrote:
> This is a lifting of a "protection" mechanism from the C language (at least
> that's where I first encountered it).
.....
Thanks, James - I have seen that type of thing in the various POV-Ray include
files, and probably in some source and arduino code. I thought that's what was
getting done, but at present it seems that TdG was trying to invoke some kind of
POV "woo".
> I'm not aware of any 'magic' that happens in povscript WRT defining a
> _filename_INC_ variable, but there could be such.
Yeah - I was stunned that there was some such thing that I had never heard of or
seen. On the other hand, it's an interesting concept - maybe a clever macro
could "search" for all variants of a particular filename...
> (hope this helps clear up the concept)
So do I. The world just keeps getting cloudier, murkier, more opaque, and more
obscure as time goes on it seems...
I'm going to sacrifice another lime and offer up a supplication that Thomas gets
the rest, therapy, - and medication - that he so desperately needs to find
clarity of mind and inner peace. We love you, Thomas. Help is always just a
forum-post away. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 01/06/2021 om 23:40 schreef Bald Eagle:
> "jamesf" <nomail@nomail> wrote:
>
>> This is a lifting of a "protection" mechanism from the C language (at least
>> that's where I first encountered it).
>
> .....
>
> Thanks, James - I have seen that type of thing in the various POV-Ray include
> files, and probably in some source and arduino code. I thought that's what was
> getting done, but at present it seems that TdG was trying to invoke some kind of
> POV "woo".
>
>> I'm not aware of any 'magic' that happens in povscript WRT defining a
>> _filename_INC_ variable, but there could be such.
>
> Yeah - I was stunned that there was some such thing that I had never heard of or
> seen. On the other hand, it's an interesting concept - maybe a clever macro
> could "search" for all variants of a particular filename...
>
>> (hope this helps clear up the concept)
>
> So do I. The world just keeps getting cloudier, murkier, more opaque, and more
> obscure as time goes on it seems...
>
> I'm going to sacrifice another lime and offer up a supplication that Thomas gets
> the rest, therapy, - and medication - that he so desperately needs to find
> clarity of mind and inner peace. We love you, Thomas. Help is always just a
> forum-post away. :)
>
Just got a bootlegged batch of fresh Dried Frog Pills (pale yellow, not
green) which does seem to do me a lot of good... [kwark!] sorry ;-)
You know how it works: somebody in some scene uses a "smart" trick,
which seems to work fine, and you mindlessly copy that into your own
scenes, and it does seem to work... somehow, and then you tweak that
"smart" trick to cover another need (close, but different) and lo! it
just refuses to do what you expected. That is what happened to me. It
took me an unusual long time to discover that it didn't work because I
had been so clever as to cover up my tracks in such a way that it always
"seemed" to work. I was sorely mislead by my tricky mind! One always
needs a critical mind close by to get you back on the right track.
Thanks Bill!
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> You know how it works: somebody in some scene uses a "smart" trick,
> which seems to work fine, and you mindlessly copy that into your own
> scenes, and it does seem to work... somehow, and then you tweak that
> "smart" trick to cover another need (close, but different) and lo! it
> just refuses to do what you expected.
Yes, I have been there on many occasions. But let's be honest, I've also been
thwarted from time to time by the simplest of stock SDL commands. :D
> One always
> needs a critical mind close by to get you back on the right track.
> Thanks Bill!
>
> --
> Thomas
Hey - if it somehow "worked", I would have let it slip by for a while too. I
only noticed it because POV-Ray was squawking about all of that undeclared
identifier stuff. Damned parser.
Glad you're feeling better. How many fingers am I holding up?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 2-6-2021 om 12:23 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> You know how it works: somebody in some scene uses a "smart" trick,
>> which seems to work fine, and you mindlessly copy that into your own
>> scenes, and it does seem to work... somehow, and then you tweak that
>> "smart" trick to cover another need (close, but different) and lo! it
>> just refuses to do what you expected.
>
> Yes, I have been there on many occasions. But let's be honest, I've also been
> thwarted from time to time by the simplest of stock SDL commands. :D
>
It is also when you are bending too long over the same bunch of code
that you get blind to the most obvious things.
>> One always
>> needs a critical mind close by to get you back on the right track.
>> Thanks Bill!
>>
>> --
>> Thomas
>
> Hey - if it somehow "worked", I would have let it slip by for a while too. I
> only noticed it because POV-Ray was squawking about all of that undeclared
> identifier stuff. Damned parser.
>
> Glad you're feeling better. How many fingers am I holding up?
>
hmmm.... fingers...? What do you mean by "fingers"...?
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> hmmm.... fingers...? What do you mean by "fingers"...?
You are a rather naughty old man.
Clearly I mean the measure of the quantity of tincture of bufo terrestris
americanus in a whiskey glass. :P
I came across this in my notifications - it's rather old, and sparse, but it has
a list of references that might be of more utility, and act as handles for
searching for newer developments.
https://www.academia.edu/993480/Modeling_Ore_Textures_and_Mineral_Liberation_Using_3D_Voronoi_Diagrams?email_work_card=
view-paper
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 03/06/2021 om 01:30 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> hmmm.... fingers...? What do you mean by "fingers"...?
>
> You are a rather naughty old man.
> Clearly I mean the measure of the quantity of tincture of bufo terrestris
> americanus in a whiskey glass. :P
>
Why didn't you say so in the first place? Filled my whiskey glass with
other stuff I am afraid... :-)
>
> I came across this in my notifications - it's rather old, and sparse, but it has
> a list of references that might be of more utility, and act as handles for
> searching for newer developments.
>
>
https://www.academia.edu/993480/Modeling_Ore_Textures_and_Mineral_Liberation_Using_3D_Voronoi_Diagrams?email_work_card=
> view-paper
>
Interesting! The use of voronoi diagrams had crossed my mind as an
alternative. However, I have not the slightest idea how to do that; a
bit beyond my capacities I am afraid. Still, good to know it has been
done. Another fork to the exploration rig. Thanks!
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 03/06/2021 om 08:39 schreef Thomas de Groot:
> Interesting! The use of voronoi diagrams had crossed my mind as an
> alternative. However, I have not the slightest idea how to do that; a
> bit beyond my capacities I am afraid. Still, good to know it has been
> done. Another fork to the exploration rig. Thanks!
>
Which reminded me of an old program I played with in the past:
Tesselsphere. On Sourceforge, there are other utilities too using
voronoi diagrams.
https://sourceforge.net/directory/os:windows/?q=voronoi
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Interesting! The use of voronoi diagrams had crossed my mind as an
> alternative. However, I have not the slightest idea how to do that; a
> bit beyond my capacities I am afraid. Still, good to know it has been
> done. Another fork to the exploration rig. Thanks!
Good heavens, lad! You're already doing it.
Crackle IS Voronoi - and you're using crackle {solid} which is 3D Voronoi.
Stop being so modest. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 3-6-2021 om 12:16 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> Interesting! The use of voronoi diagrams had crossed my mind as an
>> alternative. However, I have not the slightest idea how to do that; a
>> bit beyond my capacities I am afraid. Still, good to know it has been
>> done. Another fork to the exploration rig. Thanks!
>
> Good heavens, lad! You're already doing it.
> Crackle IS Voronoi - and you're using crackle {solid} which is 3D Voronoi.
>
> Stop being so modest. :)
>
>
LOL! I completely forgot about that aspect of crackle!
There is a 17th century French play by Molière, "Le bourgeois
Gentilhomme" where de main character, wanting to get access to the upper
echelons of society, starts to "educate" himself with the help of
"teachers" (more interested in money) and so is delighted to learn that
he has been speaking "prose" all his life without knowing it.
https://en.wikipedia.org/wiki/Le_Bourgeois_gentilhomme
[Admire my latest portrait on the site above. I think it is particularly
well done and life-like] :-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 03/06/2021 om 13:27 schreef Thomas de Groot:
> Op 3-6-2021 om 12:16 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> Interesting! The use of voronoi diagrams had crossed my mind as an
>>> alternative. However, I have not the slightest idea how to do that; a
>>> bit beyond my capacities I am afraid. Still, good to know it has been
>>> done. Another fork to the exploration rig. Thanks!
>>
>> Good heavens, lad! You're already doing it.
>> Crackle IS Voronoi - and you're using crackle {solid} which is 3D
>> Voronoi.
>>
>> Stop being so modest. :)
>>
>>
> LOL! I completely forgot about that aspect of crackle!
>
...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. At
this moment, beyond the beta and beyond the final version.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 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.
And, of course Jerome Grimbert has already addressed this in hgpovray38
https://wiki.povray.org/content/User:Le_Forgeron#voronoi
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.
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2021-06-05 à 02:39, Thomas de Groot a écrit :
> 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.
>
>
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
>> redeclare any macro parameters before each call. No big deal - I can
>> 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
>> effect. I'm not sure that I know of an equation / documentation /
>> 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
>> with black. Just a little macro to make it easier to do from within
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
