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