 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I must have forgotten something, but I am surprised that it doesn't seem
possible to specify a color for the phong or specular highlight. Am I mistaken
about that?
otherwise would it be possible to make any color one of the possible expected
values for these keywords, so that it would work more similarly to the
reflection syntax? I know about metallic keyword, but I would want to be able
to specify *any* color for highlights.
If not, what workaround do you advice? layered material with transparent colored
diffuse, opaque specular highlight with metallic parameter? I'm not even sure
that's possible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.02.2013 15:17, schrieb Mr:
> I must have forgotten something, but I am surprised that it doesn't seem
> possible to specify a color for the phong or specular highlight. Am I mistaken
> about that?
No, you're perfectly right.
> otherwise would it be possible to make any color one of the possible expected
> values for these keywords, so that it would work more similarly to the
> reflection syntax? I know about metallic keyword, but I would want to be able
> to specify *any* color for highlights.
>
> If not, what workaround do you advice? layered material with transparent colored
> diffuse, opaque specular highlight with metallic parameter?
Exactly that.
> I'm not even sure that's possible.
It should be. The highlights are always there no matter how high you set
the transparenty.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > otherwise would it be possible to make any color one of the possible expected
> > values for these keywords, so that it would work more similarly to the
> > reflection syntax? I know about metallic keyword, but I would want to be able
> > to specify *any* color for highlights.
> >
> > If not, what workaround do you advice? layered material with transparent colored
> > diffuse, opaque specular highlight with metallic parameter?
>
> Exactly that.
>
> > I'm not even sure that's possible.
>
> It should be. The highlights are always there no matter how high you set
> the transparenty.
I tried it, and now I remember what I forgot: I had already tried, and this is
why it won't do for me:
It is inside the same index of a texture_list. and POV tells me it is "expecting
} ...other texture found instead" POV won't accept layered textures inside
texture_lists.
We use those in Blender exporter to convert several materials per object. The
rest of the texture translation code is already quite convoluted to be able to
use transparency maps, along with diffuse color map, bump map and specular map
using several finishes mixed together.
any other workaround?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.02.2013 09:08, schrieb Mr:
> I tried it, and now I remember what I forgot: I had already tried, and this is
> why it won't do for me:
>
> It is inside the same index of a texture_list. and POV tells me it is "expecting
> } ...other texture found instead" POV won't accept layered textures inside
> texture_lists.
>
> We use those in Blender exporter to convert several materials per object. The
> rest of the texture translation code is already quite convoluted to be able to
> use transparency maps, along with diffuse color map, bump map and specular map
> using several finishes mixed together.
>
> any other workaround?
Yup: #define (or #local) the layered texture outside the texture_list,
and you should be fine.
It's just a limitation of the syntax (the comma in texture_list is
optional, so POV-Ray can't tell where a layered texture ends), not of
the inner workings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I second this feature request. I've encountered the same problem - an object
with variable transparency looks fake (too strong specular highlight) and there
is no way to make it variable as well. Colored reflection is also a physical
possibility (glaze of a different color than a substrate).
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you, nice to know that this is being considered.
A few comments:
> - 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.
finish map would really be perfect for modulating roughness, intensity and
reflection parameters. However, it has a disadvantage that you lose the color
information: you get one-parameter (gray) modulation, even if you specify color
for each gray level separately. For full effect (although this would not be used
frequently) you would still need a pigment inside the highlight block.
> - 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).
This is perfect from a physical point of view, as specular reflection is really
simply a fake blurred reflection term for point sources. For rendering purposes,
you probably still want a mixed option (sharp reflections, blurred highlight),
to speed up the rendering if you don't really nead blurred reflections. This is
however easily solved if it is possible to layer reflection/highlight
statements.
If I get wildly creative, I can envision another option (highly speculative):
If there will be a change in syntax, we could make it completely uniform in the
sense of shaders. We technically have a sum
diffuse+specular+reflection+emission. These are really just 4 separate blocks
with different ray sampling distribution (BDRF).
The "pigment" statement now regulates the diffuse and ambient part. But each of
the contributions could have its own pigment and own parameters. This way you
could say
texture {
model [diffuse|phong|blinn|reflection|emission|other ray distribution
functions]
blend_mode [add|overlay]
pigment { for each contribution its own color or pattern }
finish {//model-specific settings:
brilliance,ambient (for diffuse)
roughness/phong_size (for highlights)
fresnel [on/off] (for highlights and reflections)
radiosity [on/off] //sampling of additional rays beside the light rays
sample_lights [on/off] //this would turn off the direct illumination - for
instance, to avoid artifacts for models with very sharp distributions
}
}
This covers absolutely everything. if "model" is not specified, it can default
to diffuse, and for backward compatiblity (if #version<reference version) it can
still calculate phong/specular/reflection statements from finish.
If model is specified, you reproduce all existing things in a uniform way:
diffuse + radiosity off: normal illumination
diffuse + radiosity on: normal illumination + traditional radiosity
reflection + radiosity on: traditional (perfect) reflection - one radiosity ray
per pixel is just the reflection ray
phong + radiosity on: this is the blurred reflection model (radiosity sample
rays distributed according to phong reproduce the blurred reflection)
phong + radiosity off: traditional phong
phong + radiosity on + sample_lights off: no traditional (light-source) phong,
just blurred reflection.
emission: emissive color/pattern, no need to sample radiosity or lights, this
part just contributes to illumination of camera and other parts of the scene
Every "model" can have its own C++ class with different light-sampling and
radiosity-sampling functions for collecting the data, and each could have its
own pigment. Various new shaders can be added without changing the syntax, you
just create a new class that knows how to generate outgoing rays according to
some distribution and calculate weights for light rays.
The blend_mode is necessary to allow adding of contributions (just adding light
intensity) and normal texture layering (alpha channel, opaque color covers what
is underneath). For diffuse, it would default to "overlay", and for other
contributions, it would default to "add", so you would normally not need to set
this at all, unless you want special effects.
A reflective red sphere with normal highlight and blue-tinted reflection could
have a texture like:
texture {
model diffuse
pigment { color rgb <1,0,0> }
//default, no finish needed unless you want to change something
}
texture {
model phong
pigment { color rgb 0.5 }
finish { roughness 0.05 fresnel on }
}
texture {
model reflection
pigment { color rgb <0,0,1> }
finish { intensity 0,1 fresnel on }
normal {} //reflections can have perturbed normals even if other parts don't
}
Again, this is simply what I imagine would be the cleanest and most flexible
syntax. Maybe this gives you some ideas, or maybe not.
best,
Simon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 22.02.2013 09:08, schrieb Mr:
>
> > I tried it, and now I remember what I forgot: I had already tried, and this is
> > why it won't do for me:
> >
> > It is inside the same index of a texture_list. and POV tells me it is "expecting
> > } ...other texture found instead" POV won't accept layered textures inside
> > texture_lists.
> >
> > We use those in Blender exporter to convert several materials per object. The
> > rest of the texture translation code is already quite convoluted to be able to
> > use transparency maps, along with diffuse color map, bump map and specular map
> > using several finishes mixed together.
> >
> > any other workaround?
>
> Yup: #define (or #local) the layered texture outside the texture_list,
> and you should be fine.
>
> It's just a limitation of the syntax (the comma in texture_list is
> optional, so POV-Ray can't tell where a layered texture ends), not of
> the inner workings.
ACtually this workaround will work for me only in the case where my exported
mesh doesn't use Blender "specular texture"; for translating those to POV, I am
using a piment pattern to map over two different finishes, POV won't then layer
textures over a piment pattern, no matter what.
It's been more than two years now since I first tried implementing complete
shader translation from Blender and I have to give up once again, but thanks to
your advice I think I will be able to take it one step further and enable
colored specular highlights when no map influences them.
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
