Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

313 Neutral

About Eleventy

  • Rank
    Advanced Member

Personal Information

  • Role
  • Interests


  • Twitter
  • Github
  • Twitch
  • Steam

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Eleventy

    What are you working on?

    This is a good PDF overview of how to implement the QuickHull algorithm: It was written by a Software Engineer at Valve. For my implementation of it, I am referencing this PDF. Note the invariants that are mentioned, as they are important, especially for faces with more than three points. Without taking those into account, you will run into cases where you'll generate cubes with triangles instead of squares, etc. The algorithm also shows how to do it in 2D just for reference, but there is a much better method in 2D to get the convex polygon (Graham Scan).
  2. Eleventy

    What are you working on?

    I am currently working on an algorithm to generate a convex polyhedron from a set of points in 3D. I am implementing the QuickHull algorithm. It seemed straightforward, until I realized I also have to implement the Polyhedron itself - this involves coming up with how to link faces and edges to each other in order to execute the flood fill method that generates the 3D horizon. I have managed to generate an icosahedron from 12 points and have verified it to be identical to the known structure. Even that test was involved, as yet another algorithm had to be developed to generate a polyhedron from a set of faces (in case anyone is interested, you can simply create a tree map of edges to faces and then check the edge of each new face against that map). Note that I said tree map, as one cannot create a hash of a floating point value - another obstacle that had to be overcome, as even copying a floating point value in memory apparently changes it slightly. Any floating point comparison has to be done with a tolerance value - including structures such as sets and maps. So I had to "invent" the 'tolerance set' and the 'tolerance tree map'. Once this is done, I can then proceed with my cubic Bezier curved surface / plane intersection algorithm, part of which involved generating a convex polyhedron.
  3. So this method does indeed work, with some caveats: The 3D -> 2D plane projection process can introduce a loss of precision and can cause false negatives in regards to line segments. Example: If one has a 3D line segment starting at (2.5, 2.5, 0.0) and going to (5.0, 5.0, 0.0) which happens to hit a point along a Cubic bezier path segment that crosses (2.5, 2.5, 0.0) in the exact middle of the cubic path (T value of 0.5), one would expect a an intersection at (2.5, 2.5, 0.0) with a T value of 0.5 and a U value (representing the position along the line segment from the starting point) of 0. However, the result ends up being something like (2.4999045..., 2.4999045..., 0.0) with a T value of 0.49995.. and U of -0.0001.. This value lies outside of the line segment (and is also beyond the tolerance of my epsilon-based floating point equality checking) and would not be considered an intersection. A possible solution is to "snap" values close to U values of 0 to 1 within a large multiple of the binary double floating point precision epsilon (from my testing, the multiple that works is 1.0E10 - this like having values like 1.0E-6 equal to 0.0). However, I cannot simply override the U value to lie within the line segment, as I would need a full solution that contains all valid fields. In addition, I have to check that a point at this U is indeed on the Bezier curve. I need the Bezier's T value for a point. I take this "snapped" U value, find the corresponding point along the line segment (which should be very close to the initial (2.49.., 2.49.., 0.0) value - in this case (2.5, 2.5, 0)) and perform a Bezier closest-T to guessed T and Point Newtonian approximation method with the 0.4999.. T value to get the corresponding Bezier T value, which should now be at or very close to 0.5. I then confirm equality with both points to ensure a collision within the line segment and bezier curve took place. It seems like a lot for such a special case and it might be computationally inefficient, but it appears to work. If anybody has any other ideas in regards to dealing with floating-point precision issues such as these, please let me know.
  4. Thanks! Good to know that any projected plane will work with this method, and that it is fast - once I create the rest of the 3D counterparts to the 2D system I already have in place, I will implement this method.
  5. I am seeking advice regarding whether the following algorithm works (and if so, is the fastest) for a 3D line segment intersecting with a 3D cubic bezier curve: To test for intersections of a 3D line segment with a 3D bezier cubic path segment, project the 3D cubic path segment and the 3D line segment along a plane coincident with the 3D line segment. The chosen plane orientation should not cause the resultant 2D bezier cubic path segment to be linear unless its 3D counterpart is also linear. By default, the orientation will be along the Y axis (a vertical plane perpendicular to the X-Z axis). Then, perform a normal 2D bezier cubic curve/2D line intersection. For each found T value in the 2D intersection, only keep the T values in the 3D counterpart curve having all three coordinate values that are intersected by the actual 3D line segment.
  6. Eleventy

    Rotation matrix multiplication causes Gimbal lock

    Depending on if you want to have true 360-degree freedom, you could implement a system where each object has an up vector, a right vector and a forward vector. When rotation occurs, those three vectors rotate along with the object. Whenever an object rotates, you then use one of those three axis to rotate the object around, using the arbitrary rotation axis matrix: Example code (axis is the axis of rotation and radians is the degrees to rotate): axis = vector_normalize(axis); float ct = cosf(radians); float st = sinf(radians); float ci = 1 - ct; float x = axis.x, y = axis.y, z = axis.z; return matrix_make(ct + x * x * ci, y * x * ci + z * st, z * x * ci - y * st, 0, x * y * ci - z * st, ct + y * y * ci, z * y * ci + x * st, 0, x * z * ci + y * st, y * z * ci - x * st, ct + z * z * ci, 0, 0, 0, 0, 1); As an example, when an object pitches up, rotate the object along the right axis and also rotate the "orientation" vectors along that same axis. When you perform another rotation (for example, turning right), rotate the object around the new up vector for the specified number of degrees (and, also rotate the orientation vectors). Another option is to use quaternions.
  7. Eleventy

    Torque and Angular Momentum

    Thanks! Your response is very helpful. I will look through my code and see where there might be one of those pitfalls you mentioned happening, as I do not feel that having to flip both the X and Y axis on the 'forward' vector and the Z-axis on the 'up' vector for the look-at matrix, in conjunction with having to flip all Z components of the position vectors for everything in my world is indication that I am doing everything right.
  8. Eleventy

    Torque and Angular Momentum

    Ah, I realize now why I have seen some other tutorials have the cross products reversed - given that the cross product is not commutative, that never made much sense to me until now. Good to know that matrices (and perhaps other components) also have this same issue. Now that I think about it, I did have to do some weird logic calculating the "look at" matrix and reverse all of the Z coordinates in order for my scene to even render and for movement to work correctly to begin with, as OpenGL and Metal is apparently configured to use a right-handed projection matrix by default (with no known way to change it).
  9. Eleventy

    Torque and Angular Momentum

    So, it appears that I am using a left-handed coordinate system, and the cross product in such a system always goes the opposite direction (you can see such an explanation here: In my example above, in the right-handed coordinate system (positive X is to the left, positive Y is straight ahead, and positive Z is straight up), I would be calculating [1, 0, 0] cross [0, 1, 0], yielding [0, 0, 1], which looks correct. If I use the left-handed version of the cross product, I will get the correct result of [0, 1, 0] for the angular momentum vector. Weird that different coordinate systems even exist at all. I have always worked with the left-handed system in game development. Now I will have to replace all of my cross product calls with a special 'cross_lh' version, as my entire game engine has been unknowingly developed in this left-handed system.
  10. Hello, I am currently in the process of developing angular momentum for my game, and I am implementing torque for the purposes of changing objects' angular momentum. If I understand torque correctly, it is calculated by the position vector (R) (position the force is applied relative to the object) with the cross product of the force vector (F). The torque is then added to the angular momentum, resulting in the object starting to rotate. The angular momentum vector determines the direction the object rotates. An angular momentum vector of [0, 1, 0] should then cause an object to rotate to the left (it would spin counter-clockwise). So, to get an object to spin to the left, one would apply a force of [0, 0, 1] to the position of [1, 0, 0] (e.g. a force going forward applied to the right of the object). Positive X is to the right, and positive Z is going forwards. However, when I calculate R x F (e.g. [1, 0, 0] x [0, 0, 1]), I am getting torque result [0, -1, 0], which would cause the object to rotate clockwise instead of counter-clockwise. I figured my cross product calculation was wrong, but even Wolfram Mathematica gives me the same result. Am I missing something? Even the animations on Wikipedia's explanation of what torque is demonstrates that a force applied to the right of an object causes it to spin to the left (the animation clearly shows the vectors, and the torque vector is going upwards). Not to mention, this is what happens in real life. Is there something different about the coordinate system being used?
  11. Eleventy

    Worth a buck

    Any recommendations/preffered-vendors that you have personally used? [/quote] I obtained a merchant account from Their application process is pretty straight-forward. They also have low fees and very good customer service. The only thing you'll need is standard ID documentation and at least one valid business-related trade reference (such as a vendor, supplier, marketing partner, etc). If you don't want a full-blown merchant account, you can also go with other services such as FastSpring and 2CheckOut. Though, I have never used the last two. P.S. You should do a Google search for "paypal microisv" and read the first article.
  12. Eleventy

    Worth a buck

    Don't use PayPal as the only way to accept payment. They'll randomly put your transactions and account on hold when they feel like it, especially if you are a startup microISV. Go with a real merchant account. Or have a merchant account / PayPal account combination.
  13. Eleventy

    How do you market/advertise you indie game?

    I was faced with similar challenges earlier. There is actually some good advice in a thread of mine here: One good avenue for gaining traffic is blogs. Find a blog site with high traffic and ask the owner to advertise your product for free (or for a cost). Another good method for "building a community" would be to run a free beta test.
  14. Eleventy

    Post your website, get candy

    Might as well post mine here too (everyone else is). This is currently a product of mine (in the beta stage): ChronoWall It's an advanced, seasonal and time-based wallpaper manager.
  15. Eleventy

    Has anyone here ever launched their own product?

    Thank you for your comments. The next beta version (0.91) will definitely have a short (7-day) period where the user can use it without a beta key. That will probably draw significant interest and beta testers. At least they can see a product that is fully functional. Mayple - thank you for recommending the and twitter/twiends methods (I was unaware of those before). You reasoning of using that email service makes sense - given that I am not well-known, people probably haven't developed a level of trust for me yet. That twitter marketing idea sounds very interesting and I will definitely be taking that avenue. I also discovered StumbleUpon, and they have what is called 'Paid Discovery'. I will try that as well. Again, thanks!
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!