There are gaps in SDL's ability to query the state of the render, and
one of these is the default finish.  This is a problem for defining
certain library textures when radiosity is not used, as include files
have no access to the scene's lighting conditions.  This is the case
with several of the standard include files.

For a 100% diffuse texture, this is easily solved by omitting an ambient
from the finish, and setting a default ambient prior to including the
file that defines the texture; the textures in woods.inc are like this.
At the other extreme, a 100% specular texture, such as a pure metallic
texture, would have both ambient and diffuse set to zero.

But what about a texture that is, say, half metallic?  In that case, the
diffuse and ambient need to be halved.  But halved from what?  While it
is possible to override a finish ambient, I feel it is an unreasonable
burden on the user to have them figure out what ambient is appropriate
for each library texture.

The solution I used for RC3Metal was to have the user declare variables
with the scene's default ambient and diffuse.  But to implement this
solution over many include files would cumbersome for the user.  These
standard include files all set non-zero ambients on declared textures:
  glass_old.inc
  golds.inc
  metals.inc
  stones1.inc
  stones2.inc
  textures.inc

(Files finish.inc, skies.inc, and stars.inc also set non-zero ambients,
but these should really be converted to emission.)

One way to solve this would be to declare a single pair of variables
that would be used by all six include files.  Third party include files
would be encouraged to access these variables.  What do you think of
this proposal?  Does anyone have a better idea?

Post a reply to this message

Op 07/03/2022 om 19:33 schreef Cousin Ricky:
> [snip] >
> One way to solve this would be to declare a single pair of variables
> that would be used by all six include files.  Third party include files
> would be encouraged to access these variables.  What do you think of
> this proposal?  Does anyone have a better idea?

I am certainly no expert at all on this, but it seems a reasonable 
option to me while easiest to implement.

-- 
Thomas

Post a reply to this message

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

> One way to solve this would be to declare a single pair of variables
> that would be used by all six include files.  Third party include files
> would be encouraged to access these variables.  What do you think of
> this proposal?  Does anyone have a better idea?

Absent my current ability to formulate ways other than that one, I'd say that
starting all of those include files with an #include statement that references a
master include would be a good way to do it, in case any future tweaks happened.

Pre-coffee brain is thinking that the textures ought to be written as macros
that return a texture.
Why?
Then you could declare a secondary pair of values to hold "current" values while
retaining the default master values.   Then the user could use the stock
textures with the unaltered default master values, or override them by
redeclaring the "current" values.

Hope that makes sense.

Having some sort of "starter" include, or basic scene file template, or helper
libraries for new users has been intermittently discussed and worked on.
Perhaps as a means to implement, document, and standardize things going forward
from 3.8 to 4.0, you could take this value-pair idea and put that in a
default_values.inc or something that would always get included first thing.
Even after 30 years, we're still grappling with coincident textures, and so I
always define an E value, which is usually 0.000001 to make things bigger or
smaller by that much.  Having that value defined also serves as a reminder when
I'm doing differences, etc.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> One way to solve this would be to declare a single pair of variables
> that would be used by all six include files.  Third party include files
> would be encouraged to access these variables.  What do you think of
> this proposal?  Does anyone have a better idea?

given that the typical use case is a scene file doing '#include's, a single
"guard" would be nice + easy from the user point of view.


regards, jr.

Post a reply to this message

On 2022-03-08 07:40 (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> One way to solve this would be to declare a single pair of variables
>> that would be used by all six include files.  Third party include files
>> would be encouraged to access these variables.  What do you think of
>> this proposal?  Does anyone have a better idea?
> 
> Absent my current ability to formulate ways other than that one, I'd say that
> starting all of those include files with an #include statement that references a
> master include would be a good way to do it, in case any future tweaks happened.

What do you all think of the attached file?  Are there any other
variables we can add?

I added Defaults_Gamma in case an include file needs to correct for a
scene's assumed_gamma.  (I already have 2 Object Collection modules that
need to know a scene's assumed_gamma in order to return a proper color.)

Post a reply to this message

Attachments:
Download 'defaults.inc.zip' (1 KB)

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> What do you all think of the attached file?  Are there any other
> variables we can add?

a good start ?  (a lot of uppercase letters.. </grin>)

unsure if it is "in the spirit", but a "dedicated" font (preferred TTF) default,
for "post installation" ?


> I added Defaults_Gamma in case an include file needs to correct for a
> scene's assumed_gamma.  (I already have 2 Object Collection modules that
> need to know a scene's assumed_gamma in order to return a proper color.)

given the name and the purpose[*] of the file, I tried using 'include_header' to
load it.  it seems that for the system-wide 'povray.ini' that keyword won't
work.  for my personal file (~/.povray/3.8.povray.ini) I needed to add a
'#version version;' line to 'defaults.inc', before the guard, to avoid the 'as
of version 3.7' error message.

[*] I am looking at it not as the first include in other include files but as an
"always load", ideally.

of interest, loading via 'include_header' works with alpha.99456327 (displaying
the 'Defaults_Epsilon' value), but not for the beta.2.  may be a case of how
things are set up here, can anyone please confirm ?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> of interest, loading via 'include_header' works with alpha.99456327 (displaying
> the 'Defaults_Epsilon' value), but not for the beta.2.  may be a case of how
> things are set up here, can anyone please confirm ?

both work fine, and using 'include_header' in the respective system-wide
'povray.ini' too works; I'd forgotten my using a 'POVINI' in the (BASH)
functions used to invoke povray :-(, sorry about that.

Post a reply to this message

On 2025-12-28 05:58 (-4), jr wrote:
> 
> given the name and the purpose[*] of the file, I tried using 'include_header' to
> load it.

I am not familiar with 'include_header', and cannot find any mention of
it in the documentation or include files.  What does this do?

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> I am not familiar with 'include_header', and cannot find any mention of
> it in the documentation or include files.  What does this do?

to use, add the this to your (global) 'povray.ini' file:

  include_header = /path/to/defaults.inc

guessing the path may be optional if the files are stored in same directory.

this causes the named file to be included, as first thing, before the
scene/frame parsing gets underway.

<wiki.povray.org/content/Reference:Scene_Parsing_Options#Include_File_Name>

in my installed 3.8 documentation it's under "3.2.5.2 Scene Parsing Options".

(fwiw, you may need to refresh your browser's cache before revisiting the wiki's
'Reference:Keywords' page)


regards, jr.

Post a reply to this message

On 2026-01-05 02:46 (-4), jr wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> ...
>> I am not familiar with 'include_header', and cannot find any mention of
>> it in the documentation or include files.  What does this do?
> 
> to use, add the this to your (global) 'povray.ini' file:
> 
>   include_header = /path/to/defaults.inc
> 
> guessing the path may be optional if the files are stored in same directory.
> 
> this causes the named file to be included, as first thing, before the
> scene/frame parsing gets underway.

This would defeat what I had in mind for the file.  The file would be
referenced by textures.inc, metals.inc, etc., but if the user wants
different defaults, they need to be #declared *before* these other files
are #included.

This is not a problem with the file as I posted it, but I was going to
post a new version of defaults.inc that set assumed_gamma and #default
finish automatically, to save the user a bit of redundancy.  If used via
'Include_Header', the global settings and #defaults would be set before
the scene file has a chance to tell it otherwise.

With my original version, this catch-22 is avoided by including
textures.inc, etc. *after* changing the default idenfifiers, but then
the scene file still has to set assumed_gamma and #default explicitly.

Where is Bald Eagle?  I'm sure he has some good input.

> <wiki.povray.org/content/Reference:Scene_Parsing_Options#Include_File_Name>
> 
> in my installed 3.8 documentation it's under "3.2.5.2 Scene Parsing Options".

Ah, this explains why I couldn't find it.  I looked for it under
keywords, and when it wasn't there. I did a global search on the
documentation, but the search was case sensitive.  In the docs, the word
is mixed case.

> (fwiw, you may need to refresh your browser's cache before revisiting the wiki's
> 'Reference:Keywords' page)

I searched on my local installation, not on the wiki.

Post a reply to this message