Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 01 Dec 2001
Offline Last Active Dec 03 2014 10:44 AM

Posts I've Made

In Topic: Calculate volume of non-convex polyhedron

13 November 2014 - 08:35 AM

Alvaro's method does require that your polyhedron is represented as a triangle mesh, but if I understand you correctly, you only have a set of points, which lie on the boundary. This means that before you can use it, you'd have to create a triangle mesh from those points, which is possible, but really quite difficult (search for surface reconstruction from point clouds). If you don't mind using third party libraries, you could use CGAL for this though (see http://doc.cgal.org/latest/Surface_reconstruction_points_3/).

In Topic: point & Octahedron relationship

22 October 2014 - 10:39 AM

If it's a regular octahedron, just take the absolute value of each coordinate, add them, and see if the resulting value is less than a certain threshold (ie. the size of your octahedron). If so, then your point lies inside it, otherwise not.

In Topic: Quaternion angle with itself > 0.001

13 August 2014 - 10:58 AM

Hey guys,

I'm in the process of working out my math library, and so I was testing out a function that returns the angle between two quaternions..

{ return 2.0f * acos( Abs( Dot4( qa, qb ) ) ); }


.. but for some reason, I'm either getting a lot of floating point error in the result, or I'm not checking for a situation that I should be. While testing a quaternion (which was generated by a random axis+angle rotation and appears to be very close to normalized)..

{ x=0.0172970667 y=-0.0245058369 z=0.0205858145, w=-0.999337912    }

.. with itself, I'm getting a result angle of 0.00138106791 (or almost 0.1 degrees)..


I'm just wondering if this is acceptable error when working with float variables? And is there anything I can do to improve this issue other than switching to double type or something else as drastic?


edit note: After testing some more, the highest "error angle" I've been able to generate (through random axis-angles) is 0.001953125. And that was getting the angle (from itself) of a quaternion generated by the axis @ angle: { -0.833756,0.551120,-0.033417 @ 2.960138559341 } (quaternion result: { -0.830327,0.548853,-0.033279,0.090603 } )


Thank you


The reason why the error gets so big, is that the inverse cosine function is very steep around 1. This has the effect that the (even exact) inverse cosine of a dot product which is only a tiny bit off, will give a pretty big angle difference.


For example, the cosine of 0.1 degree is 0.99999847691, and so if your dot product would give 0.99999847691 (which is a pretty good approximation of 1), the angle you get will be around 0.1


I bet that the reason why, after renormalizing your quaternions, you did get the correct result, was that this gave a dot product of exactly 1, but I don't think this will work for all quaternions. There will certainly be normalized quaternions, which give a dot product with themselves not exactly equal to 1.


The good news is that it's only this bad when you're computing the angle between quaternions which are almost parallel. For quaternions which are not nearly parallel, the result will be more accurate.

In Topic: Calculating the polygon outline from the set of overlapping polygons

17 June 2014 - 05:40 PM

What you want is http://en.wikipedia.org/wiki/Boolean_operations_on_polygons with the union operations. It's definitely not an easy thing to implement though, so if you can find a way to do without this, it's probably preferable.

In Topic: Why is Guass method better for finding determinants of a 3x3 and 4x4 matrix?

04 December 2013 - 02:48 AM

But after Gaussian elimination, the elements in d,g,h are 0, and so all terms in aei + bfg + cdh - hfa - idb - gec vanish, except for aei. But indeed, for 3x3 matrices it's probably still faster to compute it using your formula, but the number of terms in that closed form is n!, with each term consisting of n factors (where n is the number of dimensions), so the complexity grows much faster than with gaussian elimination, where after bringing your matrix to reduced form, always just a single term remains. 


The reason they put a negative sign before the determinant was probably because they did an odd number of row exchanges. Each time you exchange rows, the sign of the determinant changes.