• entries
    26
  • comments
    42
  • views
    22751

Almost Normal

Sign in to follow this  

345 views

Major bug located in my triangle-splitting implementation.
My algorithm for finding the intersection of a line segment (ie 'edge') and a plane expects the two endpoints of the line segments to be handed in a particular order, which I was not observing in all cases.
The result was that some child triangles were being created with incorrectly interpolated vertices, directly leading to them being incorrectly classified in subsequent iterations of the tree generating algorithm.
I hope I fixed all the cases, I will check them over today. I don't want to continue to examining the portal generator output until I am absolutely convinced that the tree is correct.
This brings me to a small point of contention.
The surface normals for some of my planes are being returned as 0.99999994 rather than 1.0 , and although this inaccuracy might seem acceptable given my planar tolerance of +/- 0.005, rounding errors such as this quickly add up over several recursive iterations - and especially so when we are bisecting space !!!
Should I be clamping normals to 0 and 1 when they are very close to being so? This assumes that there is much orthogonality in the 3D world, which I guess is a common scenario, even today. But given that I expect to handle organic shapes too, is clamping a good idea?
The fact that my Normal is not always exactly unit length for a plane aligned to a Major Axis is a bit of a concern.
What would you do?
Sign in to follow this  


1 Comment


Recommended Comments

I'm no floating point expert, but I know you can run into precision issues depending on the way you "do your math". You can work out on paper any equations and series of operations you're going to implement in code, but a straightforward translation is not always the one that will work best in the end. Maybe the code is not fast enough, or (as in your case) you're getting precision deviations. There are some clever "tricks" for re-arranging operations, grouping, etc, that you can employ to solve some of these issues - not all of them are obvious. I'll try to find some references I may have stashed away some time ago, but searching for "floating point precision errors" or something along those lines, in the context of coding, might turn up useful tips on the matter.

I know I've read useful stuff even from nVidia articles on floating point on the GPU (the IEEE-compliant part anyway), besides articles scattered around in the web. If I find the premium ones, I'll get back to you :).

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now