On 9/22/21 7:02 PM, Samuel B. wrote:
> I was looking through old files for something else and came across this scene.
> Since I can't remember if I ever posted it or not, I am doing so now!

Neat! I don't recall seeing a previous post.

Your scene turned out to be a useful performance test case for my povr 
branch! Some years back I turned off extra on the fly bounding in 
torus.cpp done with a function called: Test_Thick_Cylinder(). It first 
looks for intersections on both an inner and outer cylinder before 
trying find the true ray->torus intersections.

Why? I'd found my way to the routine - or a similar one in a different 
shape (lathe?) - chasing a bug. On fixing it, ran on the torus solver 
test cases I had and it didn't seem to help or hurt too much. Sometimes 
slower, sometimes faster. I also didn't like that it was more bounding 
in front of the final ray-surface solver which I could not turn off by 
option.

Well, by Jove, The automatic bounding for:

...
  torus{C1.z, Thk clipped_by{Wedge_} translate y*C1.y}
  torus{C1.z, Thk clipped_by{Wedge_} translate y*C2.y}
  torus{C2.z, Thk clipped_by{Wedge_} translate y*C1.y}
  torus{C2.z, Thk clipped_by{Wedge_} translate y*C2.y}
...

is poor and without the extra Test_Thick_Cylinder() your scene is 48% 
slower in povr than v3.8 beta 2!

For now, going back to using Test_Thick_Cylinder() as I don't remember 
the slower cases with it being anywhere near 48% slower. Good protection 
against extremes I guess.

Someday need to play with something for arcs based upon 'carefully' 
placed blobs - or maybe some kind of tori slice and dice into a union 
for performance. My expectation is we can do better than that internal
Test_Thick_Cylinder() test bounding wise.

Better optimization for +bm2 suppose a general idea worth a look any 
time we get into non-orthogonal 'stuff'. Someday...

Bill P.

Post a reply to this message