On 11/2/25 14:08, Kenneth wrote:

Thanks for confirming on windows.

> So I wonder if the problem is just shadow artifacts: sturm on/off has the
> opposite effect on the inside and outside-- and on the lighted surface vs.
> shadowed surface(!)
> 

I agree. The bad sturm results for official are shadow related.

However, I believe this due the sturm results, sometimes, not being that 
accurate - by position. Specifically, I'd bet here on a 'quicker exit' 
bug in the regula-falsi code - fixed in yuqk - which finishes off the 
root calculation once an interval with a single root has been found by 
the sturmian portion of 'sturm'(*).

> The appearance of the noise and the artifacts on the*outside* depends on the
> the camera position, its look_at point, the position of the light(s) and the
> orientation of the SOR-- all of which interact, unfortunately. It looks the
> worst to me  when the y-positions of all three are the same (and not just when
> the camera is looking straight into +z).
> 
> Since the SOR when 'open' is really just an infinitely thin shell, it seems to
> me that using it this way is not a good idea anyway, as  the walls have no
> thickness at all and look unrealistic. (The docs also mention that it shouldn't
> be used in CSG this way.)

No... :-) The sor{}s are more like cylinders/cones in having well 
defined inside regions always with two surfaces when using caps and, 
potentially, only a single surface - with the same, well defined, inside 
region - depending on the ray path when not using caps.

In playing more with the sor{} shape recently, I've come to think it 
more useful due potential use in CSG! The sor{} doesn't have the fuzzy 
issues with defining an inside regions which Cousin Ricky highlighted 
recently for the lathe{} at fold-backs, for example.

Bill P.

(*) - I have more sturmian solver work years now on the todo list; 
Including replacing the regula-falsi code with a dedicated 
newton-raphson solver I wrote from scratch that always resolves to the 
root once given an interval known to have a root. That work though is 
tangled in also wanting to remove a re-ordering of coefficients into the 
sturmian part of 'sturm' that I suspect was long ago done for 
convenience, but which burns time.

I have too another solver approach which, for accuracy is much better 
than 'sturm'. However, it requires even more re-working of code because 
it merges the per shape polynomial generation and solver into one 
method. Maybe someday...

Post a reply to this message