William F Pokorny <ano### [at] anonymousorg> wrote:


> I took a few swings at fixes late last night, but no luck. I'm going to
> code up some parser checks to limit the radii to positive values only
> until I can come back to this issue with more focus.


I'm looking at the following

if (fabs(apex_radius - base_radius) < EPSILON)           // line 757

if (apex_radius < base_radius)                           // line 768

tmpf = base_radius * len / (apex_radius - base_radius);  // line 782

if (((apex_radius - base_radius)*len/tlen) < EPSILON)    // line 788


and wondering if those should should use fabs of each radius for the
calcs/comparisons

Just because I'm getting the impression that once one of the values crosses
zero, the differences sort of double-back on themselves, which might trigger
that whole

 /* What we are dealing with here is really a cylinder */

        Set_Flag(this, CYLINDER_FLAG);

        Compute_Cylinder_Data();

        return;

part, which might wind up clipping one side of the cone.
So it might be partially an algorithmic bug?

What bounding are you disabling in yuqk?
Is it stuff in
https://github.com/POV-Ray/povray/tree/master/source/core/bounding ?

Have you tried manually bounding the cones with a cylinder using the max
(abs(r1), abs(r2)) in SDL?  Curious if that would
a. work
and
b. be faster

- BW

Post a reply to this message