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