POV-Ray : Newsgroups : povray.binaries.scene-files : Granite_21 macro - beta #1.4 Server Time
20 Sep 2021 22:25:59 EDT (-0400)
  Granite_21 macro - beta #1.4 (Message 16 to 25 of 36)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Thomas de Groot
Subject: Re: Granite_21 macro - beta #1.5
Date: 1 Jun 2021 02:59:48
Message: <60b5dae4@news.povray.org>
Op 31/05/2021 om 20:06 schreef Bald Eagle:
> 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?
> 
No idea. I guess I learned it from a 'smart one'. I would not be 
surprised if that was Sam Benge. But others have used the trick too I am 
convinced.

>> 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...?
> 
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....
> 
This is one of those cases where DFP do not help I am afraid. I do not 
know th mechanism but it works. Same as my laptop: no idea how it 
functions... ;-)

> 
>> The granite include files, as I have defined them, use a 2d array
>> already.
> 
> Well, yes, but what I mean is that instead of:
> 
> array [Map1_entries][4] {
>    {0.00, not_0, not_0, not_0},
> 
> it might be preferable to have:
> array [Map1_entries][2] {
>    {0.00, <not_0, not_0, not_0>},
> 
> or
> 
> array [Map1_entries][2] {
>    {0.00, <not_0, not_0, not_0, not_0, not_0>},
> 
I am not a fan of this... The first would be a possibility... hmm, I 
have to think about this a bit. For instance, Map1 /never/ should have 
any filter or transmit info.

>> As the macro can render veins, where transmit info is supplied
>> by the corresponding array (the map2 one) it is just a matter of reading
>> the proper info in the right place. The macro takes care of that.
> 
> I am riding the struggle bus here.
> Convert () returns a basic rgb, not an rgbft,
> and map2 has transmit, yes, but not filter.
> My thought was that the macro should accommodate full 5D color vectors
> everywhere, because we have the Norbert Kern / Sean Day / Robert McGregor types
> who will squeeze every last bit of artistic flair out this if allowed to.
> 
They are free to try, but have to play by my rules ;-) For different 
reasons, I have restricted the use of transmit to the veins where 
filters are not allowed and imo, are not recommended.

Veins, btw, is still an issue of course.

>> Thanks for your thoughts! It keeps me on my toes. ;-)
> 
> You certainly have your own tricks up your sleeves that keep me on mine!!
> 
Glad to be of help :-)

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: Granite_21 macro - beta #1.5
Date: 1 Jun 2021 08:35:00
Message: <60b62974$1@news.povray.org>
Op 1-6-2021 om 08:59 schreef Thomas de Groot:


>> 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

>> 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

From: Thomas de Groot
Subject: Re: Granite_21 macro - beta #1.5
Date: 1 Jun 2021 08:50:00
Message: <60b62cf8$1@news.povray.org>
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.

> 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

From: jamesf
Subject: Re: Granite_21 macro - beta #1.5
Date: 1 Jun 2021 16:20:00
Message: <web.60b69548388d0b7adbe79f5e699c58ab@news.povray.org>
"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

From: Bald Eagle
Subject: Re: Granite_21 macro - beta #1.5
Date: 1 Jun 2021 17:45:00
Message: <web.60b6a96a388d0b7a1f9dae3025979125@news.povray.org>
"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

From: Thomas de Groot
Subject: Re: Granite_21 macro - beta #1.5
Date: 2 Jun 2021 02:27:17
Message: <60b724c5$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: Granite_21 macro - beta #1.5
Date: 2 Jun 2021 06:25:00
Message: <web.60b75c17388d0b7a1f9dae3025979125@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Granite_21 macro - beta #1.5
Date: 2 Jun 2021 07:53:32
Message: <60b7713c$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: Granite_21 macro - beta #1.5
Date: 2 Jun 2021 19:35:00
Message: <web.60b814a4388d0b7a1f9dae3025979125@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Granite_21 macro - beta #1.5
Date: 3 Jun 2021 02:39:15
Message: <60b87913$1@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

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