On 29-4-2013 10:55, s.day wrote:
> Ok, this is weird.. I simply move the translate up inside the sphere_sweep
> object and added a second union around the markers and got the image below in
> 3.7...
>
> I was previously seeing the same result as you with the bounding issue.
>
> union
> { sphere_sweep
>     { cubic_spline 6,
>       <1, -1>, R,
>       <-1, -1>, R,
>       <-1, 1>, R,
>       <1, 1>, R,
>       <1, -1>, R,
>       <-1, -1>, R
>       bounded_by { box { -<1.5, 1.5, R>, <1.5, 1.5, R> } }
>       pigment { red 1 }
>     translate 1.5 * y
>     }
>     union
>     {
>     object { Marker translate <1, 1> }
>     object { Marker translate <1, -1> }
>     object { Marker translate <-1, -1> }
>     object { Marker translate <-1, 1> }
>     translate 1.5*y
>     }
> }
>
> Sean
>

but if you comment bounded_by out, the problem reappears...

Thomas

Post a reply to this message

...in other words, why is bounded_by essential here? I myself never use 
this with sphere_sweeps and never had a problem.

Thomas

Post a reply to this message

Am 29.04.2013 13:24, schrieb Thomas de Groot:
> ....in other words, why is bounded_by essential here? I myself never use
> this with sphere_sweeps and never had a problem.

The obvious answer is, "because sphere_sweep automatic bounding is 
unreliable" :-)

Post a reply to this message

On 29-4-2013 13:29, clipka wrote:
> Am 29.04.2013 13:24, schrieb Thomas de Groot:
>> ....in other words, why is bounded_by essential here? I myself never use
>> this with sphere_sweeps and never had a problem.
>
> The obvious answer is, "because sphere_sweep automatic bounding is
> unreliable" :-)
>
Right. I could have expected that answer  ;-)

Thomas

Post a reply to this message

Am 29.04.2013 10:55, schrieb s.day:
> Ok, this is weird.. I simply move the translate up inside the sphere_sweep
> object and added a second union around the markers and got the image below in
> 3.7...

I /think/ I found at least part of the mechanism that leads to this problem:


The first thing to note is that whenever you transform an object, 
obviously the bounding box needs to be adjusted accordingly.

This is generally implemented in a pretty braindead manner: The bounding 
box is re-computed from scratch.

Normally this does not interfere with custom bounding boxes, because 
those are applied only at the closing brace of the object statement, 
when all your transformations are done already.


Enter CSG, with another important fact: If you transform CSG objects, 
what actually happens is that all its children are transformed.

And their bounding boxes are updated - read: re-computed - accordingly.

/After/ the custom bounding boxes have been applied.

And no, there's currently no mechanism in place to re-apply the custom 
bounding boxes.


I still haven't understood all the details yet, but I can already tell 
that you've exposed a bug there.


Obviously the only reason this leads to artifacts in this case is due to 
the - well-known - issue of sphere_sweep automatic bounding being 
unreliable. However, there may also be cases where the unintended 
overriding of custom bounding boxes will impact render performance.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> The first thing to note is that whenever you transform an object,
> obviously the bounding box needs to be adjusted accordingly.
>
> This is generally implemented in a pretty braindead manner: The bounding
> box is re-computed from scratch.
>
> Normally this does not interfere with custom bounding boxes, because
> those are applied only at the closing brace of the object statement,
> when all your transformations are done already.
>

I'm wondering about the implications of this during SDL coding--the ordering of
terms. If I'm understanding this correctly, is the placement of the bounded_by
object actually important? (The docs are silent on this issue, except for a
single example with no in-depth explanation.)

In other words: Which of these two constructions is the 'better' one re:
bounded_by? (I haven't checked the math, BTW; these are just dumb examples)

difference{
sphere{0,1}
sphere{0,1 translate 1*x}
bounded_by{sphere{0,2.1 translate 1*x}} // placed *prior to* translate/rotate
translate <3,6,9>
rotate 35*y
}

OR...

difference{
sphere{0,1}
sphere{0,1 translate 1*x}
translate <3,6,9>
rotate 35*y
bounded_by{sphere{0,2.1 translate 1*x}} // *after* all the transformations
}

The first example is usually the way I do it--it just seems more 'intuitive' to
transform the difference *along with* the bounding object. But is that really
correct? Or does the ordering of terms matter at all?

Post a reply to this message

Am 30.04.2013 05:37, schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> The first thing to note is that whenever you transform an object,
>> obviously the bounding box needs to be adjusted accordingly.
>>
>> This is generally implemented in a pretty braindead manner: The bounding
>> box is re-computed from scratch.
>>
>> Normally this does not interfere with custom bounding boxes, because
>> those are applied only at the closing brace of the object statement,
>> when all your transformations are done already.
>>
>
> I'm wondering about the implications of this during SDL coding--the ordering of
> terms. If I'm understanding this correctly, is the placement of the bounded_by
> object actually important? (The docs are silent on this issue, except for a
> single example with no in-depth explanation.)

The ordering does matter: A bounded_by object does undergo all 
transformations placed /after/ it, but not those before it.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> I still haven't understood all the details yet, but I can already tell
> that you've exposed a bug there.
>
>
> Obviously the only reason this leads to artifacts in this case is due to
> the - well-known - issue of sphere_sweep automatic bounding being
> unreliable. However, there may also be cases where the unintended
> overriding of custom bounding boxes will impact render performance.

Do you think the basic problem is the nature of the cubic spline math *itself*?
Or is it the overall interactions with the sphere_sweep code (and camera and
auto-bounding and...etc.)?  My own (layman's) opinion--from purely visual
results--is that the cubic_spline is producing *infinities* in places. At least,
that's what the 'discontinuities' in the sphere_sweep used to look like, in 3.61
and currently in 3.62. (Don't know about this new bounding-box issue, though.)

I've been playing around with a test set-up again (in 3.62) and managed to
arrange things to get a very clear and close-up view of the discontinuities; I
made an animation of this and will post it. Maybe it will prove helpful.

This cubic spine business has been causing problems with the sphere sweep for
years (and apparently continues to do so.) At this point, I would venture an
opinion: get rid of that spline. *If* there is a suitable replacement. (I'm no
mathematician, so I don't know such things--not sure I even want to know! So
this opinion might be a very naive one.)

It's unfortunate that, of the three spline types that can be used in a sweep,
the cubic spline is the only one that is both 'curvy' AND actually goes through
all the points...which makes it more 'understandable' (controllable?) than a
b_spline. Not the same 'curvy' results, of course.

Post a reply to this message

Am 03.05.2013 11:36, schrieb Kenneth:

> This cubic spine business has been causing problems with the sphere sweep for
> years (and apparently continues to do so.) At this point, I would venture an
> opinion: get rid of that spline. *If* there is a suitable replacement. (I'm no
> mathematician, so I don't know such things--not sure I even want to know! So
> this opinion might be a very naive one.)

There is no suitable replacement.

There are various levels of "smoothness" a spline may provide: Linear 
splines provide gradual change of position, but the direction changes 
abruptly at certain points; quadratic splines also provide a gradual 
change of direction, but the rate of change in direction (the 
"acceleration", so to speak) changes abruptly. Cubic splines also allow 
for gradual change of this acceleration.

There /are/ other splines that do allow the same level of smoothness; 
however, fun fact is that unless you're choosing some very exotic (and 
mathematically even more challenging) spline, they're all cubic (aka 3rd 
order polynomial) splines at heart, with just a different way of 
parameterizing them via a series of points.


That said, I suspect that all the problems with the cubic splines 
primitive in POV-Ray are implementation issues rather than inevitable 
mathematical problems.

Post a reply to this message

"s.day" <s.d### [at] uelacuk> wrote:
> Ok, this is weird.. I simply move the translate up inside the sphere_sweep
> object and added a second union around the markers and got the image below in
> 3.7...

Now this is funny.  Your workaround works, regardless of the Remove_Bounds (UR)
setting.  When I set +UR I get "Parse Warning: Unnecessary bounding object
removed" (as would be expected), but it still renders as if the bound were /not/
removed.

Speaking of which, I agree with Warp and his invocation of the principle of
least surprise on 2010-03-23 (p.bugreports, Re: Is sphere_sweep known to be
troublesome?).  Remove_Bounds should default to off (and I think I'll put that
in my povray.ini).

Post a reply to this message