POV-Ray : Newsgroups : povray.object-collection : SphereSweep_2.1:_quadratic_Bézier_sweeps : SphereSweep_2.1:_quadratic_Bézier_sweeps Server Time
18 Apr 2024 18:56:27 EDT (-0400)
  SphereSweep_2.1:_quadratic_Bézier_sweeps  
From: Cousin Ricky
Date: 27 Sep 2020 16:18:27
Message: <5f70f393@news.povray.org>
SphereSweep now does quadratic (2nd degree) Bézier sweeps natively.

Bill, I trust that this will simplify your code.

http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky

More Adventures in Verification

Last time, during final proofreading of the User Manual, I discovered a 
major error in my understanding of Bézier math that would have been 
quite embarrassing to have uploaded.  This time, I discovered a gap in 
the test procedure for the PointArrays conversion.  PointArrays is good 
all the way back to POV-Ray 3.6.1, but my test scene was #versioned at 
3.7.  Not wanting to take anything for granted, I rolled back the 
#version and retested it.

Fortunately, it only took removing an unnecessary pigment and converting 
the #elseif and the #for loops in the test scene to verify that the 
PointArrays conversions that I already uploaded work fine in 3.6.1. 
That said, the SphereSweep_Approx() artifacts in 3.6.1 were the stuff of 
nightmares!  There were no artifacts in the PointArrays equivalents.  It 
seems that using a linear sphere_sweep with numerous short segments 
along non-linear splines (which PointArrays doesn't do) can overwhelm 
the 3.6 engine.  When the objects were replaced with SphereSweep_CSG(), 
there were no artifacts.

As for that unnecessary pigment, apparently there are situations where 
3.6 balks when presented with a textured object, but where 3.7 doesn't 
care.  This affected the test scene only, and has no direct bearing on 
SphereSweep.

As I said I would do in another thread, I have changed all "order" 
terminology to "degree," including some variable names.  The delay in 
uploading 2.1 was to retest the module.  Now, why should I have to do 
substantial retesting after a simple search and replace?  It's because I 
have seen too many coders get burned by taking seemingly minor changes 
for granted.  You never know when you'll slip up, or what the other end 
of that strand of spaghetti is attached to.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.