Warp wrote:

>> Chris Cason <nos### [at] deletethispovrayorg> wrote:
>
>>>> unfortunately to fix it I had to restore the old (buggy) clipping behaviour
>>>> of quadrics, however as this has been present for many years it should
not be
>>>> a major problem.
>
>>
>>   I'm not aware of such bug. Could you explain in more detail?

The issue is that a quadric (not all types, just some) that is clipped_by
another object will potentially return a smaller bounding box than either
that of the object or its original clipping region. This is particularly
evident if you render a scene with and without bounding slabs. Here's an example:

---------------------------------------------------------------------------

#include "colors.inc"
#include "textures.inc"

global_settings { assumed_gamma 2.2 }

camera {
   location  <0, 50, -20>
   direction <0, 0,  10>
   look_at   <0, 0,   0>
}

light_source { <0, 10, -20> color White*2 shadowless }

plane { z, 10 pigment {checker color White color rgb <1,.8,.8>}hollow on }

#declare UnitBox = box { <-1, -1, -1>, <1, 1, 1> }

quadric {
   <-1, 0, 1>, <0, 0, 0>, <0, 1, 0>, 0
   pigment { Blue }
   finish { ambient 0.1 }
   clipped_by{object{UnitBox scale <2,2,2>}}
}

#if (1)
box
{
  <-1.4142135, -2.0000000, -1.4142135>
  <1.4142135, 2.0000000, 1.4142135>
  pigment { rgbft <1,0,0,0,0.75> }
}

object
{
  UnitBox
  scale 2
  pigment { rgbft <0,1,0,0,0.75> }
}
#end

---------------------------------------------------------------------------

If you render this in v3.6 you will get a quadric that is smaller than the
clipping box in some dimensions. If you remove the clipped_by you will see
that in fact it should extend to the edges. 3.7 beta 4 handles the above
scene OK (however beta 5 will revert to the old behaviour unless it's fixed).

The green box represents the defined clipping object and the red box is
what the internal bbox calculations returned for the bounding volume once
the clipped_by had been applied.

If you turn off the two bottom objects via the #if (0) or just add -mb to the
command-line you'll see the quadric properly contained within the clipping
region.

The issue is caused by an optimization in the bounding box calculations that
attempts - for a number of different types of quadric - to determine, given a
defined clipping region in one direction (e.g. two planes), the maximum
extent of the quadric in another direction. It also does this even if the
clipping region is finite (e.g. the box given above).

The problem is that it generates this estimate (at least in this example)
with an assumed z of 0.0, ignoring the fact that it extends beyond the
calculated x value of 1.4142135 at z = -1.0 or +1.0 (and/or elsewhere, I
didn't analyze this thoroughly).

You can see this more clearly by moving the camera to <0, 50, 0> and
rendering with the boxes turned on, and with and without -mb.

While I could just return the clipping region rather than allowing the code
to optimize it this way (and in fact I made a small improvement in that area;
previously if the mixed terms were non-zero it just returned without setting
the bbox at all, now at least it will set it to the clip), the issue is that
often (e.g. in the ionic example scene you gave), the clip is performed with
planes and as such the object will still be infinite in some direction(s)
unless the calculations are done. It would appear a number of scenes depend
on the old behaviour and do not use finite clip regions (which is what my
changes had assumed).

The proper fix would be to make a more thorough estimation of extent for each
of the covered quadric types (cone, hyperboloid and paraboloid, in each of x,
y, and z axes) and return a more correct bbox.

-- Chris

Post a reply to this message