When it works, it does an amazing job... just a bit slowly: 41m for this
shot without area light. For my current setup, with a lot of dominoes
and two big area lights, I feel it could take some days to finish at
wallpaper size.

--
Jaime

Post a reply to this message

Attachments:
Download 'domino-04.jpg' (41 KB)

Preview of image 'domino-04.jpg'

On 14-8-2012 9:24, Jaime Vives Piqueres wrote:
> When it works, it does an amazing job... just a bit slowly: 41m for this
> shot without area light. For my current setup, with a lot of dominoes
> and two big area lights, I feel it could take some days to finish at
> wallpaper size.
>

Indeed; the sss looks very good.

Thomas

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> When it works, it does an amazing job... just a bit slowly: 41m for this
> shot without area light. For my current setup, with a lot of dominoes
> and two big area lights, I feel it could take some days to finish at
> wallpaper size.
>
> --
> Jaime

Nice. How about examples of when it doesn't work and how to fix that?

Post a reply to this message

On 14/08/12 16:14, jhu wrote:
> Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
>> When it works, it does an amazing job... just a bit slowly: 41m for
>> this shot without area light. For my current setup, with a lot of
>> dominoes and two big area lights, I feel it could take some days to
>> finish at wallpaper size.
>>
>> -- Jaime
>
> Nice. How about examples of when it doesn't work and how to fix
> that?
>

   Yup... I've to setup a short scene showing the problem, if I can
reproduce it (I've deleted the original offending code in a hurry).

   As for how to fix it, that should be clipka job (if there is any bug,
of course: I just switched to another approach without further testing
of the problem).

--
Jaime

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> On 14/08/12 16:14, jhu wrote:
>
>    As for how to fix it, that should be clipka job (if there is any bug,
> of course: I just switched to another approach without further testing
> of the problem).

I realize SSLT it's still quite experimental and I've played with it quite a
bit, but finally decided that subsurface just doesn't yet work properly when
dealing with complex textures, especially regarding the pigment block. For a
simple candle it looks nice (or your dominoes), but having the subsuface color
in the finish block seems to override anything in the pigment block, with is
pretty much unusable for standard scenes. Also, I've had a lot trouble using it
with radiosity and finally gave up. It also seems to exclude anything other than
the subsurface block within a finish block, so reflections, specular, etc. don't
work quite right either.

Maybe Christoph can set us straight on these points with some new example
scenes... eh, Mr. Lipka?

At this point, doing a separate pass for subsurface is the only viable solution
that I've found, and that works quite well when composited (via screen) into the
standard shot (as long as every non-SSLT suface in the scene is textured
completely non-diffuse black).

--------------------------------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

> Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
>> On 14/08/12 16:14, jhu wrote:
>>
>>     As for how to fix it, that should be clipka job (if there is any bug,
>> of course: I just switched to another approach without further testing
>> of the problem).
>
> I realize SSLT it's still quite experimental and I've played with it quite a
> bit, but finally decided that subsurface just doesn't yet work properly when
> dealing with complex textures, especially regarding the pigment block. For a
> simple candle it looks nice (or your dominoes), but having the subsuface color
> in the finish block seems to override anything in the pigment block, with is
> pretty much unusable for standard scenes. Also, I've had a lot trouble using it
> with radiosity and finally gave up. It also seems to exclude anything other than
> the subsurface block within a finish block, so reflections, specular, etc. don't
> work quite right either.
>
> Maybe Christoph can set us straight on these points with some new example
> scenes... eh, Mr. Lipka?
>
> At this point, doing a separate pass for subsurface is the only viable solution
> that I've found, and that works quite well when composited (via screen) into the
> standard shot (as long as every non-SSLT suface in the scene is textured
> completely non-diffuse black).
>
> --------------------------------------------------------------------------
> www.McGregorFineArt.com
>
>

Did you try with version 3.7RC6?
In the previous implementation, the colour was totaly dictated by the 
subsurface components.
In the actual version, you set the translucency. This define the mean 
free travel of light on the material and play well with most pigments. 
You only need to make sure that the pigment don't contain any zero 
component and the translucency also don't have zeros. 0.00001 is OK, 0.0 
is not.

It's also been adjusted to work with radiosity.



Alain

Post a reply to this message

Am 18.08.2012 23:59, schrieb Robert McGregor:

> I realize SSLT it's still quite experimental and I've played with it quite a
> bit, but finally decided that subsurface just doesn't yet work properly when
> dealing with complex textures, especially regarding the pigment block. For a
> simple candle it looks nice (or your dominoes), but having the subsuface color
> in the finish block seems to override anything in the pigment block, with is
> pretty much unusable for standard scenes. Also, I've had a lot trouble using it
> with radiosity and finally gave up. It also seems to exclude anything other than
> the subsurface block within a finish block, so reflections, specular, etc. don't
> work quite right either.
>
> Maybe Christoph can set us straight on these points with some new example
> scenes... eh, Mr. Lipka?

When was the last time you tried?

Early SSLT parameterization did indeed use two very low-level color 
coefficients that fully determined the object colour, overriding the 
pigment block; this is no longer true however (at least it shouldn't 
be), as the two coefficients are now automatically computed from the 
classic pigment and a "translucency" color parameter.

Likewise, there was a time when SSLT did not account for indirect 
illumination, but this, too, has been changed, and it does use radiosity 
by now.

As for all the other stuff in the finish block - yes, IIRC there also 
was a time when SSLT did not play nice with them, but that's been a 
while as well.

Bottom line: If it has been a while since you last tried SSLT, I'd like 
to encourage you to play around with it once again.

Post a reply to this message

Robert, as Alain and clipka said, you should try the last incarnation...
works fine here: in fact, I was not able to reproduce the artifacts I
got with the pool balls: surely I was doing something really weird with
the texture maps.

And it's easier to setup than media, more consistent and better looking,
but unfortunately it's very slow, at least for scenes which consist
mostly on translucent objects (as much as a x10 increase in rendering
time for this shot). Oh, well...

--
Jaime

Post a reply to this message

Attachments:
Download 'domino-13-sslt.jpg' (73 KB)

Preview of image 'domino-13-sslt.jpg'

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Robert, as Alain and clipka said, you should try the last incarnation...
> works fine here: in fact, I was not able to reproduce the artifacts I
> got with the pool balls: surely I was doing something really weird with
> the texture maps.
>
> And it's easier to setup than media, more consistent and better looking,
> but unfortunately it's very slow, at least for scenes which consist
> mostly on translucent objects (as much as a x10 increase in rendering
> time for this shot). Oh, well...
>
> --
> Jaime


(and the radiosity fixes were implemented). Thanks for the tips and for setting
me straight guys, much appreciated.

After reading through all the docs and playing around a bit today I came up with
this simple scene to test things out with radiosity. The top version uses three
identical superellipsoids lit by an area light and two shadowless fill lights.
In the bottom version the only change is the addition of subsurface in the
finish block of each cube, using a different translucency color for each. Each
cube is one POV-unit, with mm_per_unit 5.



The only drawback is that the SSLT version took 60 times longer to render than
the non-SSLT version. 20% of this extra time is for the SSLT calculations, but

the SSLT.

A very useful optimization for subsurface rendering would be a parameter to
ignore area light calculations within the subsurface material (if desired). This
would speed up render times considerably, while still keeping the realistic soft
shadows. For instance, when I rendered a version of this scene /without/ the
area light the SSLT version only took 5 times longer than the non-SSLT version
/with/ area light.

--------------------------------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

Attachments:
Download 'sslt_blocks.jpg' (162 KB)

Preview of image 'sslt_blocks.jpg'

Am 30.08.2012 21:51, schrieb Robert McGregor:



I really love to hear that.

> The only drawback is that the SSLT version took 60 times longer to render than
> the non-SSLT version. 20% of this extra time is for the SSLT calculations, but

> the SSLT.

That's not really true; say you have an SSLT marble floor, a huge area 
light, and some object casting a shadow on the floor: If we'd ignore the 
area light and treat it as a point light, we'd get quite a sharp shadow, 
softened only by the marble's SSLT effect; this is because SSLT doesn't 
/complement/ the classic diffuse surface mechanism, but /replaces/ it.

But there's indeed still room for optimization: For SSLT, we could get 
away with much lower area light quality.


What area light settings did you use? I guess for your scene it'll make 
a huge difference whether you're using "adaptive 1" or "adaptive 0".

Post a reply to this message