On 1/30/22 20:09, Cousin Ricky wrote:
> On 2022-01-30 17:40 (-4), William F Pokorny wrote:
>>
>> You can still manually bound objects but you have to turn the automatic
>> bounding strip off. -ur (IIRC). Not sure any advantage over the union of
>> spheres idea.
> 
> The problem with this is that you'd have to know where the bounds are,
> which seems to be the unknown here.
> 
> As far as defeating automatic bounding (which cannot be entirely turned
> off--See clipka's comments in "Apparent bounding bug in sphere_sweep,"
> April 2013), I just intersect the object with a bounding shape, which
> sidesteps the issue entirely.  Potential problems with this approach are
> performance issues with complex unions, and that it may not work with
> cubic sphere_sweeps.

I expect you're right that - especially with official v3.7+ POV-Ray - a 
user bounding approach will be problematic.

---
Sorry too, I wasn't clear. The ur control strips user specified bounding 
or not and it defaults to stripping all user specified bounding. My 
thinking was it might be possible to quickly dial in the axis of 
rotation you want via a larger - as needed on certain sides - user 
bounding(a) so long as the user bounding wasn't stripped.

I was forgetting that in POV-Ray proper there is - completely hidden 
from users / silent acting - code which measures the volume of the 
current bounding box and it prevents users from specifying a smaller by 
volume user bounds than exist on the shape currently. Long standing 
comments in the code suggest there are problems with this "we know 
better than the user" approach to bounding - expect you too can think up 
a few pitfalls.

---
It's true, but a somewhat different issue, that the bounds checking set 
on the final object cannot be turned off(c) in official v3.7,v3.8,v4.0 
versions of POV-Ray.

The -mb or bounding off by < count options do work again in povr as in 
v3.6 and prior.

Bill P.

(a) - With the +ur default there are internally exceptions where for a 
few constructions/(objects?) the stripping does not happen even with the 
+ur default. (d)

(b) - Code I changed in povr a long time ago. I don't recall all the 
particulars. (d)

(c) - For a very few simple base objects this last level of bounds 
checking is bypassed. I don't recall a compete list (it's a per object 
code change), but spheres and boxes are on it. (d)

(d) - Does this sort of secrete, "we'll quietly fix/do it differently 
for you," code occasionally lead to brutally confusing situations for 
users and coders?

Post a reply to this message