I am currently browsing through the include files to see if I can give a 
meaningful contribution to their upgrading to 3.7+ standard. Over time, 
some have been added to or partly upgraded, some are in am almost 
pristine state going back to version 3.1.

I started small and upgraded skies.inc, using the scene files provided 
in scenes/textures/pigments/skies.

This brings up a couple questions, illustrated by the images below. In 
this particular skies case, the scenes are typically labelled version 
3.6 with assumed_gamma 2.2 (image: s_cloud1-1). Obviously, this cannot 
be maintained in any self-respecting program promoting assumed_gamma 
1.0! :-)

So, I changed assumed_gamma to 1.0 (image: s_cloud1-2) and while I was 
at it, I experimented with Ive's transformation macro and Clipka's 
colour boost macro, and thus achieved a version with srgb colours 
(image: s_cloud1-3). These macros have been discussed  fairly recently 
in these ng's.

The fundamental question is: What do we want?

-- 
Thomas

Post a reply to this message

Attachments:
Download 's_cloud1-1.jpg' (30 KB) Download 's_cloud1-2.jpg' (27 KB) Download 's_cloud1-3.jpg' (30 KB)

Preview of image 's_cloud1-1.jpg'

Preview of image 's_cloud1-2.jpg'

Preview of image 's_cloud1-3.jpg'

Just as a check, I rendered your example  SCloud_1  skysphere in v3.8xx
(assumed_gamma 1.0), and get identical results to your middle image. So far, so
good ;-)

However, I think that in v3.6 days and prior to that, there was a real
question-- not to mention a bit of confusion-- about using assumed_gamma 1.0 vs.
2.2. My own *guess* is that the  SCloud_1  colors were chosen in a 2.2 gamma
environment, and that the 1st image is probably what was intended. But that's
just my gut feeling; it's very difficult to 2nd-guess someone's intention (and
working gamma space) from so long ago...not to mention having to deal with any
unknown color/gamma problems that may have existed in older versions of POV-ray
itself, which may have confused the original author.

I actually think that both the 1st AND 2nd images are pleasing-- but not the
3rd, it's too washed out. PERSONALLY, I think the appearance of these specific
sky colors should be somewhere *between* gamma 1.0 and 2.2, ha. But apparently a
2.2 gamma was what the author had in mind...so image #1 would be my pick. As a
jumping-off point, I would suggest simply changing the specified colors to srgb
versions-- no fancy conversions-- and see what it looks like at assumed_gamma
1.0.

[I also have a suspicion that some of the colors in "colors.inc" *may* have been
created for a gamma of 2.2 rather than 1.0. That's certainly debatable, of
course.]

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I am currently browsing through the include files to see if I can give a
> meaningful contribution to their upgrading to 3.7+ standard. Over time,
> some have been added to or partly upgraded, some are in am almost
> pristine state going back to version 3.1.

Thanks, Thomas.
I still have a few include files from Friedrich Lohmueller that I was working
through to tighten up the code and try to explain what was going on.


> The fundamental question is: What do we want?

Short answer: you really can't ever tell.
You may want to somehow include all three.
CloudySky1
CloudySky2
CloudySky3

Or maybe put all 3 versions in a macro with a version argument, and use #switch
to pick which one gets used.


Very long version:


I try to keep in mind that these files are accessed for usage, reference, and
learning.
So, the way I (try to) approach my stuff, is a chaotic mix of the following:

1. The simplest bare-bones example whose text can be used in the copy-paste
mechanism of the Insert Menu.
Because Whether I'm tired or forgetful, or whatever - I approach this part from
a New User perspective, and just want to plug in some working code from the GUI.

The only "extra" here, is that for something like a macro, I like to write a
working line of code or two to illustrate its actual usage in a scene.

2. Since these might be used as a reference to how certain features work, or as
the basis for the development of new SDL, or just as a historical record of
POV-Ray development, I like to get rid of "magic numbers", give things
meaningful identifiers, and perhaps restructure the formulas and code a bit so
that it's neat, clean, and easy to follow.
Author, date, version number, revision comments, etc.
This might comprise a completely separate "meta-version" of the code, which has
#debug statements enabled by #if_def (Verbose), etc.

One thing I've toyed with but haven't really fleshed out and used extensively,
if to come up with a naming scheme for almost everything, so that 400 lines into
some complicated scene code, I can get a clue about what's going on, and jump a
few steps ahead in the debugging process.
f_Identifier - function
v_Identifier - vector quantity
s_Identifier - scalar quantity
C_Identifier - color
P_Identifier - Pigment
T_Identifier - Texture
L_Identifier - a loop variable: #for (L_Identifier, 0, 10)

If Verbose is defined (boolean), I may send some comments to the debug stream
showing that a macro has indeed been invoked, and has exited.  That's just
because a scene with a large number of nested things can get pretty crazy,
trying to figure out where things went wrong.  Looking at the debug stream, I
can count the number of opening and closing statements and see where things went
off the rails.

For complicated formulas, or ones that probably won't have obvious meaning, a
few comments on what it does, how it's composed, what the assumed inputs and
outputs are, and perhaps a reference to the origin of the formula can go a long
way.
// based on code / formula for [whatever] - POV-Ray, Graphics Gems, ShaderToy,
website URL, math textbook, etc.
// Takes 2 vectors and uses the point-slope formula for a line to....
// divide both sides by x and cancel out [term] ....


On rare occasion, just for kicks, I've sent the stepwise solution to the worked
problem to the debug stream.

Along those lines, you might not worry so much about which fish to give the
end-user, and instead include a texture-generating macro that teaches someone
how a nice sky texture gets generated from first principles.
Links to the wiki for various features ought to help people quickly grasp what's
going on and possibly avoid the rehashing of the usual "how do I...", and even
if they do ask, anyone can just post a quick and simple "Just look at
m_ExampleMacro () in skies.inc - it _shows_ you how to do _everything_ ...

If you use "Step" as a macro argument, then you could progressively step through
the code line-by-line by doing something like
#if (Step > 0)
#declare P_SkyBasis = pigment {bozo};
#end
#if (Step > 1)
#declare P_StretchedSky = pigment {P_SkyBasis scale <10, 1, 50>}
#end

etc.
Every increment to step executes ALL of the previous steps.
Of course, you could use clock as well...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I would suggest simply changing the specified colors to srgb
> versions-- no fancy conversions-- and see what it looks like at assumed_gamma
> 1.0.
>

I decided to try that myself, for the S_Cloud1 skysphere. It makes use of the
pigments P_Cloud2 and P_Cloud3 in "skies.inc", so I changed those as well. All
srgb colors now, with assumed_gamma 1.0.

SO...the result is not what I was naively expecting; very different from the
v3.6 assumed_gamma 2.2 version. Rather stark and ugly.

I guess my 'simple' color/gamma conversion scheme is not the way to proceed...
:-[

Post a reply to this message

Attachments:
Download 's_cloud1_1_srgb_colors_assumed_gamma_1.jpg' (99 KB)

Preview of image 's_cloud1_1_srgb_colors_assumed_gamma_1.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
> Just as a check, I rendered your example  SCloud_1  skysphere in v3.8xx
> (assumed_gamma 1.0), and get identical results to your middle image. So far, so
> good ;-)
>

Hmm, they are not quite identical after all.

I thought I would do a side-by-side comparison of your v3.6 assumed_gamma 1.0
version to v3.8xx (I changed the "skies.inc" pigments back to their originals.)

There's a definite difference; I assume that it comes from the many
'under-the-hood' changes made to POV-ray since v3.6.

So it seems to be very difficult to determine (and update) what the author's
*original* visual intent was for these pigments.

Unless we all go back to using v3.6  :-O

Post a reply to this message

Attachments:
Download 'version_comparison_at assumed_gamma_1.jpg' (84 KB)

Preview of image 'version_comparison_at assumed_gamma_1.jpg'

Le 2021-02-28 à 03:14, Thomas de Groot a écrit :
> I am currently browsing through the include files to see if I can give a 
> meaningful contribution to their upgrading to 3.7+ standard. Over time, 
> some have been added to or partly upgraded, some are in am almost 
> pristine state going back to version 3.1.
> 
> I started small and upgraded skies.inc, using the scene files provided 
> in scenes/textures/pigments/skies.
> 

Another thing.
Most if not all of those are using ambient for the clouds. That need to 
be changed to emission to work properly in a radiosity scene.

The same hold for the starry skies.

Next, the ambient component in the metallic textures need to go away.

Post a reply to this message

Op 28/02/2021 om 16:09 schreef Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> I would suggest simply changing the specified colors to srgb
>> versions-- no fancy conversions-- and see what it looks like at assumed_gamma
>> 1.0.
>>
> 
> I decided to try that myself, for the S_Cloud1 skysphere. It makes use of the
> pigments P_Cloud2 and P_Cloud3 in "skies.inc", so I changed those as well. All
> srgb colors now, with assumed_gamma 1.0.
> 
> SO...the result is not what I was naively expecting; very different from the
> v3.6 assumed_gamma 2.2 version. Rather stark and ugly.
> 
> I guess my 'simple' color/gamma conversion scheme is not the way to proceed...
> :-[
> 

This is strange. Attached find my version of the same which is 
comparable to the original. Something is different apparently.

In skies.inc, I also changed the version to 3.7, which is also used in 
the scene file.

-- 
Thomas

Post a reply to this message

Attachments:
Download 's_cloud1-4.jpg' (32 KB)

Preview of image 's_cloud1-4.jpg'

Op 28/02/2021 om 18:11 schreef Alain Martel:
> Le 2021-02-28 à 03:14, Thomas de Groot a écrit :
>> I am currently browsing through the include files to see if I can give 
>> a meaningful contribution to their upgrading to 3.7+ standard. Over 
>> time, some have been added to or partly upgraded, some are in am 
>> almost pristine state going back to version 3.1.
>>
>> I started small and upgraded skies.inc, using the scene files provided 
>> in scenes/textures/pigments/skies.
>>
> 
> Another thing.
> Most if not all of those are using ambient for the clouds. That need to 
> be changed to emission to work properly in a radiosity scene.
> 
> The same hold for the starry skies.
> 
> Next, the ambient component in the metallic textures need to go away.

Yes sir. One of the first actions I took in skies.inc was to change 
ambient to emission. It has also the neat advantage that it works 
correctly whether radiosity is used or not.

The stars.inc file has a very different type of problem about which I 
shall write separately. As it stands now, it is totally useless.

Otherwise, indeed, ambient needs to be dropped completely.

-- 
Thomas

Post a reply to this message

Op 28/02/2021 om 16:43 schreef Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> Just as a check, I rendered your example  SCloud_1  skysphere in v3.8xx
>> (assumed_gamma 1.0), and get identical results to your middle image. So far, so
>> good ;-)
>>
> 
> Hmm, they are not quite identical after all.
> 
> I thought I would do a side-by-side comparison of your v3.6 assumed_gamma 1.0
> version to v3.8xx (I changed the "skies.inc" pigments back to their originals.)
> 
> There's a definite difference; I assume that it comes from the many
> 'under-the-hood' changes made to POV-ray since v3.6.
> 
> So it seems to be very difficult to determine (and update) what the author's
> *original* visual intent was for these pigments.
> 
> Unless we all go back to using v3.6  :-O
> 

I have not tested it, but maybe your differences come from the fact that 
you use version 3.8 here. I did not, from the principle that version 3.7 
and/or 3.7.1 are the /last/ official versions of POV-Ray. As a start, 
the includes should comply with those versions. Version 3.8 is beta and 
may need more changes in future.

-- 
Thomas

Post a reply to this message

Op 28/02/2021 om 14:52 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I am currently browsing through the include files to see if I can give a
>> meaningful contribution to their upgrading to 3.7+ standard. Over time,
>> some have been added to or partly upgraded, some are in am almost
>> pristine state going back to version 3.1.
> 
> Thanks, Thomas.
> I still have a few include files from Friedrich Lohmueller that I was working
> through to tighten up the code and try to explain what was going on.
> 
> 
>> The fundamental question is: What do we want?
> 
> Short answer: you really can't ever tell.
> You may want to somehow include all three.
> CloudySky1
> CloudySky2
> CloudySky3
> 
> Or maybe put all 3 versions in a macro with a version argument, and use #switch
> to pick which one gets used.
> 

Indeed. This was one of the options I was thinking about. However, as 
you correctly mentioned below, these files are (probably) mostly used as 
reference and learning items, and their value resides in the first place 
to their use by new users. So, I would prefer to update/-grade the files 
to 3.7.1 standards. In the process, some files will probably need more 
serious tweaking than others or be completely rewritten. A #switch kind 
of system may then be advisable indeed, as you write below (and above).

> 
> Very long version:
> 

And I appreciate your effort. I am not going to comment in detail just 
now, but keep this in the background as reference.

> 
> I try to keep in mind that these files are accessed for usage, reference, and
> learning.
> So, the way I (try to) approach my stuff, is a chaotic mix of the following:
> 
> 1. The simplest bare-bones example whose text can be used in the copy-paste
> mechanism of the Insert Menu.
> Because Whether I'm tired or forgetful, or whatever - I approach this part from
> a New User perspective, and just want to plug in some working code from the GUI.
> 
> The only "extra" here, is that for something like a macro, I like to write a
> working line of code or two to illustrate its actual usage in a scene.
> 
> 2. Since these might be used as a reference to how certain features work, or as
> the basis for the development of new SDL, or just as a historical record of
> POV-Ray development, I like to get rid of "magic numbers", give things
> meaningful identifiers, and perhaps restructure the formulas and code a bit so
> that it's neat, clean, and easy to follow.
> Author, date, version number, revision comments, etc.
> This might comprise a completely separate "meta-version" of the code, which has
> #debug statements enabled by #if_def (Verbose), etc.
> 
> One thing I've toyed with but haven't really fleshed out and used extensively,
> if to come up with a naming scheme for almost everything, so that 400 lines into
> some complicated scene code, I can get a clue about what's going on, and jump a
> few steps ahead in the debugging process.
> f_Identifier - function
> v_Identifier - vector quantity
> s_Identifier - scalar quantity
> C_Identifier - color
> P_Identifier - Pigment
> T_Identifier - Texture
> L_Identifier - a loop variable: #for (L_Identifier, 0, 10)
> 
> If Verbose is defined (boolean), I may send some comments to the debug stream
> showing that a macro has indeed been invoked, and has exited.  That's just
> because a scene with a large number of nested things can get pretty crazy,
> trying to figure out where things went wrong.  Looking at the debug stream, I
> can count the number of opening and closing statements and see where things went
> off the rails.
> 
> For complicated formulas, or ones that probably won't have obvious meaning, a
> few comments on what it does, how it's composed, what the assumed inputs and
> outputs are, and perhaps a reference to the origin of the formula can go a long
> way.
> // based on code / formula for [whatever] - POV-Ray, Graphics Gems, ShaderToy,
> website URL, math textbook, etc.
> // Takes 2 vectors and uses the point-slope formula for a line to....
> // divide both sides by x and cancel out [term] ....
> 
> 
> On rare occasion, just for kicks, I've sent the stepwise solution to the worked
> problem to the debug stream.
> 
> Along those lines, you might not worry so much about which fish to give the
> end-user, and instead include a texture-generating macro that teaches someone
> how a nice sky texture gets generated from first principles.
> Links to the wiki for various features ought to help people quickly grasp what's
> going on and possibly avoid the rehashing of the usual "how do I...", and even
> if they do ask, anyone can just post a quick and simple "Just look at
> m_ExampleMacro () in skies.inc - it _shows_ you how to do _everything_ ...
> 
> If you use "Step" as a macro argument, then you could progressively step through
> the code line-by-line by doing something like
> #if (Step > 0)
> #declare P_SkyBasis = pigment {bozo};
> #end
> #if (Step > 1)
> #declare P_StretchedSky = pigment {P_SkyBasis scale <10, 1, 50>}
> #end
> 
> etc.
> Every increment to step executes ALL of the previous steps.
> Of course, you could use clock as well...
> 


-- 
Thomas

Post a reply to this message

Op 01/03/2021 om 08:49 schreef Thomas de Groot:
> Op 28/02/2021 om 16:43 schreef Kenneth:
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>> Just as a check, I rendered your example  SCloud_1  skysphere in v3.8xx
>>> (assumed_gamma 1.0), and get identical results to your middle image. 
>>> So far, so
>>> good ;-)
>>>
>>
>> Hmm, they are not quite identical after all.
>>
>> I thought I would do a side-by-side comparison of your v3.6 
>> assumed_gamma 1.0
>> version to v3.8xx (I changed the "skies.inc" pigments back to their 
>> originals.)
>>
>> There's a definite difference; I assume that it comes from the many
>> 'under-the-hood' changes made to POV-ray since v3.6.
>>
>> So it seems to be very difficult to determine (and update) what the 
>> author's
>> *original* visual intent was for these pigments.
>>
>> Unless we all go back to using v3.6  :-O
>>
> 
> I have not tested it, but maybe your differences come from the fact that 
> you use version 3.8 here. I did not, from the principle that version 3.7 
> and/or 3.7.1 are the /last/ official versions of POV-Ray. As a start, 
> the includes should comply with those versions. Version 3.8 is beta and 
> may need more changes in future.
> 

I tested and, no, you must have used some wrong settings somewhere. 
versions 3.7 or 3.8 render identically.

-- 
Thomas

Post a reply to this message

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

> >
> > I have not tested it, but maybe your differences come from the fact that
> > you use version 3.8 here. I did not, from the principle that version 3.7
> > and/or 3.7.1 are the /last/ official versions of POV-Ray. As a start,
> > the includes should comply with those versions. Version 3.8 is beta and
> > may need more changes in future.
> >
>
> I tested and, no, you must have used some wrong settings somewhere.
> versions 3.7 or 3.8 render identically.
>
You are absolutely correct; I made a mistake, a really dumb one: In my simple
v3.8xx scene file for testing the skysphere and the rgb-vs-SRGB colors, I
mistakenly wrote #version 2.8 instead of 3.8! (I have no idea what "version 2.8"
does to colors-- if there ever WAS such a version.) My render was definitely
screwed up; sorry for the confusion.

Now, my v3.8 SRGB-color version looks just like your v3.7 version.

I also ran my scene in v3.7 to double-check any color/gamma differences
between that and v3.8xx; they look identical, as you say.

The other interesting behavior I noticed (maybe it's expected) is that the older
#version directive of 3.5 in "skies.inc" can be changed to 3.7, with absolutely
no change in the renders (when run in either v3.7.0 or 3.8xx). I did some
'difference' comparisons in Photoshop to check this.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > I would suggest simply changing the specified colors to srgb
> > versions-- no fancy conversions-- and see what it looks like at assumed_gamma
> > 1.0.
> >
>
> I decided to try that myself, for the S_Cloud1 skysphere...

This is what the comparison was supposed to look like, between
v3.6 at assumed_gamma 2.2
and
v3.7.0 (or 3.8, same effect) at assumed gamma 1.0

There is a slight difference, perhaps in contrast. It is difficult to figure out
exactly what causes this; but it might be like comparing 'apples to oranges',
considering the many changes that have been made to POV-ray since v3.6.

Post a reply to this message

Attachments:
Download 'skies_scene_comparison.jpg' (114 KB)

Preview of image 'skies_scene_comparison.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:
>[...]
Thanks a lot or your undertaking,
First note that looking at images through small previews on the web interface of
theses newsgroups is always error prone and one would naturally go to the more
contrasted. But opening full screen and really looking at pictures,
I clearly prefer the third version because a) it's the most realistic would one
consider the season to be winter (paler) rather than summer, and b)that does not
show procedural cloud color map edges so contrasted as was so frequently done in
the nineties, it's crucial now that POV moves away from what people think are
its limitations to show what it really can do.

If not already done, could more "modern" macros such as lightsys or
CousinRicky's metal work or the ones you mentionned be integrated to those
official libraries at last or is there some show stopper ?

Post a reply to this message

Op 01/03/2021 om 14:42 schreef Mr:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> [...]
> Thanks a lot or your undertaking,
> First note that looking at images through small previews on the web interface of
> theses newsgroups is always error prone and one would naturally go to the more
> contrasted. But opening full screen and really looking at pictures,
> I clearly prefer the third version because a) it's the most realistic would one
> consider the season to be winter (paler) rather than summer, and b)that does not
> show procedural cloud color map edges so contrasted as was so frequently done in
> the nineties, it's crucial now that POV moves away from what people think are
> its limitations to show what it really can do.
> 
> If not already done, could more "modern" macros such as lightsys or
> CousinRicky's metal work or the ones you mentionned be integrated to those
> official libraries at last or is there some show stopper ?
> 

Aha! This again, addresses imo the fundamental question, also mentioned 
by BaldEagle, if we should not take leave of (some) of the "backward 
compatibility" rule. These cloud scenes were great a couple of decades 
ago but hardly anyone nowadays would use them without serious changes; 
even newbies would probably not find them acceptable given the 
development in the field of cgi.

So, I think that POV-Ray's include files should reflect these changes 
and, as Bald Eagle wrote too, provide a switching system to show, where 
possible or available, the evolution of the concept. In the case of 
clouds, that would mean these simple, version 3.1 and 3.5 cloud scenes, 
and the version 3.7+ alternatives.

In other cases, upgrading will be much more straightforward imo. 
Metallic or wood textures e.g. But there too, new additions might be or 
should be seriously considered. After all, over the years, we have 
acquired a huge amount of creative power condensation and deposition! :-)

-- 
Thomas

Post a reply to this message

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

> Aha! This again, addresses imo the fundamental question, also mentioned
> by BaldEagle, if we should not take leave of (some) of the "backward
> compatibility" rule. These cloud scenes were great a couple of decades
> ago but hardly anyone nowadays would use them without serious changes;
> even newbies would probably not find them acceptable given the
> development in the field of cgi.

I think, at this point, if we are going to move forward toward "4.0", then WE
must move _forward_ TO 4.0.

I have been writing some macros for use in (new) include files as well, and I
think it would be good to periodically collect and summarize ALL of the broadly
useful macros and formulas that we have - to see where we are, and so people can
review, fiddle, critique, error and performance check, etc.

> ...over the years, we have
> acquired a huge amount of creative power condensation and deposition! :-)

Going through a lot of what we have, I would say that if we're in the process of
updating and changing things, we should make a clean break, and even start
renaming some of the macros as well.

For instance, in the recent example of clarifying and modifying Point_At_Trans,
I have always thought that the name was terrible, due to vagueness.  Point
_what_ at _what_?  I think that maybe it should be renamed to something that
more clearly and concisely describes what it actually does.  "Tilt Y to new
position" "Rotate Y vector" or something like that.  Because that's what we're
going to have to remember when we type it into the scene.
It's easy enough to have the old macro name just call the macro with the new
name.

#macro OldName (Argument)
     //#warning "macro OldName has been deprecated, consider using NewName"
     #macro NewName (Argument)
#end

It's always difficult for me to know where to strike a balance with comments,
but in general, as Bill Pokorny pointed out, comments in macros and loops need
to be parsed - character by character - and so perhaps comments should reside
exclusively outside of the macros, perhaps in a nice, boxed header section, or
at least use a // 1   // 2   // 3 short notation to refer to line-specific
comments in the header.

//########################################
// This is my macro that does cool stuff #
// 1. actually it does literally nothing #
//########################################
// Author                                #
// Revised by                            #
// Version                               #
// Dependencies: math.inc, stuff2.inc    #
//########################################
#macro CoolStuff ()
     #if (true)
          #break // note 1
     #else
     #end
#end
//########################################

Since over the course of time, various include files have been improved,
updated, and have had errors corrected, I would like to see a semantic
versioning system somehow implemented.  Otherwise we're talking about one
filename, rather than a specific version of the file.  Just like we have POV-Ray
3.5, 3.6, 3.7, 3.8...
How do we accomplish that, yet keep the same simple naming scheme?
Maybe skies.inc has a single functional line: #include "skies_2_1_1.inc"
Sure, we can have a revision history, with #include "skies_1_1_1.inc" commented
out above that.

Perhaps, if there is a need for extensive documentation, it would be wise to
supplement the official docs with a .txt file with the same parent filename.
So, skies,inc would have a skies.txt file that tags along in the include
directory, and can be as verbose as the situation warrants.

Things like eval_pigment(), now(), trace() and the orthographic camera are
things that I have to re-learn to use Every Single Time.
There are also things about the orthographic camera that I still don't really
understand.


Everyone has their own programming style, and naming conventions, and toleration
for "clutter" or absence of guiding commentary.

So while there will be a certain level of unavoidable preference clashes, I
think that now is a good time to set the tone for how things will be structured,
and maybe even the content and placement of macros in the include files might
get rearranged, if it makes more sense to do so.

I mean we have shapes, and shapes1 and shapes2 and maybe even a shapes3
and there are necessary dependencies in some of those shape files that aren't
explicitly indicated or automatically included.

stones metals granites golds, ....
textures.inc ---- textures of WHAT?

It's a lot to slog through, but I think that hammering out a single include file
that illustrates a lot of the ideology and format we might want would be a great
way to guide work on successive efforts.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:

> updating and changing things, we should make a clean break, and even start
> renaming some of the macros as well.
> [...]I think that now is a good time to set the tone for how things will be
structured,[...]
> It's a lot to slog through, but I think that hammering out a single include file
that illustrates a lot of the ideolo
gy and format we might want would be a great way to guide work on successive efforts.

Very true that more explicit names are required.
And +1 vote for a proof of concept macro set, so pragmatic use will better
reorient reflection. Something that I believe would weight in the positive
changes balance is that some acclaimed macro developers could start to value
their work as more being part of POV-Ray core or at least potentially, that's
why I asked about some specific macros such as Lightsys (but correct me if
POV-Ray trunk already features a better alternative that I'm not aware of): that
example is a collective work and one that appears to be time standing-ly
recognized, respected, and used actually much more than most of the "official"
macros delivered with POV-Ray package. In the same way when I look at what
asset/sample is available for any kind of metal presets, If I browse through the
standard includes and compare them with CousinRicky's I will definitely consider
the standard one outdated legacy for its result (maybe it just needs better
default settings but still), yet on the other hand, having to go to through some
"download>unzip>skim-through-newsgroups-for-doc" procedures for CR's macro makes
one (probably mistakingly) believe that this macro has been judged sub-standard
by the main team, so using it seems more risky /costly / not worthy /whatever...

All this makes it appear like POV is somewhat limited to phong spheres would you
choose to get more "seriously" into it.

Of course I do not pretend to speak for macro authors, but as a user, so one
could argue that these authors might not want their macros included ? Then the
question behind would rather be, after many decades, maybe it's time some
alternatives were made to  be actually delivered along with pov as part of the
package. (dropping off less used ones if file size is the matter)

Am I missing something or does this naive opinion actually make sense?

Post a reply to this message

"Mr" <nomail@nomail> wrote:

> Very true that more explicit names are required.

Explicit yes, as well as memorable and quick and easy to type, if possible.
The underscores make me cringe a bit.

> And +1 vote for a proof of concept macro set, so pragmatic use will better
> reorient reflection.

I _STILL_ look at descriptions of functions and macros and say to myself, "Oh,
no.... HOW do I actually USE that?  What do I DO with it?   Where in the code
does it GO?  Is it a standalone line?  Is it transformation on my object?  Is it
a value that use to do something else...?
And that can waste 10 minutes until I wrap my head around the underlying theory
of operation.

> ... having to go to through some
> "download>unzip>skim-through-newsgroups-for-doc" procedures for CR's macro makes
> one (probably mistakingly) believe that this macro has been judged sub-standard
> by the main team, so using it seems more risky /costly / not worthy /whatever...
>
> All this makes it appear like POV is somewhat limited to phong spheres would you
> choose to get more "seriously" into it.

Right - the standard distribution files may not have been touched in the last 20
years.

We could certainly use some of the nicer macro packages integrated more tightly
with "the system".   I'd say that things don't get used, due to a number of
things.   Time, knowledge or memory that they exist, the learning curve to
implement them, the energy and daring to spend the time and effort trying new
things....   Inertia....

> Of course I do not pretend to speak for macro authors, but as a user, so one
> could argue that these authors might not want their macros included ?

.... then don't write them and post them on the internet?
I mean, I understand the philosophical and practical theory of patents and IP,
but IMO, I think that there's a ridiculous level of "we can't use that without a
signed contract from the author" (who may be long gone or, sadly passed from
this mortal coil).   If it got posted, we use it.  Especially if it's just for
something like an include file or an insert menu snippet.   If they complain, we
can delete it.  It's not like it's critical source code.

> Am I missing something or does this naive opinion actually make sense?

Nope.  Not missing anything.   There are a lot of opinions that make perfect
sense, but which people have been conditioned to somehow find "offensive".
Ain't got time for that nonsense.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I _STILL_ look at descriptions of functions and macros and say to myself, "Oh,
> no.... HOW do I actually USE that?  What do I DO with it?   Where in the code
> does it GO?  Is it a standalone line?  Is it transformation on my object?
> Is it a value that use to do something else...?
> And that can waste 10 minutes until I wrap my head around the underlying
> theory of operation.
>

That's EXACTLY my problem as well. Except that I usually cannot figure out what
a particular feature means, and simpy move on in frustration-- never making an
attempt to use it, and not learning anything.

There are indeed many features that could be MUCH-better explained, with more
'humanly-readable' descriptions. I like *clarity*. If I had my way, something
like the Point_At_Trans macro would instead be

#macro This_Points_Your_Vector_Direction_In_Another_Direction_But_Watch_Out_For
Problems_So_Add_The_Bald_Eagle_Solution(...)"

:-P


I think the present state of POV-ray-- the difficulty of understanding how to
use certain features-- is partly a result of years /decades of a certain 'elite
attitude' among some users, and a few developers as well (Clipka being the major
exception IMO), that the program is meant for a particular intellectually
superior audience-- and that those of us who aspire to learn it should not be
'spoon fed' with helpful comments if we are perceived to be below a certain
level of ability. It went something like this: "Why don't you understand what
you're asking? Read the f**king manual. If you don't understand it, you don't
belong here, so get out." I exaggerate, but only a little. I think we have all
seen this kind of response-- an attitude that has certainly not helped to expand
POV-ray's user base! Personally, I've had to develop a thick skin over the
years, to put up with that kind of unhelpful garbage; luckily, I persevered. But
I amagine that others have simply given up and moved elsewhere. Of course, we
would not be using the program at all if we didn't have a desire to learn
programming in some way, and to 'build things from the ground up'; so it does
take *some* level of knowledge and interest to grasp the essentials.  But the
unhelpful attitudes have made it much harder than it should have been. And IMO,
there are many parts of the documentation that reflect this unnecessary
'anti-spoon-feeding' attitude. Perhaps POV-ray *was* initially developed only
for astute computer programmers, all those years ago; but those times have
changed. Now even kids are learning to program!

POV-ray is such a great platform for creating almost anything visual. With some
improvements to the documentation, and better example scenes, it would probably
pick up many more users going forward.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> That's EXACTLY my problem as well. Except that I usually cannot figure out what
> a particular feature means, and simpy move on in frustration-- never making an
> attempt to use it, and not learning anything.

Well, thankfully we have the interwebs, and a lot of other graphics platforms
that go about things in slightly different ways, which can help provide a few
more approaches to compare, and there are literally whole courses and textbooks
to be had just for the searching...

> There are indeed many features that could be MUCH-better explained, with more
> 'humanly-readable' descriptions. I like *clarity*. If I had my way, something
> like the Point_At_Trans macro would instead be
>
> #macro This_Points_Your_Vector_Direction_In_Another_Direction_But_Watch_Out_For
> Problems_So_Add_The_Bald_Eagle_Solution(...)"
>
> :-P

So, with regard to that, I was thinking that maybe a neat idea would be to go
through ALL of the keywords and major macros and functions and make a single
giant file with nothing but illustrative code examples.

I made an in-depth stab at tackling the Bezier splines and patches - but that
ate up what - a month or two? (I learned a lot though).


> I think the present state of POV-ray-- the difficulty of understanding how to
> use certain features-- is partly a result of years /decades of a certain 'elite
> attitude' among some users, and a few developers as well (Clipka being the major
> exception IMO), that the program is meant for a particular intellectually
> superior audience-- and that those of us who aspire to learn it should not be
> 'spoon fed' with helpful comments if we are perceived to be below a certain
> level of ability. It went something like this: "Why don't you understand what
> you're asking? Read the f**king manual. If you don't understand it, you don't
> belong here, so get out." I exaggerate, but only a little. I think we have all
> seen this kind of response-- an attitude that has certainly not helped to expand
> POV-ray's user base! Personally, I've had to develop a thick skin over the
> years, to put up with that kind of unhelpful garbage; luckily, I persevered. But
> I amagine that others have simply given up and moved elsewhere. Of course, we
> would not be using the program at all if we didn't have a desire to learn
> programming in some way, and to 'build things from the ground up'; so it does
> take *some* level of knowledge and interest to grasp the essentials.  But the
> unhelpful attitudes have made it much harder than it should have been. And IMO,
> there are many parts of the documentation that reflect this unnecessary
> 'anti-spoon-feeding' attitude. Perhaps POV-ray *was* initially developed only
> for astute computer programmers, all those years ago; but those times have
> changed. Now even kids are learning to program!

Yeah - there are those elitist types everywhere.   "This is for me, but not for
thee."  And they hate me, because I have a very "F U, I won't do what you tell
me" attitude, and learn how to do everything that they can, and then some.  And
find out all of the ways that they are wrong, and discover ways to do it better
than they ever could.

I get a very distinct sense of what you're talking about over on
StackExchange/StackOverflow, where people are unnecessarily condescending, and
you can't even post questions or replies unless you have a certain reputation...
Linux seems to have a bit of that as well.   "Well, you're using linux, so you
should ALREADY know how to...."  Yeah, lemme just pull that regular expression
out of my nether region and plug it into awk, pipe it through grep, and then....

POV-Ray is nice, because it has a lot of "pre-packaged" things that help you get
up and running quickly even though there is still a big learning curve if you
want to start doing anything reasonably advanced.
ShaderToy is helpful for me because it strips away the entire safety net, and
requires me to understand what something like a camera is in code and math ...
there is no camera {} statement.  There is no pigment {granite}.  If you want
granite you have to code the damned thing from scratch.

Which I could never do a few years ago, but TOK, Bill P., and other people have
shown me what is possible, and given me a few nudges here and there to help me
on my way.  Perusing POV-Ray's source code was pretty eye opening too.  Because
those pigment patterns weren't magic black-boxes anymore, they were really,
ultra simple one-line equations that (in hindsight) made perfect sense.  So then
once I saw how it was done, I could replicate the simple examples, and start to
play with new functions, daisy-chaining equations, and basically getting into
the deep end of the pool   ;)

For a new-user, ignorance and some naive notions are to be expected.  It's super
easy to help out with a few lines of code, or just plopping a whole ready-made
scene on them to show them how it's done.

On the flip side, there are people who never want to do anything themselves and
only take. But generally this is a politics-free forum.  ;)

As long as people are willing to TRY, that's fine with me.   And probably more
often than not, I've learned more and answered some of my own questions in the
process of trying to answer a question or prove to someone that "it can't be
done!" just isn't true.   There's a way.  It may take me 3 years to find it.
But by golly, I'll resort to the most heinous and hacktastic coding practices to
prove that "IT CAN BE DONE!!!"

Post a reply to this message

Things are actually moving in the right direction. I wouldn't feel that bitter.
Most people around here are humanist, altruist and generous. I tend to keep
asking stuff in the "new user"  section -and I never regret to post there
anytime I feel my question may be too basic. Doing so, I only received awesome
great answers since I came here.

Also about the documentation :

Though it is one of the best I know, I do agree that examples for everything is
a Great Idea , and a simple one like so many great ideas ! I'll try to take part
in that effort on the wiki.

Post a reply to this message

Op 03/03/2021 om 23:30 schreef Mr:
> Things are actually moving in the right direction. I wouldn't feel that bitter.
> Most people around here are humanist, altruist and generous. I tend to keep
> asking stuff in the "new user"  section -and I never regret to post there
> anytime I feel my question may be too basic. Doing so, I only received awesome
> great answers since I came here.
> 
> Also about the documentation :
> 
> Though it is one of the best I know, I do agree that examples for everything is
> a Great Idea , and a simple one like so many great ideas ! I'll try to take part
> in that effort on the wiki.
> 
> 
> 
I am a bit overwhelmed by the number of comments and I need to digest 
all that. My time seems always too limited to grasp even the essentials. :-/

Nonetheless, I fully agree with all the speakers! Be back later.

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, with regard to that, I was thinking that maybe a neat idea would be to go
> through ALL of the keywords and major macros and functions and make a single
> giant file with nothing but illustrative code examples.

That is a GREAT idea! I'd be interested in helping with that initiative.

> Yeah - there are those elitist types everywhere.   "This is for me, but not for
> thee."  And they hate me, because I have a very "F U, I won't do what you tell
> me" attitude, and learn how to do everything that they can, and then some.  And
> find out all of the ways that they are wrong, and discover ways to do it better
> than they ever could.

Rage on brother (i.e., Against the Machine), and amen, I feel exactly where
you're coming from.

> I get a very distinct sense of what you're talking about over on
> StackExchange/StackOverflow, where people are unnecessarily condescending, and
> you can't even post questions or replies unless you have a certain reputation...
> Linux seems to have a bit of that as well.   "Well, you're using linux, so you
> should ALREADY know how to...."  Yeah, lemme just pull that regular expression
> out of my nether region and plug it into awk, pipe it through grep, and then....

Now you're just killing me with your snarky regex, awk and grep - I literally
laughed out loud! Because it's all so true...

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:

> That is a GREAT idea! I'd be interested in helping with that initiative.

I guess something where we make a list (pref in a starter .pov file) and then we
can use that as a framework for group editing.

Maybe come up with a standard camera/resolution for anything that needs
rendering.
And #error directive for things that don't.
Make it one big #switch #case #break #end block.

Possibly alphabetize everything so it's easy to skim through.

And then it's just a basic functioning few lines of code for everything, and
then that can act as a basis for anyone who wants to follow up with
improvements.

(might need a companion .inc file for textures, useful macros, various other
odds and ends)

Which reminds me
In addition to my include file edits, and random number additions, I have a file
that I'm writing Graphics Gems methods in SDL, and I have my own include files
for things like matrix and array macros/formulas, and some commonly used
algorithms like sorting, etc.


> Rage on brother (i.e., Against the Machine), and amen, I feel exactly where
> you're coming from.


I do/have done construction, electrical, gas, HVAC, painting, grow food, store
food, cook, grind my own meat grain and spices, auto engine repair, small engine
repair, computer and printer repair, electronics, photography (B&W), arduino/cpp
coding, POV-Ray, archery, was an FFL, firearms instructor, I drive carts, pallet
jacks, forklifts, do organic chemistry, ....  getting into CB and ham, other
skillz...

"What do you do at work?"  Lift heavy stuff, clean, mop....
"What do you do at home?"  Derive the mixed partial second derivatives of
Bernstein polynomials..."


Does anyone hire me for any of that stuff? ...  no.  :|



Some is due to interest alone, most due to poverty/necessity.
It's TIRING, but I plan on outliving the snowflakes whose delicate constitution
can only tolerate organic soy milk.

“A human being should be able to change a diaper, plan an invasion, butcher a
hog, conn a ship, design a building, write a sonnet, balance accounts, build a
wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly. Specialization is for
insects.”

― Robert A. Heinlein


> Now you're just killing me with your snarky regex, awk and grep - I literally
> laughed out loud! Because it's all so true...


I mean I've done all of that - most of it 20 years ago ...  but I'm a fan of
clear, concise, complete, and robust instructions.
It's easy to forget that SHT, and sometimes I write code on Monday and have no
idea how what I wrote works on Wednesday...
Not to mention the few times I only found a single example of code I wanted to
use, and am in the middle of saying to myself, "Yes! This is great...."    and
then I realize, "Oh.  Wow.  This is MY code..."   <eyeroll> because clearly the
coffee was working its magic when I wrote it, and then wasn't, when I forgot
that I had already wrote it and then searched for it....   :D

Post a reply to this message

So, I just copied the keyword list from the wiki, added the boilerplate code,
and did the acos entry just to suggest a starting point and format.

I'm thinking I should have used strcomp...  :/

Post a reply to this message

Attachments:
Download 'keywordexamples.pov.txt' (70 KB)

Op 07/03/2021 om 02:23 schreef Bald Eagle:
> "Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> 
>> That is a GREAT idea! I'd be interested in helping with that initiative.
> 
> I guess something where we make a list (pref in a starter .pov file) and then we
> can use that as a framework for group editing.
> 
> Maybe come up with a standard camera/resolution for anything that needs
> rendering.
> And #error directive for things that don't.
> Make it one big #switch #case #break #end block.
> 
> Possibly alphabetize everything so it's easy to skim through.
> 
> And then it's just a basic functioning few lines of code for everything, and
> then that can act as a basis for anyone who wants to follow up with
> improvements.
> 
> (might need a companion .inc file for textures, useful macros, various other
> odds and ends)
> 
> Which reminds me
> In addition to my include file edits, and random number additions, I have a file
> that I'm writing Graphics Gems methods in SDL, and I have my own include files
> for things like matrix and array macros/formulas, and some commonly used
> algorithms like sorting, etc.
> 
> 
>> Rage on brother (i.e., Against the Machine), and amen, I feel exactly where
>> you're coming from.
> 
> 
> I do/have done construction, electrical, gas, HVAC, painting, grow food, store
> food, cook, grind my own meat grain and spices, auto engine repair, small engine
> repair, computer and printer repair, electronics, photography (B&W), arduino/cpp
> coding, POV-Ray, archery, was an FFL, firearms instructor, I drive carts, pallet
> jacks, forklifts, do organic chemistry, ....  getting into CB and ham, other
> skillz...
> 
> "What do you do at work?"  Lift heavy stuff, clean, mop....
> "What do you do at home?"  Derive the mixed partial second derivatives of
> Bernstein polynomials..."
> 
> 
> Does anyone hire me for any of that stuff? ...  no.  :|
> 
> 
> 
> Some is due to interest alone, most due to poverty/necessity.
> It's TIRING, but I plan on outliving the snowflakes whose delicate constitution
> can only tolerate organic soy milk.
> 
> “A human being should be able to change a diaper, plan an invasion, butcher a
> hog, conn a ship, design a building, write a sonnet, balance accounts, build a
> wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
> alone, solve equations, analyze a new problem, pitch manure, program a computer,
> cook a tasty meal, fight efficiently, die gallantly. Specialization is for
> insects.”
> 
> ― Robert A. Heinlein
> 
> 
>> Now you're just killing me with your snarky regex, awk and grep - I literally
>> laughed out loud! Because it's all so true...
> 
> 
> I mean I've done all of that - most of it 20 years ago ...  but I'm a fan of
> clear, concise, complete, and robust instructions.
> It's easy to forget that SHT, and sometimes I write code on Monday and have no
> idea how what I wrote works on Wednesday...
> Not to mention the few times I only found a single example of code I wanted to
> use, and am in the middle of saying to myself, "Yes! This is great...."    and
> then I realize, "Oh.  Wow.  This is MY code..."   <eyeroll> because clearly the
> coffee was working its magic when I wrote it, and then wasn't, when I forgot
> that I had already wrote it and then searched for it....   :D
> 

I have learned by experience that writing instructions for everybody's 
use (or for a dedicated group like in a working environment) is one of 
the most challenging things to do, especially if you intend them to be 
'clear', 'consistent', 'comprehensible'. It is a humbling experience 
too, about your own limitations. More often than not I got people coming 
to me telling me that my instructions 'didn't work', 'crashed the 
system', 'were Russian to them', etc... I learned to integrate those 
reactions into comprehensive updates. :-)

Btw, I am still 'digesting' but I'll come back to the topic.

-- 
Thomas

Post a reply to this message

I am slowly working towards an understanding about what needs to be 
done. The skies.inc was primary exploration for me; I have now examined 
more closely some texture issues.

I selected the American Granites suite which Daniel Mecklenburg Jr wrote 
for version 2.2. I corrected some inconsistencies and then built a 
#switch system (for now only the first textures: MohoganyPol and 
MohoganyFro) to allow for different renders according to the user's whim.

I think that this suite of granite textures should be included into the 
POV-Ray package by the way. I guess it was dropped or lost.

The image below shows two sets of renders: The top two rows correspond 
to the MohoganyFro set; the two bottom rows to the MohoganyPol set. The 
difference between the row couples is only that in the second one a 
layered texture is used for some extra veins in the granite.

The first column shows the granite in its basic, linear colour space, 
form as written by the author.

The second column uses a simple rewrite of rgb --> srgb, assuming that 
the original code was written for an assumed_gamma 2.2 environment.

The third column uses the transformation function by Ive from scRGB to 
sRGB. I kept this column as reference, but I would argue for the 
following column as to be definitive.

The fourth column additionally uses the colour saturation/brightness 
variation code by Clipka.

It is a bit of work, but I think that this would be an acceptable to 
update the textures available in the Include directory.


-- 
Thomas

Post a reply to this message

Attachments:
Download 'conversions.jpg' (778 KB)

Preview of image 'conversions.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:
> I am slowly working towards an understanding about what needs to be
> done. The skies.inc was primary exploration for me; I have now examined
> more closely some texture issues.

I like Clipka's version best. I know Christoph has championed gamma 1.0 but I'm
really a novice with the whole gamma issue (which I've seen debated endlessly
here over the years).

That said, I just read this blog post about gamma, which I found very
enlightening and thought it might be helpful to others here:

https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/

Post a reply to this message

Op 7-3-2021 om 17:32 schreef Robert McGregor:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I am slowly working towards an understanding about what needs to be
>> done. The skies.inc was primary exploration for me; I have now examined
>> more closely some texture issues.
> 
> I like Clipka's version best. I know Christoph has championed gamma 1.0 but I'm
> really a novice with the whole gamma issue (which I've seen debated endlessly
> here over the years).
> 
> That said, I just read this blog post about gamma, which I found very
> enlightening and thought it might be helpful to others here:
> 
> https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/
> 

I agree, in particular because it is closest to the "original", although 
we have no idea how the textures looked under version 2.2.

The whole switch idea gives a broader choice of textures to the user. 
After all, somebody may prefer a different aspect. And he/she can always 
start tinkering too.

-- 
Thomas

Post a reply to this message

On 2021-03-07 12:32 PM (-4), Robert McGregor wrote:
> 
> That said, I just read this blog post about gamma, which I found very
> enlightening and thought it might be helpful to others here:
> 
> https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/

Et tu, Photoshop?

Does anyone know whether GIMP and ImageMagick do it correctly?  The 
article doesn't mention these two, but I use them for resizing, and I've 
wondered about this issue.

I'm confident that POV-Ray 3.7 does it correctly, but who wants to write 
a scene file just to resize?  (I often end up doing that for simple 
editing anyway, because it's easier than deciphering the GIMP 
documentation.)

POV-Ray 3.6.2 and earlier read image files incorrectly, although this 
can be fixed with a pigment function, which is what I did before 3.7 was 
developed.  (Thanks Jaime or Ive, whoever posted the function.)  The 
article might also explain why anti-aliased text in POV-Ray 3.5 looks 
heavier than in 3.6 and later.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> POV-Ray 3.6.2 and earlier read image files incorrectly, although this
> can be fixed with a pigment function, which is what I did before 3.7 was
> developed.  (Thanks Jaime or Ive, whoever posted the function.)  The
> article might also explain why anti-aliased text in POV-Ray 3.5 looks
> heavier than in 3.6 and later.

Friedrich Lohmueller?

http://www.f-lohmueller.de/pov_tut/backgrnd/p_sky8.htm

Post a reply to this message

On 2021-03-08 2:23 PM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> POV-Ray 3.6.2 and earlier read image files incorrectly, although this
>> can be fixed with a pigment function, which is what I did before 3.7 was
>> developed.  (Thanks Jaime or Ive, whoever posted the function.)  The
>> article might also explain why anti-aliased text in POV-Ray 3.5 looks
>> heavier than in 3.6 and later.
> 
> Friedrich Lohmueller?
> 
> http://www.f-lohmueller.de/pov_tut/backgrnd/p_sky8.htm

No, the function I have uses sRGB non-linearity instead of a power 
gamma.  But Lohmüller's function has the same idea.  I cannot find the 
original post, but this code is adapted from one of my old scene files.

-----------[BEGIN CODE EXCERPT]-----------
#declare p_Map = pigment
{ image_map { jpeg "myimage.jpg" interpolate 2 }
}

#declare fn_Map = function { pigment { p_Map } }

#declare fn_Adjust = function (x) //from IEC 61966-2-1:1999
{ select (x - 0.04045, x / 12.92, pow ((x + 0.055) / 1.055, 2.4))
}

#declare p_Adjusted = pigment
{ average pigment_map
   { [ function { fn_Adjust (fn_Map (x, y, z).red) }
       color_map { [0 rgb 0] [1 red 3] }
     ]
     [ function { fn_Adjust (fn_Map (x, y, z).green) }
       color_map { [0 rgb 0] [1 green 3] }
     ]
     [ function { fn_Adjust (fn_Map (x, y, z).blue) }
       color_map { [0 rgb 0] [1 blue 3] }
     ]
   }
}
-----------[BEGIN CODE EXCERPT]-----------

Post a reply to this message

Op 08/03/2021 om 19:04 schreef Cousin Ricky:
> On 2021-03-07 12:32 PM (-4), Robert McGregor wrote:
>>
>> That said, I just read this blog post about gamma, which I found very
>> enlightening and thought it might be helpful to others here:
>>
>> https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/ 
>>
> 
> Et tu, Photoshop?
> 
> Does anyone know whether GIMP and ImageMagick do it correctly?  The 
> article doesn't mention these two, but I use them for resizing, and I've 
> wondered about this issue.


I don't know, but I preferably use Ive's IC for resizing.


-- 
Thomas

Post a reply to this message

I have been working on this one:

https://github.com/mjhorvath/POVRay-Updated-Screen-Inc

It modifies the original to work with orthographic camera too.

It also can report the 2D screen coordinates of a 3D point.



Mike

Post a reply to this message

On 3/7/2021 2:41 AM, Thomas de Groot wrote:
> I have learned by experience that writing instructions for everybody's 
> use (or for a dedicated group like in a working environment) is one of 
> the most challenging things to do, especially if you intend them to be 
> 'clear', 'consistent', 'comprehensible'. It is a humbling experience 
> too, about your own limitations. More often than not I got people coming 
> to me telling me that my instructions 'didn't work', 'crashed the 
> system', 'were Russian to them', etc... I learned to integrate those 
> reactions into comprehensive updates. :-)
> 
> Btw, I am still 'digesting' but I'll come back to the topic.
> 

I enjoy writing documentation, wiki articles, tables and charts, etc.

I almost NEVER comment my code however.

Meh.

Post a reply to this message

Op 13/05/2021 om 06:27 schreef Mike Horvath:
> On 3/7/2021 2:41 AM, Thomas de Groot wrote:
>> I have learned by experience that writing instructions for everybody's 
>> use (or for a dedicated group like in a working environment) is one of 
>> the most challenging things to do, especially if you intend them to be 
>> 'clear', 'consistent', 'comprehensible'. It is a humbling experience 
>> too, about your own limitations. More often than not I got people 
>> coming to me telling me that my instructions 'didn't work', 'crashed 
>> the system', 'were Russian to them', etc... I learned to integrate 
>> those reactions into comprehensive updates. :-)
>>
>> Btw, I am still 'digesting' but I'll come back to the topic.
>>
> 
> I enjoy writing documentation, wiki articles, tables and charts, etc.
> 
Oh, I certainly agree with that! However, it does not come easy and 
needs a lot of corrections and rewriting before it is even basically 
acceptable to me. An extra challenge is to do it in English which is not 
my native language (which does not make writing in my /native/ languages 
any easier though).

> I almost NEVER comment my code however.
> 
I almost ALWAYS do. ;-)

-- 
Thomas

Post a reply to this message

Op 13/05/2021 om 05:15 schreef Mike Horvath:
> I have been working on this one:
> 
> https://github.com/mjhorvath/POVRay-Updated-Screen-Inc
> 
> It modifies the original to work with orthographic camera too.
> 
> It also can report the 2D screen coordinates of a 3D point.
> 
Yes, that is an important one. I have it here.

-- 
Thomas

Post a reply to this message