I tried the subsurface feature for the first time (RC6) and noticed
that normals no longer seemed to have a visible effect on lighting, e.g.
testing with an object such as

sphere
{
   y,1
   pigment {color White}
   normal  {bozo 100 scale 0.2}
   // finish  {subsurface {translucency 0.2}}
}

Is this a known limitation? If so it should probably be documented
in the warning section of the subsurface reference.

Also, if I understand correctly SSLT completely replaces the lighting
model. I would have found it to be more intuitive if it were just some
additional effect (similar to a reflection block, at least without
conserve_energy). Possibly by defaulting the SSLT contribution with
a diffuse of 0 unless an explicit diffuse appears in the subsurface
block (in which case it would be physically correct, but optional, to
use diffuse 0 for the old model. Not sure if this is feasible, though.

Post a reply to this message

Am 22.09.2012 22:16, schrieb Christian Froeschlin:
> I tried the subsurface feature for the first time (RC6) and noticed
> that normals no longer seemed to have a visible effect on lighting, e.g.
> testing with an object such as
>
> sphere
> {
>    y,1
>    pigment {color White}
>    normal  {bozo 100 scale 0.2}
>    // finish  {subsurface {translucency 0.2}}
> }
>
> Is this a known limitation? If so it should probably be documented
> in the warning section of the subsurface reference.

I never paid attention to this before, but you're right: Currently the 
algorithm doesn't properly respect perturbed normals. The reason is that 
this would require extra effort (both in terms of speed, but also and 
especially in terms of programming) to handle averaged and layered 
textures. There'll come a time to dig into this, but not yet.

> Also, if I understand correctly SSLT completely replaces the lighting
> model. I would have found it to be more intuitive if it were just some
> additional effect (similar to a reflection block, at least without
> conserve_energy). Possibly by defaulting the SSLT contribution with
> a diffuse of 0 unless an explicit diffuse appears in the subsurface
> block (in which case it would be physically correct, but optional, to
> use diffuse 0 for the old model. Not sure if this is feasible, though.

 From the math behind SSLT, there is no such thing as an "SSLT 
contribution" - the formulae totally /replace/ the conventional diffuse 
term.

To obtain a pure SSLT-to-diffuse "delta" image, you could render the 
scene once with only regular diffuse, and once with SSLT enabled, and 
from the resulting images generate a difference. (Note though that 
SSLT's light "bleeding" feature does not only brighten up dark areas, 
but also darken bright ones in turn; so the delta may be negative, and 
therefore OpenEXR is highly recommended as file format of choice.)

Post a reply to this message

clipka wrote:

> To obtain a pure SSLT-to-diffuse "delta" image, you could render the 
> scene once with only regular diffuse, and once with SSLT enabled, and 
> from the resulting images generate a difference.

Instead, I tried to average a plain texture with normals and
the subsurface texture, but the results are not very convincing.
Probably because small bumps on the surface are the features that
should be most affected by subsurface lighting.

Isosurface it is, then ;) (see p.b.i)

Some additional problems I encountered:

1. I tried to set "mm_per_unit 100" in the global settings block,
but this yielded the parse error "Parse Error: No matching } in
'subsurface', mm_per_unit found instead".

2. I had trouble with the help in the windows editor:
- Pressing F1 only seems to work for some types of keywords (for
example, I could use it to get help for camera or subsurface, but not
for location, aperture, samples, or global_settings).
- Also, when the topic was not unique (e.g. camera), and the help
was not previously open, the topic selector did not close on display
or double click and moved to the background. In this situation the
the search/replace dialog will not open.

Post a reply to this message

Am 23.09.2012 20:45, schrieb Christian Froeschlin:

> Some additional problems I encountered:
>
> 1. I tried to set "mm_per_unit 100" in the global settings block,
> but this yielded the parse error "Parse Error: No matching } in
> 'subsurface', mm_per_unit found instead".

Note that mm_per_unit is /not/ a subsurface parameter; although SSLT is 
currently the only feature using it, other features might follow 
somewhen in the future.

> 2. I had trouble with the help in the windows editor:
> - Pressing F1 only seems to work for some types of keywords (for
> example, I could use it to get help for camera or subsurface, but not
> for location, aperture, samples, or global_settings).
> - Also, when the topic was not unique (e.g. camera), and the help
> was not previously open, the topic selector did not close on display
> or double click and moved to the background. In this situation the
> the search/replace dialog will not open.

I do remember that we did have some known issues with the online help 
index, but I can't recall off the top of my head whether that was in RC5 
or RC6. Jim is more familiar with the current status.

Post a reply to this message

clipka wrote:

> Note that mm_per_unit is /not/ a subsurface parameter; although SSLT is 
> currently the only feature using it, other features might follow 
> somewhen in the future.

thanks, that explains it ;)

Post a reply to this message