POV-Ray : Newsgroups : povray.beta-test : Revisiting SSLT with 3.7.1 beta 9 Server Time
28 Mar 2024 12:01:26 EDT (-0400)
  Revisiting SSLT with 3.7.1 beta 9 (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 8 Aug 2017 17:15:00
Message: <web.598a298b5151470f883fb31c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 07.08.2017 um 23:21 schrieb FlyerX:
>
> > I checked the release notes and I could not find any reference to changes in
> > SSLT since 3.7. Is there any new setting that helps with the mesh density
> issue, or should I just keep using subdivision to alleviate it?
>
> The latter.

I haven't tried experimenting with SSLT yet (other than rendering POV-Ray's
example 'candle' file), so I'm out of my depth here, but...

I've been reading the technical article "A Practical Model For Subsurface Light
Transport," recommended in the docs. Unless I missed something there, it doesn't
mention anything specific about the use of 'normals' on the mesh triangles.
FlyerX's 'coarser' mesh-derived example shows odd brightness concentrations
around what look like the edges of the triangles (the eyes, specifically.) So
I'm wondering if POV-Ray's implementation of SSLT --or *any* implementation--
takes 'smooth triangles' into consideration, and shoots its rays along those
interpolated normals? Just from his example, it seems not. (I apologize for my
lack of technical understanding of exactly how all of this works.)

OR, perhaps his mesh isn't being exported correctly (i.e., the normals aren't
being included?)

Just food for thought.


Post a reply to this message

From: Stephen
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 8 Aug 2017 17:43:20
Message: <598a3078$1@news.povray.org>
On 8/8/2017 10:13 PM, Kenneth wrote:
> OR, perhaps his mesh isn't being exported correctly (i.e., the normals aren't
> being included?)
>

I would be surprised if that were the case. FlyerX is the author of 
PoseRay. The best obj to mesh2 converter there is.



-- 

Regards
     Stephen


Post a reply to this message

From: Kenneth
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 8 Aug 2017 17:50:01
Message: <web.598a30f85151470f883fb31c0@news.povray.org>
Stephen <mca### [at] aolcom> wrote:
> On 8/8/2017 10:13 PM, Kenneth wrote:
> > OR, perhaps his mesh isn't being exported correctly (i.e., the normals aren't
> > being included?)
> >
>
> I would be surprised if that were the case. FlyerX is the author of
> PoseRay. The best obj to mesh2 converter there is.
>

OOPS! My profuse apologies, FlyerX  :-O  Keep up the good work.... (**hides in
shame**)


Post a reply to this message

From: clipka
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 9 Aug 2017 05:05:35
Message: <598ad05f$1@news.povray.org>
Am 08.08.2017 um 23:13 schrieb Kenneth:

> I've been reading the technical article "A Practical Model For Subsurface Light
> Transport," recommended in the docs. Unless I missed something there, it doesn't
> mention anything specific about the use of 'normals' on the mesh triangles.
> FlyerX's 'coarser' mesh-derived example shows odd brightness concentrations
> around what look like the edges of the triangles (the eyes, specifically.) So
> I'm wondering if POV-Ray's implementation of SSLT --or *any* implementation--
> takes 'smooth triangles' into consideration, and shoots its rays along those
> interpolated normals? Just from his example, it seems not. (I apologize for my
> lack of technical understanding of exactly how all of this works.)

There's a twofold problem here:

- Dealing with the edges of supposedly smooth meshes in SSLT is tricky
enough in and of itself: The algorithm needs to look at nearby geometry,
not just a single ray-surface intersection and its surface normal.
Without any additional countermeasures, edges in supposedly smooth
surfaces /will/ cause artifacts. There is no paper on such
countermeasures that I'd be aware of, so careful thought needs to be put
into this.

- Whatever the details of such countermeasure would be, it would
inevitably involve looking at the true geometric surface normal.
Unfortunately, POV-Ray currently only passes around the fake-smoothed
surface normal and the perturbed surface normal.

So in order to prevent the artifacts in question, first POV-Ray's
internal architecture needs to be modified to also pass around the true
geometric surface normal (which is on the agenda anyway to eliminate
certain other artifacts). Once that is done, brainpower needs to be
invested into finding a suitable algorithm to account for smoothed geometry.


BTW, there's also a related problem with photons collected on smooth meshes.


Post a reply to this message

From: Jim Holsenback
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 9 Aug 2017 07:01:10
Message: <598aeb76$1@news.povray.org>
On 8/9/2017 5:05 AM, clipka wrote:
> - Whatever the details of such countermeasure would be, it would
> inevitably involve looking at the true geometric surface normal.
> Unfortunately, POV-Ray currently only passes around the fake-smoothed
> surface normal and the perturbed surface normal.

i believe this explains why i'm having difficulty with my current 
project (rolly sphere) ... i thought i'd stumbled upon a cure when i 
used smooth vertex weights (blender) around the edges of the hole cut 
outs then recalculating the normal's. it /did/ get rid of the puckering 
that i was seeing around those edges for /non/ subsurface renders but i 
haven't been able to scale or sample them away entirely when using (they 
are diminished somewhat) subsurface.


Post a reply to this message

From: Jim Holsenback
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 9 Aug 2017 07:23:27
Message: <598af0af$1@news.povray.org>
On 8/8/2017 5:43 PM, Stephen wrote:
> PoseRay. The best obj to mesh2 converter there is.

yep ... i'm a fan too


Post a reply to this message

From: Kenneth
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 9 Aug 2017 16:30:01
Message: <web.598b6f9f5151470f883fb31c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

>
> There's a twofold problem here:
>
[snip
> - Whatever the details of such countermeasure would be, it would
> inevitably involve looking at the true geometric surface normal.
> Unfortunately, POV-Ray currently only passes around the fake-smoothed
> surface normal and the perturbed surface normal.
>

*Thanks* for taking the time to explain this. It *is* a complex subject.

I need a little clarifaction, just to improve for my own understanding:

I take the "true geometric surface normal" to mean the unalterted,
un-interpolated *single* normal on the face of the flat triangle. Is that
correct?

Also: It is becoming clearer to me as to why SSLT works better on an object with
finer-and-finer triangle subdivisions (and perhaps not so well with large flat
'mathematical' slabs like a box object?) The smaller triangles-- curving away at
slightly different angles-- cause the (many) incoming rays (and subsequent
subsurface 'volume gathering') to be averaged together in a smoother way, with
the artifacts contributing less to the 'larger' average, or being swamped by it.
This is my layman's understanding, anyway ;-)  Please correct me if I'm mistaken
or hopelessly wrong. If I'm at least somewhat correct, then POV-Ray's in-built
documentation doesn't actually mention the need for finer triangle-mesh
subdivisions, to get a smoother look. Perhaps it should, in light of Flyer X's
results.


Post a reply to this message

From: clipka
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 9 Aug 2017 18:51:33
Message: <598b91f5$1@news.povray.org>
Am 09.08.2017 um 22:25 schrieb Kenneth:

> I take the "true geometric surface normal" to mean the unalterted,
> un-interpolated *single* normal on the face of the flat triangle. Is that
> correct?

Yes.

> Also: It is becoming clearer to me as to why SSLT works better on an object with
> finer-and-finer triangle subdivisions (and perhaps not so well with large flat
> 'mathematical' slabs like a box object?)

The results are actually quite accurate for "large flat 'mathematical'
slabs", if that's the shape you intend to model. The problem isn't the
presence of edges /per se/ -- the problem is the presence of edges in
places where you want to pretend that there are none.

> The smaller triangles-- curving away at
> slightly different angles-- cause the (many) incoming rays (and subsequent
> subsurface 'volume gathering') to be averaged together in a smoother way, with
> the artifacts contributing less to the 'larger' average, or being swamped by it.
> This is my layman's understanding, anyway ;-)  Please correct me if I'm mistaken
> or hopelessly wrong. If I'm at least somewhat correct, then POV-Ray's in-built
> documentation doesn't actually mention the need for finer triangle-mesh
> subdivisions, to get a smoother look. Perhaps it should, in light of Flyer X's
> results.

The SSLT feature is still considered highly experimental, and so are its
docs.


Post a reply to this message

From: Kenneth
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 9 Aug 2017 23:00:00
Message: <web.598bcb995151470f883fb31c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

>
> The results are actually quite accurate for "large flat 'mathematical'
> slabs", if that's the shape you intend to model. The problem isn't the
> presence of edges /per se/ -- the problem is the presence of edges in
> places where you want to pretend that there are none.
>

Ah yes, I see now. Thanks.

From reading lots of newgroup comments over the years, I had come to the
(mistaken) impression that SSLT actually *worked* better on complex, CURVED
objects-- meaning, an object with LOTS of small triangles and their attendent
interpolated normals. (Such objects do show a nicer, more complex 'look' from
the SSLT effect-- like the ears on the Stanford Bunny.) And conversely, that
more-or-less 'flat-surfaced' featureless objects were to be avoided. But I
understand more clearly now that SSLT *works* equally well on simpler shapes--
like a superellipsoid 'bar of soap', for example. It's just that the final
effect isn't as visually complex (leading me to the mistaken conclusion that it
didn't work well on such shapes.)


Post a reply to this message

From: Mr
Subject: Re: Revisiting SSLT with 3.7.1 beta 9
Date: 10 Aug 2017 05:05:01
Message: <web.598c21275151470fe10e80840@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> >
> > The results are actually quite accurate for "large flat 'mathematical'
> > slabs", if that's the shape you intend to model. The problem isn't the
> > presence of edges /per se/ -- the problem is the presence of edges in
> > places where you want to pretend that there are none.
> >
>
> Ah yes, I see now. Thanks.
>
> From reading lots of newgroup comments over the years, I had come to the
> (mistaken) impression that SSLT actually *worked* better on complex, CURVED
> objects-- meaning, an object with LOTS of small triangles and their attendent
> interpolated normals. (Such objects do show a nicer, more complex 'look' from
> the SSLT effect-- like the ears on the Stanford Bunny.) And conversely, that
> more-or-less 'flat-surfaced' featureless objects were to be avoided. But I
> understand more clearly now that SSLT *works* equally well on simpler shapes--
> like a superellipsoid 'bar of soap', for example. It's just that the final
> effect isn't as visually complex (leading me to the mistaken conclusion that it
> didn't work well on such shapes.)


Indeed, what we are all saying about SSLT, is that it's actually *too* accurate
and looks (too?) great !... :-) We are not used to that behaviour from other
renderers especially with the smoothed average normal cheat  enabled.
I am hoping a normal overhaul will also bring many other goodies to POV (such as
tangeant space (/parallax) normal mapping if we don't forget :-P )
meanwhile, I would love to have a fast biased cheated sstl simulated effect
shipped along under the subsurface/translucency command with a keyword similar
to the (fake photonless) caustics. A result similar to ST Benge fastprox macro
would be enough.


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.