 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Playing around with 3.7's SSS and an old MakeHuman export. There definitely
*is* SSS going on here! :)
So far, I took an RGB value from a photo of a friend. Then I made the pigment 3X
that rgb, and the first vector under subsurface {} to be 3X that vector as well.
Still experimenting.
Post a reply to this message
Attachments:
Download 'subsurf_mh_a021.png' (231 KB)
Preview of image 'subsurf_mh_a021.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The texture for the guy on the left is:
material {
texture {
pigment { color rgb 3*<200/256,134/256,116/256>}
finish { diffuse 0.69
specular 0.1 roughness 0.5
subsurface { 3*<200/256,134/256,116/256>,<0.013, 0.070, 0.145> }
}
normal{granite 0.07 scale 0.1}
}
}
interior { ior 1.3 }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.01.2011 14:32, schrieb gregjohn:
> Playing around with 3.7's SSS and an old MakeHuman export. There definitely
> *is* SSS going on here! :)
>
> So far, I took an RGB value from a photo of a friend. Then I made the pigment 3X
> that rgb, and the first vector under subsurface {} to be 3X that vector as well.
There are some very important things to note here:
* When using SSS, it is vitally important that you set "global_settings
{ mm_per_unit FLOAT }" to a fitting value. If for instance your human
figure happened to be 1.8 POV-Ray units tall, then you'd need to set
"global_settings { mm_per_unit 1000 }" (one POV-Ray unit being
equivalent to 1m)
* The parameters are /not/ colors, but rather some pretty technical
parameters that happen to be different for each color component. They do
/determine/ the effective colour, but in a highly non-intuitive way (one
of the reasons why SSS syntax needs to be changed sooner or later). So I
do recommend starting with the values given in that paper I mentioned,
and tweak your way from there. Plugging in color values there doesn't do
any good.
* Normally you should not need "diffuse" with SSS; in theory, SSS should
be a replacement for diffuse.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here are some new experiments based on a better following of advice of Christoph
and the SIGGRAPH paper:
http://www-graphics.stanford.edu/papers/bssrdf/bssrdf.pdf
I used their Skin1 (I presume African), Skin2 (Caucasian/ Asain), and Chicken1
(completely unexpected-- even for "dark meat".). Compared are my previous
"mistake" of basing the subsurface parameters on a typical skin color, and using
diffusion. And that's all compared to a typical pre-SSS texturing. The image
was labeled in Powerpoint and screen-grabbed from there, but I don't think the
quality is adversely affected.
Comments:
i) The non-SSS looks so hideous I don't know if I want to render a human that
way again.
ii) The paper talks about Fresnel reflection, but these people are a bit too
reflective. And um, I don't know what specular to use.
iii) All the SSS folks have unusually dark fingers and ears. This may be the
limitation of the technique. Lower values of mm_per_unit give darker fingers;
higher values make some of the vertices stand out in an unusual way, one which
is just starting to happen in this image.
iv) With any future experimentation I think I would start adding some diffuse. I
bet that'll fix the dark ears & fingers and make it a little less waxy.
PS. I could "donate" anonymously, CC-Zero license, the mesh exported from this
Circa 2009 version of makehuman, if "povray" wants it.
Post a reply to this message
Attachments:
Download 'sssviews.png' (811 KB)
Preview of image 'sssviews.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"gregjohn" <pte### [at] yahoo com> wrote:
> Here are some new experiments based on a better following of advice of Christoph
> and the SIGGRAPH paper:
> http://www-graphics.stanford.edu/papers/bssrdf/bssrdf.pdf
>
> I used their Skin1 (I presume African), Skin2 (Caucasian/ Asain), and Chicken1
> (completely unexpected-- even for "dark meat".). Compared are my previous
> "mistake" of basing the subsurface parameters on a typical skin color, and using
> diffusion. And that's all compared to a typical pre-SSS texturing. The image
> was labeled in Powerpoint and screen-grabbed from there, but I don't think the
> quality is adversely affected.
>
> Comments:
> i) The non-SSS looks so hideous I don't know if I want to render a human that
> way again.
> ii) The paper talks about Fresnel reflection, but these people are a bit too
> reflective. And um, I don't know what specular to use.
> iii) All the SSS folks have unusually dark fingers and ears. This may be the
> limitation of the technique. Lower values of mm_per_unit give darker fingers;
> higher values make some of the vertices stand out in an unusual way, one which
> is just starting to happen in this image.
> iv) With any future experimentation I think I would start adding some diffuse. I
> bet that'll fix the dark ears & fingers and make it a little less waxy.
>
> PS. I could "donate" anonymously, CC-Zero license, the mesh exported from this
> Circa 2009 version of makehuman, if "povray" wants it.
Very useful experiment. Here are some comments:
-The dark blueish tip of the fingers is something I've met too in my tests. In
other software it's rather the opposite: brighter and more towards the red
extremities. Though it may be caused by a wrong scale for the sss phenomenon, it
shows that the SSS is currently hard to handle, not flexible/forgiving enough,
otherwise, if the mm_per_unit scale is right, maybe it shows that there is some
error somewhere in the current POV implementation?
-for specular or reflection, what is important is that the human body has
different levels of shininess and roughness per each area. so it needs to be
texture mapped, which is a pain (but possible) with the current syntax.
specular_map would be a delight here and the specularity should be as broad as
possible, if using fresnel reflection instead we would then need blurry
reflections which is also a pain (but possible) with the current syntax.
The best you can do for now (so you don't always need to use diffuse) is to use
a much rougher specular and probably a very low value.
-About the dark chicken, it's not a pov mistake, this sss preset also turns out
that dark in Blender. The only way a chicken might look like that is without the
skin and before cooking so maybe CG artists could use this preset as a basis for
raw meat. I suspect it could also be a private joke of the guys who made the
paper, maybe a chocolate chicken... :-)
-About the shiny vertices in the diffuse+sss version, I would rather say they
are accurate as you seem to have used a non smoothed mesh. you can smooth it in
blender 2.5 and export to POV from there now. You'd just need to find the
temporary folder where the blender file is exported. to copy and paste mesh2
data in yours.
-If you made more tests, maybe with all the values of the paper, it would be
nice to have the values for each keyword, and maybe render times?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <nomail@nomail> wrote:Very useful experiment. Here are some comments:
> -The dark blueish tip of the fingers...
I did another experiment where I went across a wide range of mm_per_unit scale.
At low values, everything is blue, then with medium values, only the fingertips
& ears are blue. With higher still, the vertices-- eventually the edges!-- turn
"extra bright". You can already see it here in my image, in the center of the
pectoral muscles. This image actually has worst of both worlds-- blue ears and
shiny vertices.
> -for specular or reflection,
What would a "rougher value" be? This is frankly scary to someone who was
turning his nose at all photorealism not long ago. :)
> -About the shiny vertices in the diffuse+sss version,
> I would rather say they are accurate as you seem
> to have used a non smoothed mesh. you can smooth it in
> blender 2.5 and export to POV from there now. You'd
> just need to find the temporary folder where the
> blender file is exported. to copy and paste mesh2
> data in yours.
Fair enough suggestion, but it's the case that the triangle EDGES also start to
show up as well with higher mm's.
I would also use this platform to repeat my request for the best material for
human skin that could be "donated" to the makehuman project, SSS or no.
Post a reply to this message
Attachments:
Download 'fingers.png' (599 KB)
Preview of image 'fingers.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"gregjohn" <pte### [at] yahoocom> wrote:
> I would also use this platform to repeat my request for the best material for
> human skin that could be "donated" to the makehuman project, SSS or no.
Hi all, regarding the blue ears/fingertips - I'm wondering if there's a bug in
the way the color vector is handled somewhere. The color components seem to be
inverted; for instance red is <0,1,1> instead of <1,0,0>. Here are some color
vectors I was playing with a while back. Note that they're all inverted from
their RGB equivalents, but each renders as it's named color with SSLT:
#declare sslt_aqua = <1, 0, 0>;
#declare sslt_magenta = <0, 1, 0>;
#declare sslt_yellow = <0, 0, 1>;
#declare sslt_blue = <1, 1, 0>;
#declare sslt_red = <0, 1, 1>;
#declare sslt_green = <1, 0, 1>;
#declare sslt_white = <0, 0, 0>;
Regarding scale, rather than fooling with mm_per_unit I just use min_extent()
and max_entent() to examine the actual POV unit size of the mesh and scale to
real-world dimensions based on the SSLT default spacing (since Christoph has the
default spacing set to 10mm/POV unit and that's easy to calculate with).
To get realistic scattering on a human head of real-world dimensions <70mm,
120mm, 90mm> the bounding box of the scaled head mesh should measure <7, 12, 9>.
Scale your object accordingly and then you're ready to consider color and set up
a texture.
It doesn't seem to work putting the pigment (say, an image map) and finish in
the same texture block because then you end up with the dark ears, fingers, etc.
shown earlier in this thread. The SSLT simply tramples the pigment, but a simple
layered texture will suffice in some cases, e.g.:
#declare SSLT_AMT = 0.2;
// SSLT texture
texture {
pigment { rgbt 1 }
finish {
subsurface { <1.09, 1.59, 1.79>, <0.013, 0.070, 0.145>}
}
}
// Standard texture
texture {
pigment { uv_mapping image_map { png "head" transmit all SSLT_AMT } }
normal { uv_mapping bump_map { png "head" } bump_size -3 }
finish {
specular 0.25 roughness 0.02
reflection {0, 0.5 fresnel }
conserve_energy
}
}
Trying to get more realism by using various image maps to define areas of
reflection, specular, and translucency is trickier because POV-Ray won't let you
use this layered technique (the old "cannot layer over a patterned texture"
error). But you can easily build more complex, compound patterned textures to
handle the various maps.
In this example I'm using SSLT_AMT and BASE_AMT to control the blend amounts
between a standard base texture (having image/bump/spec maps and a basic finish)
and an SSLT texture that uses a translucency map to define the translucent
(SSLT) areas, e.g.:
#declare sslt_red = <0, 1, 1>;
// Note: all the SSLT colors seem inverted, is that a bug??
// e.g., red should = <1,0,0> NOT <0,1,1>
// Could be why the chicken looks so dark/bad?
#declare SSLT_AMT = 0.25;
#declare BASE_AMT = 1;
//------------------------------------------------------------------------------
// Test Head
//------------------------------------------------------------------------------
#include "man_head.inc" // your Mesh2 object
#declare Man_Head_ = object { Man_Head_
// with spec/reflection/subsurface mapping
#declare P_Head = pigment { uv_mapping image_map { png "Head" } }
#declare N_Head = normal { uv_mapping bump_map { png "Head" } bump_size -3 }
texture {
average
texture_map {
// SSLT texture
[SSLT_AMT
uv_mapping
image_pattern { png "Head_Transluc" interpolate 2 } // subsurface
amount mask
texture_map {
[0.0
pigment { P_Head }
normal { N_Head }
]
[0.4
pigment { P_Head }
normal { N_Head }
]
[1.0
pigment { rgb 1 }
finish {
//subsurface { <1.09, 1.59, 1.79>, <0.013, 0.070, 0.145> }
// skin2
subsurface { <1.09, 1.59, 1.79>, sslt_red }
}
]
}
]
// Base texture with spec and reflection mapping
[BASE_AMT
uv_mapping
image_pattern { png "HeadSpec" interpolate 2 } //
specular/reflection amount mask
texture_map {
[1
pigment { P_Head }
normal { N_Head }
finish {
specular 0
reflection 0
}
]
[0
pigment { P_Head }
normal { N_Head }
finish {
specular 0.25 roughness 0.05
reflection { 0.05, 0.9 fresnel }
conserve_energy
}
]
}
]
}
}
interior { ior 1 }
}
Center_Object(Man_Head, x+y+z)
Cheers,
Rob
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
Attachments:
Download 'sslt_tests.png' (668 KB)
Preview of image 'sslt_tests.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For the SSLT_AMT a value around 0.15 seems pretty good. Here's a larger render
using:
#declare SSLT_AMT = 0.15;
#declare BASE_AMT = 1;
-------------------------------------------------
www.McGregorFineArt.com
Post a reply to this message
Attachments:
Download 'sslt_test1024.png' (469 KB)
Preview of image 'sslt_test1024.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2011 23:55, schrieb Robert McGregor:
> Hi all, regarding the blue ears/fingertips - I'm wondering if there's a bug in
> the way the color vector is handled somewhere. The color components seem to be
> inverted; for instance red is<0,1,1> instead of<1,0,0>. Here are some color
> vectors I was playing with a while back. Note that they're all inverted from
> their RGB equivalents, but each renders as it's named color with SSLT:
>
> #declare sslt_aqua =<1, 0, 0>;
> #declare sslt_magenta =<0, 1, 0>;
> #declare sslt_yellow =<0, 0, 1>;
> #declare sslt_blue =<1, 1, 0>;
> #declare sslt_red =<0, 1, 1>;
> #declare sslt_green =<1, 0, 1>;
> #declare sslt_white =<0, 0, 0>;
As I already mentioned earlier, the SSLT parameters are /not/ colors,
but a pair of wavelength-dependent coefficients that /determine/ the
color; in POV-Ray, both coefficients are specified for three distinctive
wavelengths (corresponding - not surprisingly - to red, green and blue,
respectively).
The first parameter is the "scattering coefficient", specifying how
often a photon (speaking of the physical thing here, not the POV-Ray
thing) will be scattered (i.e. experience a change of direction) on
average while travelling an "odometer distance" of 1 mm through the
material. (The algorithm presumes that scattering is isotropic; the
sample values are fit to match that presumption.)
The second parameter is the "absorption coefficient", specifying the
probability that a photon will be absorbed while travelling that distance.
The dark blue fingers are indeed the results of bad coefficient
settings; they tell me that the units_per_mm setting is set in a way
that a finger is close to - or even smaller than - the distance a red or
green photon would travel before being scattered. In such situations,
the current surface scattering implementation still gives wrong results,
as it does not account for photons traveling through the object
unscattered. (In reality, with features that small, non-isotropic
scattering would dominate, making the object appear either transparent
or translucent, or something in between.)
Where the bright edges come from I can't tell exactly; what I /can/ tell
you is that (1) the math behind the algorithm was designed for planar
surfaces, and may give less accurate results at edges, and (2) the
algorithm cannot fully compensate for "fake smoothing"; so in essence
you'll need a higher-resolution mesh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/23/2011 09:35 AM, clipka wrote:
> Am 22.01.2011 23:55, schrieb Robert McGregor:
>
>> Hi all, regarding the blue ears/fingertips - I'm wondering if there's
>> a bug in
>> the way the color vector is handled somewhere. The color components
>> seem to be
>> inverted; for instance red is<0,1,1> instead of<1,0,0>. Here are some
>> color
>> vectors I was playing with a while back. Note that they're all
>> inverted from
>> their RGB equivalents, but each renders as it's named color with SSLT:
>>
>> #declare sslt_aqua =<1, 0, 0>;
>> #declare sslt_magenta =<0, 1, 0>;
>> #declare sslt_yellow =<0, 0, 1>;
>> #declare sslt_blue =<1, 1, 0>;
>> #declare sslt_red =<0, 1, 1>;
>> #declare sslt_green =<1, 0, 1>;
>> #declare sslt_white =<0, 0, 0>;
>
> As I already mentioned earlier, the SSLT parameters are /not/ colors,
> but a pair of wavelength-dependent coefficients that /determine/ the
> color; in POV-Ray, both coefficients are specified for three distinctive
> wavelengths (corresponding - not surprisingly - to red, green and blue,
> respectively).
>
> The first parameter is the "scattering coefficient", specifying how
> often a photon (speaking of the physical thing here, not the POV-Ray
> thing) will be scattered (i.e. experience a change of direction) on
> average while travelling an "odometer distance" of 1 mm through the
> material. (The algorithm presumes that scattering is isotropic; the
> sample values are fit to match that presumption.)
>
> The second parameter is the "absorption coefficient", specifying the
> probability that a photon will be absorbed while travelling that distance.
>
>
> The dark blue fingers are indeed the results of bad coefficient
> settings; they tell me that the units_per_mm setting is set in a way
> that a finger is close to - or even smaller than - the distance a red or
> green photon would travel before being scattered. In such situations,
> the current surface scattering implementation still gives wrong results,
> as it does not account for photons traveling through the object
> unscattered. (In reality, with features that small, non-isotropic
> scattering would dominate, making the object appear either transparent
> or translucent, or something in between.)
>
> Where the bright edges come from I can't tell exactly; what I /can/ tell
> you is that (1) the math behind the algorithm was designed for planar
> surfaces, and may give less accurate results at edges, and (2) the
> algorithm cannot fully compensate for "fake smoothing"; so in essence
> you'll need a higher-resolution mesh.
you know this is awful good stuff that should be captured somehow ...
Robert: is there any way you could be conned into bundling this up into
a how to article?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
