Change Recast Orientation
Michael K.
First i want to thank you for your great work on this project. It
looks really great and works fine in my code.
Currently I'm using OpenSceneGraph for reading node-files and
displaying them. While creating NavigationMeshes with Recast I got
some problems because OpenSceneGraph uses another coordinate system.
It uses ENU-notation. At the moment the conversion is in the mesh-
creator which reads out the data from OpenSceneGraph and builds a
triangle mesh. But my favourite solution would be to change the
notation recast uses because the triangle mesh should be the same
notation OSG uses.
Is that possible and how could I do that? If someone has a easy trick
let me know. ;)
best regards
Michael
Mikko Mononen
How does a point on ENU-notation look like? Based on what I gather
from wikipedia, it looks rather scary :)
Recast assumes one up direction through out the data. I.e. it cannot
generate mesh that would be on the surface of a sphere.
If your problem is more about having different up-axis, then the
following might be relevant.
There was quite some discussion about different up axis last autumn.
There is an issue for it too:
http://code.google.com/p/recastnavigation/issues/detail?id=9
Though, I'm slowly leaning towards not implementing this feature.
There are a lot of code in Recast which makes the assumption that the
data lies on xz-plane, and making all that code to handle arbitrary
plane and potentially different winding is loads of work with very
little gain.
The best way to handle different coordinate systems when building a
navigation mesh is to have a matrix which transforms the data from
your coordinate system to Recast's. At runtime, when you use Detour,
you are most likely to build wrapper around it. Since you are only
dealing with point data when you use Detour, it is easy to write a
simple function which will take Detour point and transform it back to
your own. For example here are functions to transform from Y-up to
Z-up notion:
inline void customToRecast(const Vec3& v, float* p)
{
p[0] = -v.x;
p[1] = v.z;
p[2] = v.y;
}
inline Vec3 recastToCustom(const float* p)
{
return Vec3(-p[0], p[2], p[1]);
}
If there is huge demand for it, I can add a custom conversion matrices
into the pipeline. Currently I see it very little use, because most
people end up writing wrappers around Recast and Detour (that is also
the usage I encourage) and it should not be big deal to make the
wrapper also transform the data.
I do acknowledge this is not userfriendly especially when doing the
first integration.
--mikko
shawn
Micheal,
in response to mikkos reply, I took the approach he outlined of
transforming my input data into recast space. Because heavy
customization was needed at runtime I transformed the resulting data
back to my coordinate system upon save. This did require some slight
changes to detour to acount for the change in the up axis. Overall the
changes were minimal.
If you run into any issues ping me and I'll see if I can help out.
Shawn