On 9/5/25 04:31, kurtz le pirate wrote:
> With my merged shape, i have no artifact in the lower right.
> 
> My code is attached. Play wit it !
> 
> You can see differences with useWFPObject = true or false

Thank you - especially for taking the time to add the extra switch. :-)

I believe the short of it is that the corner rounding with the bezier 
spline is a approximation of what the equivalent cylinder radius is. 
Meaning there is tiny, but real, relative, discontinuity where the 
straight segments join the rounded ones. The SSLT feature doesn't like 
it in a way similar to how it doesn't like other 'tight' features / 
paths through the object.

---

More detail.

Disclaimer. I'm no expert with the SSLT feature / code.

0) The far side artefacts are always there for both the merge{} and the 
prism{} no matter the things tried.

1) I used only six digits of the coefficient value calculation, so the 
first thing I tried was using the full double calculated value of 
0.5522847498307936 (a value accurate to maybe only about 7 or 8 
significant digits in any case). No difference.

2) I tried yuqk versions with all the solver improvements over-Ray 
releases(a). The artefact becomes slightly larger with the better 
solvers.

(a) - Found too that yuqk change(s) after Nov 2021 (when yuqk was still 
called povr) and all recent yuqk named versions, results in an infinite 
parser hang any time global_settings{} uses subsurface{} and the scene 
invokes ANY object - whether or not it is using SSLT... :-(

3) I tried a limited number of different camera positions and the 
prism{} specific artefact was always there.

4) The far side artefacts can be reduced in size by reducing the 
translucency via either the 'mm_per_unit' value or the per object 
'translucency' value. But, to my eye, the visual result is then not much 
worth the cost of SSLT.

5) Played a little with adding a normal{} block as a way to mitigate the 
artefacts, but it didn't seem to change the SSLT result at all. Might be 
the perturbed normals are ignored by SSLT; Anyone know for sure?

---

FWIW.

As our documentation makes clear, the experimental SSLT feature is 
there, but it's never been a polished implementation. For yuqk, it is a 
feature I might delete.

For the next yuqk release - unless I find the time to debug and fix the 
yuqk SSLT parser hang - I'll make the feature illegal to use with a 
message like "The SSLT feature is currently broken in the yuqk fork."

Bill P.

Post a reply to this message