Am 07.04.2016 um 18:32 schrieb Le_Forgeron:

> Now, I know we have a "fresnel" qualifier, but could we have some easier keyword for
the alternative diffuse models ?
> (and "lambert" is not even mentionned, that is a bit unfair)
> 
> There is no chance to remember the exact spelling without double-checking the
documentation...
> 
> Something like "dusty" for oren_nayar, or "rough" ? and I have no clue for
lommel_seeliger.

That's a no-go, as far as I'm concerned. Here's why:

"Dustyness" or "roughness" are physical phenomena.

Oren-Nayar and Lommel-Seeliger are two mathematical approaches that
differ in the underlying model and the resulting formulae, but they are
both designed to model dustyness and roughness, and they are equally
valid attempts to approximate these phenomena.

If we call one "rough", what do we call the other? "rough2"?

What if at some point in the future we decide to provide yet another
alternative? Minnaert would be a hot candidate, for instance. "rough3"?

The "phong" and "specular" keywords are an ideal showcase of what is
wrong with that approach: The one uses the Phong model, the other the
Blinn-Phong model. One is a tad faster, while the other is a tad more
precise, but both are equally valid models to compute specular
highlights. Yet only one has the honor of carrying the generic name of
the phenomenon. (And, as a matter of fact, the name is misleading:
"specular" would normally encompass not only specular highlights but
also specular reflection -- which in turn we just call "reflection",
although that therm could also encompass diffuse reflection. In short,
keyword choice is a bitch. "albedo" turns out to have been a bad pick,
too, because besides the white-sky albedo it is actually meant to denote
there's also blue-sky albedo, black-sky albedo, geometric albedo, bond
albedo, single-scattering albedo, and what-have-you-not albedo, all
meaning different things.)


As for being difficult to remember, there are two approaches to solve this:


(A) Provide a standard include file with generic finish macros, just
like we provide standard include files with pigments, colours and some
such. You could have one "Rough" finish, that may happen to invoke the
Oren-Nayar model. Or the Lommel-Seeliger model. Or Minnaert. Or
what-have-you. If all you want is /any/ rough finish, any of the
mathematical models is good enough.

Note that work on this could be started any moment, by whoever wants to
assist in improving POV-Ray.


(B) Overhaul the entire finish syntax to define materials based on the
physical phenomena that need modelling, and _optionally_ the
mathematical model(s) to use (with defaults being picked otherwise),
maybe like so:

    finish {
      roughness 0.05
      reflection {
        // how to model light reflected in a specular manner
        brightness {
          // variable reflection
          minimum 0.0
          maximum auto // compute from ior
          #if (!UseFresnel)
            linear // just use a linear interpolation model
          #elseif (UseSchlickApproximation)
            schlick // use schlick's approximation
          #else
            fresnel // use fresnel model
          #endif
        }
        light_source {
          // how to model light coming from a light_source
          blinn_phong
        }
        environment {
          // how to model light coming from other objects
          raytracing { blur off }
        }
      }
      diffuse {
        // how to model light reflected diffusely
        brightness 0.5
        conserve_energy on // compensate for variable reflection
        light_source {
          oren_nayar
        }
        environment {
          #if (UseRadiosity)
            radiosity
          #elseif (UseMonteCarlo)
            raytracing { blur on } // Monte Carlo!
          #else
            constant 0.2 // our current "ambient"!
          #end
        }
      }
      refraction {
        // how to model light transmitted in a "specular" manner
        conserve_energy on // compensate for variable reflection
        light_source {
          raytracing { blur off } // uses looks_like
        }
        environment {
          photons
          raytracing { blur off }
        }
      }
      translucency {
        // how to model light transmitted in a diffuse manner
        ...
    }

As a matter of fact that's the general direction I'd personally prefer
to go, but it's still a loooong way to get there. So in the meantime,
new features need to be hooked up in whatever way they fit best with the
current syntax.

Post a reply to this message