 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I tested SSLT with the new 3.7.1 beta 9 and I still found that it is affected by
the mesh density.
I tested a scene with a mesh with SSLT on the skin+eyes, a single area light, an
emissive background, radiosity, and anti-aliasing. The issue is most notable on
the chin, neck, and whites of the eyes. The SSLT translucency was 2,1,1 for the
skin and 0.2,0.2,0.2 for the eyes. See images below for more details.
Render with the mesh at about 130000 triangles:
https://drive.google.com/file/d/0B0WPQb1iNGaYS1NFVWJ4eWF4U2c/view?usp=sharing
Render with the mesh subdivided to about 560000 triangles:
https://drive.google.com/file/d/0B0WPQb1iNGaYUEItNGUwbFpGLVE/view?usp=sharing
Here is a PoseRay capture of the mesh densities
130k:
https://drive.google.com/file/d/0B0WPQb1iNGaYVnpaQzktMk1IQXc/view?usp=sharing
560k:
https://drive.google.com/file/d/0B0WPQb1iNGaYdmRRV0xMTjZValk/view?usp=sharing
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?
Thanks,
FlyerX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I forgot to mention that I used 24.5 mm per unit. The scene is scaled in inches.
"FlyerX" <fly### [at] yahoo com> wrote:
> Hello,
>
> I tested SSLT with the new 3.7.1 beta 9 and I still found that it is affected by
> the mesh density.
>
> I tested a scene with a mesh with SSLT on the skin+eyes, a single area light, an
> emissive background, radiosity, and anti-aliasing. The issue is most notable on
> the chin, neck, and whites of the eyes. The SSLT translucency was 2,1,1 for the
> skin and 0.2,0.2,0.2 for the eyes. See images below for more details.
>
> Render with the mesh at about 130000 triangles:
> https://drive.google.com/file/d/0B0WPQb1iNGaYS1NFVWJ4eWF4U2c/view?usp=sharing
>
>
> Render with the mesh subdivided to about 560000 triangles:
> https://drive.google.com/file/d/0B0WPQb1iNGaYUEItNGUwbFpGLVE/view?usp=sharing
>
>
> Here is a PoseRay capture of the mesh densities
> 130k:
> https://drive.google.com/file/d/0B0WPQb1iNGaYVnpaQzktMk1IQXc/view?usp=sharing
>
> 560k:
> https://drive.google.com/file/d/0B0WPQb1iNGaYdmRRV0xMTjZValk/view?usp=sharing
>
>
> 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?
>
> Thanks,
>
> FlyerX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
