Am 28.02.2013 23:57, schrieb Simon Copar:

> I posted this request as FS#263 on the bugtracker. It is a nice possibility for
> an extension in next version (3.7.1 or something). The old syntax
> specular <number>
> could be retained for compatibility, and a new syntax with curly braces could
> provide a full-featured specification, similar to pigment:
>
> specular {
>    specular | phong | other future algorithm names //type
>    <scalar> | <color> | <pattern> | <function>
>    roughness <number>
>    [metallic]
>    [copy_transparency]
>    [optional transforms, warps, turbulence]
> }
>
> This would also migrate all highlight-related keywords in the same block, which
> is more consistent with other blocks (such as reflection).
>
> Does any of the official developers think this is an acceptable idea? It would
> not be difficult to implement, just use Pigment_Function class that already
> exists (yes, I looked at the code). I could take my time and write a patch for
> this.

As one of the official developers, the highlights syntax has actually 
bothered me for quite a while now, with my main point of concern being 
the parameterization of the existing feature:

- With the highlight brightness settings specifying the maximum 
brightness of the highlight, rather than how much of the incoming light 
would be reflected, it used to be difficult to find realistic highlight 
brightness settings to go along with a particular reflection brightness. 
(This has been addressed by now with the "albedo" keyword.)

- The specular and phong models use totally different parameterizations 
for how blurry the highlight looks, making it non-trivial to switch 
between the two highlight models. It also means that if blurred 
reflections are implemented some day, whatever parameterization is used 
for that one will make it non-trivial to pick matching settings for at 
least one of the highlight models. So ideally we should have 
"phong_roughness" instead of "phong_size" (or a "specular_size" instead 
of "roughness", but personally I prefer the roughness-style 
parameterization). Or change the syntax "somehow" to use the same 
keyword for both highlight models; one such approach would indeed be to 
have just one "highlights" block (I wouldn't use the "specular" keyword 
there) with one setting being the highlight model to use.

- What is completely missing so far is fresnel-based attenuation for 
highlights, because in reality highlights vary with angle of incicence 
just like reflection does. Again having a dedicated "highlights" block 
would make it easy to come up with a consistent syntax (just use the 
"fresnel" keyword in the "highlights" block like you would in the 
"reflection" block).

Some other thoughts on your suggestion:

- Pattern-based control over highlights is indeed quite a frequent 
feature request; to some degree similar effects can be achieved by using 
a texture map, but this is only half the truth: Where extreme but 
gradual changes in highlight roughness are desired, texture maps won't 
get you anywhere. However, I think this is better catered for by a 
"finish map"; after all, when you vary highlights chances are that you 
will also want to vary diffuse and specular reflection along with it.

- There has been arguing that a single highligts block would be too 
limiting, because specular and phong highlights couldn't be used 
together on the same surface anymore. I disagree with that view, 
because: (A) The reason given is that sometimes it might be desirable to 
have both dull and sharp highlights on the same material; however, I 
find it rather arbitrary to limit the number of highlights per texture 
to 2, and also require that one be phong and the other blinn_phong; if 
there is real need for multiple highlights per basic texture, this would 
better be catered for by allowing an arbitrary number of highlights 
blocks per finish. (B) It isn't difficult to achieve multiple highlights 
per material by using layered textures.

- The internal data structures used for pigment, texture and normal maps 
are subject to change in the near future, from the current C-style 
structs to C++-style classes, so this might not be the moment to 
implement a finish_map feature.

- One thing that should be considered when developing a new highlights 
syntax is that some day we might see blurred reflections, in which case 
a direct correlation between reflection and highlights settings would be 
strongly desirable. So maybe the highlights settings should be part of 
the reflection block in the first place, in which case we'll possibly 
end up with no other highlights-specific parameter than just the model 
to use (the "roughness" parameter would be shared with blurred reflections).

Post a reply to this message