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