On 3/18/25 01:44, Paul Bourke wrote:
> Another one ... please see zip archive here with scene and data file
>     https://paulbourke.net/transient/povray2/
> And sample render attached, PovRay 3.8.
> What causing the black defects? Seem to only be on close parts of the blob.
> Note PovRay 3.7 gives "There are more than the maximum supported components in a
> blob."
> 

I'd bet on numerical issues with the blob code or the solvers which are 
fixed(*) in the yuqk fork. No idea which fixes in particular.

In the attached image (no AA) the top sub image is the v3.8 beta 2 
result; The middle sub-image is the yuqk fork result; The bottom 
sub-image shows the differences.

I see black artefacts in the v3.8 result where there are differences 
shown in the bottom sub-image.

---

Aside 1 : We can, in the spherical camera, use angles like 360,360 as I 
did here for the images posted. And though the documentation implies 
limits, we can in fact use values >360 for both angles. Has anyone found 
a use for this somewhat hidden(**) capability?

I've had the thought maybe we could get to an ODS camera capability by 
adding two optional 2D offset vectors after the two spherical camera 
angles - which would be applied by multiples on mod(angle,360)s to get 
different eye pupil positions. Might have some work to get the pixels 
into a more standard positions for ODS viewing, but - maybe - we can get 
to some ODS support without adding more cameras.

Aside 2: Another thought with folks recently discussing ODS cameras with 
respect to your scene. The disc / polygon orienting would be slightly 
off for one or both eyes, if the ODS image is created via one scene and 
render. Perhaps not enough to matter?

Bill P.

(*) Cleaner. Floating point numerical limitations never really go away...

(**) - 'hidden' so I don't have to spell 'secret', Bill W.

Post a reply to this message

Attachments:
Download 'sceneloop0400_v38b2_to_sceneloop0400_yuqk.jpg' (167 KB)

Preview of image 'sceneloop0400_v38b2_to_sceneloop0400_yuqk.jpg'