search

swordlegend / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

Higher magnitude coordinates cause extra polys in nav mesh #23

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What is the upper / lower limit to the X/Y coordinate values that Recast 
can handle?

The tiles at the edge of my world map go out to about -6400 to 6400. I find 
that the tiles near the center (0,0) have few errors, but that the higher 
the magnitude of the coordinates, the more erroneous polygons appear in the 
Recast meshes. 

Here's an example.

I am loading a mesh with X values in the -5300s, like so:
v -5333.750000 -40.111305 533.375000
v -5337.917969 -40.717781 533.375000
v -5333.750000 -39.976643 529.207031

Please see the attached screenshots:

In "large coordinates error.jpg" I have loaded the file as-is. 

In "large coordinates error B.jpg" I have altered this line of 
rcMeshLoaderObj to move all the coordinates closer to 0:
      addVertex(x+5000, y, z, vcap);

After moving the X coordinates to a lower magnitude, all the false polygons 
disappear.

Is this perhaps a limitation of the float data type? Could a float here or 
there be changed to a double to eliminate this?

Original issue reported on code.google.com by seaninaf...@gmail.com on 22 Nov 2009 at 8:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Floating point coords start to have serious accuracy problems around and past 
4096.0f
(on negative side too) if you assume 4 or 5 decimal points of accuracy (that 
is, use
meters as units). Usually this manifests even more if you use "fast math" 
compiler
switch. The calculations which are based squared distances show the symptom the 
first
(which is the case of detail mesh generation you witnessed).

I changed the detail mesh generation to happen at local tile coordinates (bmin =
origin). This should fix at least the generation side of problems.

If and when you encounter some problems at the runtime bit, let me know and 
I'll try
to find solutions for them. Ideally all the calculations should be done in some 
sort
of local frame, but that complicates the code a lot. Another solution could be 
to
offset the world at certain points in time to be closer to origin.

The generation fix is in the SVN rev 76.

Original comment by memono...@gmail.com on 23 Nov 2009 at 8:52