Today I tested the principle of making a SSLT marble object, lit from behind.
Results are interesting, but not entirely successful. I'll retry it in future
though.

The idea is that the veins permeate through the solid, and have different
absorbent and diffusive properties than the rest of the medium.

The attached image shows a simple box (this can be any CSG-able object), but it
is actually two objects: an isosurface for the veins (dark, and highly
absorbent), and its inverse for the rest of the material (light, and highly
scattering). I've chosen to mimic 'inverse' using phase in the vein pattern,
rather than trying to close off CSG inverses.

Notes to prevent confusion:
1. The floor does not use SSLT.
2. The box is slightly raised from the floor, so the shadow position is OK.


(Speculative!) Observations:

It's not a visually good marble (it won't convince anyone), but I think a
principle is demonstrated here.

1. Dark veins can throw 'shadows' into the material, even when the veins are not
touching (?) the surface of the overall object.

2. The blue back-scattering, and red forward-scattering (a consequence of the
scattering colours) at the top-right of the shape.

3. What I'm not really seeing is the gradual receding of the veins in the bulk
of the material. Someone will probably tell me they can see it (top-left) and
say that I need to tweak parameters of textures, but I think that this marbling
is not possible in the current SSLT implementation, because inner edges can't
see the (discarded filtered pass-through) light. I'd be interested to know the
truth either way.

4. Possible brightness problem at edge of CSG intersections. I don't want to
speculate on the cause, as there are many possible reasons. (Oh, OK then: 1.
Poor CSG coincidences (and is the top face complete?), 2. Perhaps small convex
volumes are problematic).

If/when this SSLT develops, I hope for marbles and woods to be created like this
(a new material library) - obviously with more marble-ish functions (like the
current surface textures), and with a better understanding of the interfaces
between coincident surfaces of different SSLT-enabled materials.


Trace time (not tuned): ~50 mins on Intel Q6600 @ 2.4GHz (640 x 512, +AM2 +a0.4)

Post a reply to this message

Attachments:
Download 'subsurface_test4.jpg' (134 KB)

Preview of image 'subsurface_test4.jpg'

"MessyBlob" <nomail@nomail> wrote:
> Today I tested the principle of making a SSLT marble object, lit from behind.
> Results are interesting, but not entirely successful. I'll retry it in future
> though.
>
> The idea is that the veins permeate through the solid, and have different
> absorbent and diffusive properties than the rest of the medium.
....
> (Speculative!) Observations:

Plain fact observation:

You're operating far beyond the current limitations of the SSLT algorithm :P

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> Plain fact observation:
> You're operating far beyond the current limitations of the SSLT algorithm :P

Yes, but I'll save it for later ;o)
It's important to understand limits, and maybe others can learn from this
exercise, and not get too ambitious yet.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > Today I tested the principle of making a SSLT marble object, lit from behind.
> > Results are interesting, but not entirely successful. I'll retry it in future
> > though.
> >
> > The idea is that the veins permeate through the solid, and have different
> > absorbent and diffusive properties than the rest of the medium.
> ....
> > (Speculative!) Observations:
>
> Plain fact observation:
>
> You're operating far beyond the current limitations of the SSLT algorithm :P

First off - fantastic work on the initial SSLT algorithm, it's an amazing
feature that already works very well!

And now to my request :-) Having the SSLT algorithm be able to take a density
parameter in the same way media does would be in my top two requests for future
work - faked media-based SSS can give some pretty stunning results in term of
the feeling for the material.

My examples is far from stunning, but hopefully shows that there's a huge amount
that could be achieved if density could make it into the SSLT system...

Cheers,
Edouard.

Post a reply to this message

Attachments:
Download 'media-sss-density.jpg' (25 KB)

Preview of image 'media-sss-density.jpg'

"Edouard" <pov### [at] edouardinfo> wrote:
> First off - fantastic work on the initial SSLT algorithm, it's an amazing
> feature that already works very well!

Thanks. Glad to hear you like it.

> And now to my request :-) Having the SSLT algorithm be able to take a density
> parameter in the same way media does would be in my top two requests for future
> work - faked media-based SSS can give some pretty stunning results in term of
> the feeling for the material.

Unfortunately(?), the model on which the SSLT algorithm is based is not really
"volume aware": Basically all it does to compute the apparent color of a point
on the object's surface is sample the incident light at some other surface
points nearby, and then apply some smart math to it.

So yes, I will ultimately equip it with mechanisms to vary the material
parameters over space. But no, this will only take into account the parameters
on the surface (using the values at both the entrance and exit point).

Well, we'll see what the SSLT code will be able to do with that pattern
approach.

A possible extension would be to simply use not the parameters at the entrance
and exit point, but the averaged value along a straight line between the two.
Maybe this would be a viable way to "fake" volumetric effects.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Unfortunately(?), the model on which the SSLT algorithm is based is not really
> "volume aware": Basically all it does to compute the apparent color of a point
> on the object's surface is sample the incident light at some other surface
> points nearby, and then apply some smart math to it.

I was wondering how easy it would be to have the SSLT algorithm cope with
transitions from one SSLT object to another. This comes from the limitation that
currently, any SSLT objects must be a single object (implicit function, blob,
etc), and any CSG (or just one object seemlessly abutting another) causes the
SSLT algorithm to register shadow for the surface that is hidden.

I guess any transfer between surfaces would be recursive in nature (for each
transition point between materials), but could be optimized to be nearer linear
complexity using some caching. How would one get around volume intersection
problems, where it would be difficult to decide whether two objects are abutted,
overlapping, or disjoint? (I think I've had a similar discussion in the past
about a different feature - where I suggested a distance threshold: in this
case, for shorter distances, the SSLT transfer is interpolated between 'abutted'
and 'disjoint' values).

p.s. I've been away from POV-Ray for about 18 months (life!) - good to see
recent speed and smoothness/sampling improvements for SSLT!

Post a reply to this message

MessyBlob wrote:
> "clipka" <nomail@nomail> wrote:
>> Unfortunately(?), the model on which the SSLT algorithm is based is no
t really
>> "volume aware": Basically all it does to compute the apparent color of
 a point
>> on the object's surface is sample the incident light at some other sur
face
>> points nearby, and then apply some smart math to it.
> 
> I was wondering how easy it would be to have the SSLT algorithm cope wi
th
> transitions from one SSLT object to another. This comes from the limita
tion that
> currently, any SSLT objects must be a single object (implicit function,
 blob,
> etc), and any CSG (or just one object seemlessly abutting another) caus
es the
> SSLT algorithm to register shadow for the surface that is hidden.
> 
	Isn't that more or less the kind of issues that "merge" is meant to
address? I.e if you use "merge" instead of "union", don't the extra
shadows disappear?

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

<jeb### [at] freefr> wrote:
> MessyBlob wrote:
> > [...] any CSG (or just one object seemlessly abutting another) causes
> > the SSLT algorithm to register shadow for the surface that is hidden.

> Isn't that more or less the kind of issues that "merge" is meant to
> address? I.e if you use "merge" instead of "union", don't the extra
> shadows disappear?

No; SSLT does simple light visibility computations from the surface of the
object. It doesn't respect CSG, so if another object is between an SSLT-shaded
object and its light, then SSLT just treats the surface as being in shadow.

I'm hoping for a way for SSLT, on finding a foreign surface from the inside of
the current object, to be able to transfer its coefficients to the new object,
do another random ray-casting in the foreign medium, and then back-propagate and
re-integrate those results into the original object's results.

Post a reply to this message

Am 21.11.2010 01:29, schrieb MessyBlob:

> No; SSLT does simple light visibility computations from the surface of the
> object. It doesn't respect CSG, so if another object is between an SSLT-shaded
> object and its light, then SSLT just treats the surface as being in shadow.
>
> I'm hoping for a way for SSLT, on finding a foreign surface from the inside of
> the current object, to be able to transfer its coefficients to the new object,
> do another random ray-casting in the foreign medium, and then back-propagate and
> re-integrate those results into the original object's results.

That will happen. Other things currently have priority though.

Post a reply to this message