Recastnavigation specifically Detour serialisation?

[Harland]

A few weeks ago I took interest in adding recastnavigation to my bot as it looked to be the flavour of the month (although namreeb, main, and Apoc are obviously saying that is soooo 2009).

With all the information available on Wow.dev whipping up a parser was easy enough, to dump an .obj file for the world geometry.

Once you feed the .obj file to recast you can then generate the navmesh geometry. Now here is where I have stumbled across a question with detour. Are most of you using a custom (de)serialisation method to retrieve/store the navmesh geometry to be used for detour? Or is there some sort of prebuilt load/dump function that is available in the detour lib already? The only method I have come across that stores the navmesh is the duDumpPolyMeshToObj. Unfortunately it is only useful for debugging, and stores the navmesh geometry in the inflated .obj format. Not very useful for detour at all...

Anyways I'd just like to thank Main, namreeb, Bananenbrot, pendra, Apoc (sorry if I missed a few people) for most of the useful information and design methodology provided on the said topic in these forums.

[caytchen]

Theres something in the Demo already, check out Sample_TileMesh.cpp - recastnavigation - Project Hosting on Google Code
But its pretty much what you would expect: you store the dtNavMeshParams and then just store every tile. And by tile I mean the data you get from dtCreateNavMeshData. Theres no point in just storing raw geometry or even the mesh data from Recast when Detour can already compile all that data in one binary blob for you.

[Harland]

Cheers for the prompt reply, I'll certainly try that out when I get home from work later tonight. That's exactly what I need, I feel stupid for missing that method.

[Bananenbrot]

Have a look at his bog post:
Digesting Duck: Detour Serialization API

It's well hidden in dtNavMesh class and in the sample posted by caytchen.

I used the built-in serialization API because I was just too lazy to implement my own...
It's quite an overkill because for now you probably will not use most of the recast features that are serialized (e.g. jump links).
So it may be beneficial to save it in a custom format (maybe even compressed).

Seeing that caytchen posted esentially the same answer, making the most of my post redundant... nevertheless, hf

[namreeb]

Recast and detour are by no means irrelevant, obsolete, or anything like that. At the very least, it is a good starting point for developing your own system. It sounds like you want to use the demo app to generate your meshes (if I'm wrong please correct me). This is a very bad idea. You will be processing a very large amount of geometry -- more than that app was designed to cope with. The reason that the detour structures are laid out so strange is so that they can be easily written bit-for-bit into a file (and read in).