POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#243 - Sphere sweep behaves wrong when scaled

Attached to Project: POV-Ray
Opened by Simon (infoised) - Sunday, 27 May 2012, 18:02 GMT
Last edited by William F Pokorny (wfpokorny) - Sunday, 30 April 2017, 13:56 GMT
Task Type Unimp. Feature/TODO
Category Backend → Geometric Primitives
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Low
Priority Low
Reported Version All
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

The sphere_sweep renders well when specified directly, but when it is scaled, its bounding box is calculated incorrectly, which clips the object so it almost disappears.

The effect is present for all three types of splines.

I’m attaching a test scene and the rendering result. The saving of the object with #declare has no effect, I just wanted to show both transformed and untransformed version.

I don’t think this issue is related to other artifacts occuring with sphere_sweep, as it is obviously an issue of the internal bounding box.

This task depends upon

Comment by Thorsten Fröhlich (thorsten) - Sunday, 27 May 2012, 19:03 GMT

The bounding of spline-based sphere sweeps never worked right and it known to have many bugs, in particular because the bounding box does not correctly consider splines were the curve extends beyond the control points. Transformations just make the problems more apparent. The best solution is to manually bound sphere-sweeps.

Comment by Simon (infoised) - Monday, 25 February 2013, 16:27 GMT

Found the error. It's an easy fix. The SphereSweep::Scale has a special case for scaling if scaling is uniform: it simply multiplies all vectors AND ALL RADII by the scaling factor. This makes radius negative for negative scaling factors, which makes the bounding box shrink instead of grow. The code should be

void SphereSweep::Scale(const VECTOR Vector, const TRANSFORM *tr)
{
if((Vector[X] != Vector[Y]) || (Vector[X] != Vector[Z]))
{
	if(Trans == NULL)
		Trans = Create_Transform();
}
 
if(Trans == NULL)
{
	for(int i = 0; i < Num_Modeling_Spheres; i++)
	{
		VScaleEq(Modeling_Sphere[i].Center, Vector[X]);
		Modeling_Sphere[i].Radius *= fabs(Vector[X]); /*missing absolute value*/
	}
	Compute();
	Compute_BBox();
}
else
Transform(tr);
}

This fixes the bounding box for linear_spline (linear splines never stick out of their bounding box, so they don't have the same problems as the other types).

As for other problems with bounding boxes: for cubic_spline and b_spline, the bounding box in the code is heuristically made a bit bigger, but may still be too small in some cases. It is possible to find roots of the derivatives of cubic polynomials that describe the spline to get exact bounding values.

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 06 March 2014, 22:26 GMT

I agree, the scaling of the radius should use the absolute value. scale -1 is traditional, it shouldn't break the sphere_sweep when used alone or first.

Comment by William F Pokorny (wfpokorny) - Sunday, 30 April 2017, 13:56 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on github as issue #285.

Loading...