|
|
On 4/25/22 18:25, Cousin Ricky wrote:
> I want to compute the volume of arbitrary solids of revolution, and to
> do this, I need to trace the objects. But with cubic and Bezier lathes,
> trace() is hit or miss.
Thanks for the nice test case!
FWIW.
In a 'completely accurate' numerical result there are holes in the lathe
at the (top or bottom), OR, (top and bottom) depending upon whether
cubic or Bezier curves. When rays shot exactly vertical at the x,z
origin of the rotation about y. I cannot for certain recall which is
which at the moment.
Probably due the improved solvers; When I run your scene as shipped
(Offset 0) in my povr fork, I get vertical misses - but no side misses.
However, some of the side results are from the wrong end due there being
a hole on one end(a).
A recommendation would be to use the specified on curve points directly
when those align with the trace you'd otherwise do.
All said, trace, especially when the direction vector is 0 in one or
more its components, can be problematic depending upon the curve
specified and the ray being traced.
Bill P.
(a) - Where you have:
Ypt = trace (Form, adjStart, v_Dir, Norm);
and there is a hole the first vertical surface, but not the second, Ypt
gets set to the wrong location. The follow-on side trace is done at the
wrong (probably it's always a duplicate to the other 'side trace') y.
---
Aside: In povr, when I use a small offset in z, as in:
#local adjStart = (v_Start+<0,0,1e-6>) + Offset * x;
I no longer see misses for any vertical trace, but I introduce some side
misses. Those can be 'addressed' with a y specific offset:
#local Side = <v_Min.x - 1, Ypt.y + (f_sign(v_Dir.y) * 5e-3), 0>;
(The numerical y-view "hole(s)" at the ends has a related "trim" viewed
from the sides)
With the two changes above I get trace results with povr for all your
cases. However, trace is likely still unstable with respect to certain,
other lathe, curve specifications...
Post a reply to this message
|
|