I had a bit of time to re-read the whole thread after second coffee kicked in.
Below find Richard's discussion, and my labeled comments.
I don't regularly use ini files or command line flags, so this can likely be
supplemented by jr, who is much more well-versed in their implementation.

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.

BE: Well, our inability to query any number of things is a crippling
disadvantage that requires workarounds, such as assigning values to
variable in SDL and then passing those into the definitions of scene
objects such as is done with the camera in screen.inc

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.

BE: I would agree, and further comment about many unreasonable burdens that
are borne by the users.

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?

BE:  I think that it's time for a lot of these files to be rewritten,
both in form and substance.  I might suggest a standard
"Distribution_Standard_Defaults.inc" that:
1. gets checked for by any include file seeking to use the values therein.
Sanity checks and guards can be used in case the file is corrupt or missing.

2. It would be wise to allow the user to set values that can either be
overwritten
by the include file, or vise-versa.  Setting the actual value and then invoking
the
include file would overwrite the previous user-declared values, and setting a
Identifier_Override identifier to the value would keep the value in place.
writing a macro in "Distribution_Standard_Defaults.inc" to update values would
allow
the obvious updating of the value hierarchy.

3. As I have suggested before, "Distribution_Standard_Defaults.inc" ought to be
a sort of proxy
that includes the actual include file used, which is the latest
semantic-versioning include file.
That way a versioning history can be internally and automatically maintained,
and upgrading to the latest
include file version is as simple as adding the new include file to the
directory and pasting the filename into
"Distribution_Standard_Defaults.inc"
(The reasoning here is that all dependent files just use the proxy name, and so
don't need to be edited in any way. The proxy include file then acts as a
pointer to the latest version of the "real" include file)

The texture files can then be rewritten to use default values, dictionaries, etc
to construct the texture.
I would suggest that the textures be rewritten as macros, so that the user can
invoke them with different arguments if desired, and then the last section of
the include file just runs all of the macros to set the default textures.

These sorts of problems, workarounds, and solutions should be able to be used as
a template for 4.0 parser and source code to avoid and/or handle these problems
within the distribution.

In the absence of a primary developer, or dev group, I believe that the most
efficient way forward will be to construct a fully parallel "distribution"
package that we current active users develop, maintain, and USE, so that we can
iron all of this out and have it fully implemented once active development on
4.0 resumes.


- BE

Post a reply to this message