3D graphics programmers using Python?
bokr at oz.net
Sun Feb 9 05:13:26 CET 2003
On Thu, 06 Feb 2003 08:57:12 GMT, "Brandon Van Every" <vanevery at 3DProgrammer.com> wrote:
>Bengt Richter wrote:
>> On Wed, 05 Feb 2003 22:58:33 GMT, "Brandon Van Every"
>> <vanevery at 3DProgrammer.com> wrote:
>>> That means when you're trying to compute points on the
>>> SphereTriangle, you end up having to use arccosines.
>> If you want great circle surface distance, I would have thought
>> arcsine more likely.
>That's merely an implementation detail of your formulation. If you are
>determining your arc from a vertex and a point the opposite edge, their dot
>product is the cosine, so you take the arccos. If you were using a planar
>normal representation of the triangle boundary, you'd use an arcsin. Six of
>one, half dozen of the other. The point is, you have to use an inverse
I think you will find that the smaller the angle (surface distance), the better
is the choice of using arc sine instead of arc cosine. I.e., consider that as the angle
approaches zero, what you are taking the arc cosine of is approaching 1.0, and if
y = arccos(x), dy/dx is -1.0/(1.0-x**2)**0.5 which goes to infinity when x goes to 1.0.
IOW, the smaller your triangles, the worse the errors in your calculation. In contrast,
for y = arcsine(x), x is zero when the angle y is zero, and dy/dx is 1.0/(1.0-x**2)**0.5
so it is nicely behaved when y and x go to zero.
IOW, what you call an "implementation detail" has computational consequences, which,
depending on your problem, and considering today's floating point hardware, you _may_
be able to get away with ignoring, but it's not just six of one half a dozen of the other.
More information about the Python-list