|
 |
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'
|
|
