Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> The algorithm is designed to give realistic results at a scale of 10 mm per
> POV-Ray unit by default; for other scales, place the following statement in
> the global_settings section:
>
>   mm_per_unit NUMBER

Hi I'm new here, I'm a blenderhead. this SSTL feature attracted me to Povray.
What a beautiful piece of software!
My question is whether this mm_per_unit option was added just for SSTL and
applies only to it (which is not clued by the currently chosen keyword) or if
it will also have an incidence over the whole scene's scale and stuff like
photons, radiosity scale etc...?
Using Blend2pov and trying to make a skin shader, my current scale is 1 meter
per Blender Units, and I guess keeping the same in Pov units would make it
easier for me to get more intuitive and predictable results with other Pov
features later. So I tried mm_per_unit 1000 but I could not get the same
translucency with SSTL as I could achieve with mm_per_unit 100, which is indeed
closer to what the algorithm is optimized for.

Post a reply to this message

> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> The algorithm is designed to give realistic results at a scale of 10 mm per
>> POV-Ray unit by default; for other scales, place the following statement in
>> the global_settings section:
>>
>>   mm_per_unit NUMBER
> 
> Hi I'm new here, I'm a blenderhead. this SSTL feature attracted me to Povray.
> What a beautiful piece of software!
> My question is whether this mm_per_unit option was added just for SSTL and
> applies only to it (which is not clued by the currently chosen keyword) or if
> it will also have an incidence over the whole scene's scale and stuff like
> photons, radiosity scale etc...?
> Using Blend2pov and trying to make a skin shader, my current scale is 1 meter
> per Blender Units, and I guess keeping the same in Pov units would make it
> easier for me to get more intuitive and predictable results with other Pov
> features later. So I tried mm_per_unit 1000 but I could not get the same
> translucency with SSTL as I could achieve with mm_per_unit 100, which is indeed
> closer to what the algorithm is optimized for.
> 
> 
> 

The mm_per_unit is ONLY used for the new SSLT feature. Before it's 
introduction, that keyword did not exist. If you try to use it with any 
version older than 3.7 beta 31, the parsing will give you an error about 
an undefined user variable and stop.

This is because, SSLT is dependent on the actual "real" distences 
traveled into the substence.
If you set it to 1000, it's normal that the effect is smaller and less 
pronounced than if it's set to 100. In fact, it will be 10 about times 
less visible.

I don't think that the algorythm is optimised for a value of 100, it's 
just the default value.

Anywhere else, a POV-unit is just an arbitrary unit that can represent 
whatever real world unit you like. Be it a nanometer or a kilo parsec, 
or anything in between.




Alain

Post a reply to this message

> The mm_per_unit is ONLY used for the new SSLT feature.

Thanks! This way I won't fear to change the scale of radiosity or photons along
with it. I was afraid it would change scale of all the rays and make radiosity
or caustics out of scale.

Why not name it "sslt_mm_per_unit" to have a better idea of what it does... ? I
aslo think that naming it sss instead of sstl would be less error prone but who
cares...


> I don't think that the algorithm is optimised for a value of 100, it's
> just the default value.

I get it, only the default value is mm_per_unit 10 (100 was what worked best for
my scene)

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> Hi I'm new here, I'm a blenderhead. this SSTL feature attracted me to Povray.
> What a beautiful piece of software!
> My question is whether this mm_per_unit option was added just for SSTL and
> applies only to it (which is not clued by the currently chosen keyword) or if
> it will also have an incidence over the whole scene's scale and stuff like
> photons, radiosity scale etc...?

It is currently used for SSLT (Subsurface Light Transport) only, and was in fact
added specifically for it. The sole reason why it's not in the "subsurface{}"
block is that it's not an inherently SSLT-related parameter.

It is also not guaranteed to be there to stay. The whole SSLT implementation is
still at alpha stage, from the inner workings to the SDL syntax.

On the other hand, future versions *might* extend its use to other
distance-dependent effects in future, like atmospheric fog, media and the like.
POV-Ray has previously avoided any reference to a particular scale, but maybe
the SSLT feature may serve as a showcase how scale might be handled in POV-Ray
consistently.

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> Why not name it "sslt_mm_per_unit" to have a better idea of what it does... ?

(1) Imagine some feature coming up somewhen in the future that would need a
realistic scale of reference as well: Would that "borrow" the
"sslt_mm_per_unit" value, or add its own redundant parameter?

It really does what it says: It provides an actual scale of reference for all
effects that use such a scale. It just so happens that SSLT is currently the
only one that does.

(2) SSLT is alpha-stage, and any syntax it introduces is as experimental as the
code itself (maybe even more so).


> I aslo think that naming it sss instead of sstl would be less error prone but who
> cares...

(3) It's "SSLT" ("Subsurface Light Transport"), not "SSTL".

(4) It is implemented using an approach discussed in the paper "A Practical
Model for Subsurface Light Transport" by Henrik Wann Jensen et al.; I'm not
sure whether there is any technical difference in the term as opposed to
"Subsurface Scattering", but if there is, SSLT would obviously be the more
appropriate term.

(5) You will notice that the current syntax uses neither "sss" nor "sslt", but
"subsurface".

(6) see (2).


> > I don't think that the algorithm is optimised for a value of 100, it's
> > just the default value.
>
> I get it, only the default value is mm_per_unit 10 (100 was what worked best for
> my scene)

That may be due to the coefficients you picked for the material ;)

Post a reply to this message

> (3) It's "SSLT" ("Subsurface Light Transport"), not "SSTL".

I made it on purpose :)

> (5) You will notice that the current syntax uses neither "sss" nor "sslt", but
> "subsurface".

True... The rest doesn't matter.

> That may be due to the coefficients you picked for the material ;)

Yes I got through so much trial and error because I didn't find examples nor any
data on real world "sigmas" I must also confess, I din't understand what
1/mm as the way to express these coefficients meant. I hope I'm not bohering you
guys by giving noob feedback on still undocumented beta.

Post a reply to this message

Mr schrieb:
>> That may be due to the coefficients you picked for the material ;)
>>     
>
> Yes I got through so much trial and error because I didn't find examples nor any
> data on real world "sigmas" I must also confess, I din't understand what
> 1/mm as the way to express these coefficients meant. I hope I'm not bohering you
> guys by giving noob feedback on still undocumented beta.
>
>   
The original Jensen et al. paper has actual values for some materials - 
see Figure 5 (b) on page 5:

http://graphics.stanford.edu/papers/bssrdf/bssrdf.pdf

The sigma[a] coefficients basically specify how much absorption a light 
ray of a given wavelength suffers, per mm travelled in the medium (hence 
the 1/mm dimension; that's "odometer" distance btw, not simply |A-B|); 
the sigma-prime[s] coefficients specify how many scattering events a 
light ray of a given wavelength suffers on average (again per mm 
travelled in the medium), multiplied by a correctional factor to account 
for non-isotropic scattering.

These coefficients are admittedly hard to use and non-intuitive, as it 
is difficult to predict the resulting apparent material color, so I 
expect future versions to add another layer to automatically compute 
fitting coefficients, based on a user-specified apparent material color 
and some other RGB parameter to control the "waxiness" of the material 
(probably the "mean free path", which should be intuitive enough for 
this purpose).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> The original Jensen et al. paper has actual values for some materials -
> see Figure 5 (b) on page 5:
>
> http://graphics.stanford.edu/papers/bssrdf/bssrdf.pdf
>
> The sigma[a] coefficients basically specify how much absorption a light
> ray of a given wavelength suffers, per mm travelled in the medium (hence
> the 1/mm dimension; that's "odometer" distance btw, not simply |A-B|);
> the sigma-prime[s] coefficients specify how many scattering events a
> light ray of a given wavelength suffers on average (again per mm
> travelled in the medium), multiplied by a correctional factor to account
> for non-isotropic scattering.

Great resource, at least that gives me some reference values expressed the same
way as the expected input... right? what does the odometer measure change...?
(from the point of view of a user referring to the said paper?)

> These coefficients are admittedly hard to use and non-intuitive, as it
> is difficult to predict the resulting apparent material colour, so I
> expect future versions to add another layer to automatically compute
> fitting coefficients, based on a user-specified apparent material colour
> and some other RGB parameter to control the "waxiness" of the material
> (probably the "mean free path", which should be intuitive enough for
> this purpose).

Why not take it as an opportunity of giving Blender and Povray a common
approach? (it could happen working from both sides since Blender is being
rewritten)? It might help later... I'm not  a coder though and will use
whatever coders implement, or at least try to :)


A little off topic, if you want I can post in a new thread?
I'm experiencing quite heavy render times with SSTL
(still have to check this but it seemed strangely faster with fast radiosity
than without)

Anyway I suppose I need to balance with alternatives for other, but secondary
SSSish materials in my scene... so I'm wondering how does the fastSSS macro by
Samuel Benge compare to SSTL regarding realistic (human) look and rendering
times? or even maybe to directly using scattering media? I'm not at all
questionning the usefullness of SSTL. In fact it seemed the easiest to use from
Pov skin techniques I tried so far) I would also like to avoid wasting too much
time on any obsolete solution before searching for something faster to compute
(Sorry that sounds so demanding!)

Post a reply to this message

Mr schrieb:
>> http://graphics.stanford.edu/papers/bssrdf/bssrdf.pdf
>>
>> The sigma[a] coefficients basically specify how much absorption a light
>> ray of a given wavelength suffers, per mm travelled in the medium (hence
>> the 1/mm dimension; that's "odometer" distance btw, not simply |A-B|);
>> [...]
> 
> Great resource, at least that gives me some reference values expressed the same
> way as the expected input... right? what does the odometer measure change...?
> (from the point of view of a user referring to the said paper?)

I just mentioned the "odometer" for people unfamiliar with the paper.

> Why not take it as an opportunity of giving Blender and Povray a common
> approach? (it could happen working from both sides since Blender is being
> rewritten)? It might help later...

Having the same "native" parameters as the front-end would be of benefit 
of course; however, (a) Blender is not the only software that can be 
used as a front-end, (b) I have no idea whether Blender cares about the 
physical background of subsurface scattering or just goes for the 
effect, and (c) at least as far as I'm personally concerned, I have 
decided to despise blender due to its catastrophic interface.

If the Blender developers are smart enough, though, *and* intend to 
define parameters that have any physical basis whatsoever, I wouldn't be 
surprised if they used the re-parameterization outlined in "A Rapid 
Hierarchical Rendering Technique for Translucent Materials" (again by 
Jensen et al., though the al.s are different ;-)), section 4, and 
therefore come up with the very same parameters that POV-Ray is likely 
to use (see 
http://graphics.ucsd.edu/~henrik/papers/fast_bssrdf/fast_bssrdf.pdf)

> A little off topic, if you want I can post in a new thread?
> I'm experiencing quite heavy render times with SSTL
> (still have to check this but it seemed strangely faster with fast radiosity
> than without)

The current SSLT implementation in POV-Ray is still very naive, without 
any optimization whatsoever, and therefore computationally extremely 
heavy. (I can't imagine how radiosity would speed it up though.)

Future versions will implement caching mechanisms, probably similar to 
what raidisity does.

> Anyway I suppose I need to balance with alternatives for other, but secondary
> SSSish materials in my scene... so I'm wondering how does the fastSSS macro by
> Samuel Benge compare to SSTL regarding realistic (human) look and rendering
> times? or even maybe to directly using scattering media?

Currently, the other approaches are very likely to do a better job as 
far as quality is concerned (the SSLT code suffers heavily from an 
inferior random number generator); as for speed, I have no experience 
with the fastSSS macro, but as it does a lot of "cheating" I expect it 
to be quite fast; media might be about as computationally intensive as 
the current SSLT code.

The power of the SSLT code is yet to be unleashed; the major benefits 
will be ease of use and high realism, which I expect to come at a 
reasonable price regarding performance (probably comparable to radiosity).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> >> http://graphics.stanford.edu/papers/bssrdf/bssrdf.pdf
Ah using them feels so much more relaxing! they work! :)

> at least as far as I'm personally concerned, I have
> decided to despise blender due to its catastrophic interface.
Like so many people not without reason... anyway in case you wouldn't know, the
2.5 rewriting aims to attract precisely people more used to standard
customizable interfaces while keeping its present strengths (though you might
not consider them as such)I would be glad to help any Pov user wanting to
approach/stay away from blender or Blender users wanting to try blend2pov if I
can.

> If the Blender developers are smart enough, though, *and* intend to
> define parameters that have any physical basis whatsoever, I wouldn't be
> surprised if they used the re-parameterization outlined in "A Rapid
> Hierarchical Rendering Technique for Translucent Materials" (again by
> Jensen et al., though the al.s are different ;-)), section 4, and
> therefore come up with the very same parameters that POV-Ray is likely
> to use (see
> http://graphics.ucsd.edu/~henrik/papers/fast_bssrdf/fast_bssrdf.pdf)

Maybe:
The few included presets are exactly the ones from the first paper you pointed
me to (apple, chicken, ketshup etc...) Also when we use SSS in Blender, a first
pass with a grey level image is calculated for each bucket. Isn't that a sign
they did?



> > A little off topic, if you want I can post in a new thread?
> > I'm experiencing quite heavy render times with SSTL
> > (still have to check this but it seemed strangely faster with fast radiosity
> > than without)
>
> The current SSLT implementation in POV-Ray is still very naive, without
> any optimization whatsoever, and therefore computationally extremely
> heavy. (I can't imagine how radiosity would speed it up though.)

I probably messed up in my settings I'll come back later with a simplified scene
otherwise


> Future versions will implement caching mechanisms, probably similar to
> what raidisity does.
Great!

I'll try to post my progress ASAP, is there a way to post images here? Do I have
to start using something like fire bird or outlook?

Post a reply to this message