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