adaption recast / detour to 2D tile-based game

[vgb]

Hello
I'd like to use recast and detour for my game. Except instead of being 3D it's a 2D top down view where the world is based on tiles. Each tile can be blocking or passing (for now), so the collision data is basically a boolean 2D array.
I'm a bit confused as to what would be the best way to use recast to generate the navmesh.
From what I understand I could generate a .obj file from my map and process it like it's done in the demo. However I'm assuming there is a simpler way to do this (how?) as I've read that recast can have other data types as input.
So what would be the easiest way to process my data, using the existing API ?
thanks a lot !

[Krom Stern]

How big are your maps going to be, more like 32x32 or 1024x1024?

[vgb]

probably around 200x200 (tiles)

[Krom Stern]

Since there are no other replies:

From my uderstanding, you can skip a lot of initial navmesh building steps. 

For example you can build a heightfield in Recast format yourself and continue generation from it (skipping erode and filter stages, which are mostly used for 3D maps).

[vgb]

Thanks!

I'm trying a few things but it difficult for me without real knowledge of exactly what all the parameters do.
Here's what I did :
- cloned Sample_SoloMesh class from recast demo
- in the HandleBuild(), removed the  whole "Step 2. Rasterize input polygon soup." part. Instead I randomly generate either passing tiles (height = 0) or blocking tiles (height = 1), in the rcHeightfield data
- launched Recast Demo
- set Cell Size to 1 : this gives me 60x60 voxel grid
- hit build
- the voxel data generated is basically the kind of input I want to work with, so that's ok  ( img : http://imgur.com/KHr2dZi,H8kB6XA)
- however the nav mesh generated is really inprecise (img : http://imgur.com/KHr2dZi,H8kB6XA#1)

can someone please shed some light on this  ? I assume I recuce the resolution of the navmesh a lot when I set the CellSize to 1 ( = 60x60 voxels)
How can I fix this ? Ideally I'd like to keep my 60x60 voxel input because it's closer to what data I'll actually have

[Patrick Baggett]

If you use a tile-based world, then I don't think you really need a navigation mesh. Naive A* works fine for small values, and then when you need to optimize it, try jump point search[1].

[1] https://harablog.wordpress.com/2011/09/07/jump-point-search/

--

---
You received this message because you are subscribed to the Google Groups "recastnavigation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to recastnavigati...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vgb]

Hi

thanks, but for now I'd mostly like to use recast (and detour), because the feature set is really complete and powerful. It seems like just a bit of tweaking is needed to use tile-based maps, whereas using naive A* is already complex as is (unless I pull a special lib for this) , and trying to optimise it further is way beyond my skills

[Patrick Baggett]

OK, I disagree, but...

The screenshot looks like might be eroding the navigation mesh - if you see an option for that, disable it; you shouldn't need to at all since agents should fit exactly through boundaries and can come infinitely close to them. I would also make sure that all voxels are integer units in size and that your obstacles are also integer units in size. Doing this should help mitigate floating point precision errors. You edge error ideally should be ... 0, since the polygon's points should map 1-to-1 with the corners of the voxels. You probably should keep 4 vertices per polygon, since there should be (almost?) no way to generate a convex n-gon with n > 4 by removing rectangular areas. The agent radius should be exactly 1/2 of the voxel size (and hope that Recast will allow 1.0 diameter agent through a 1.0 unit-sized hole).

Good luck.

Patrick

[vgb]

Hi

ok after some more fiddling I manage to get decent results (see pics attached)

It seems that the problem was the CellSize... if I create it such that 1 tile = 1 voxel , this won't work at all.
Putting a CellSize of 0.3 works much better and now there is actually enough room for the actors to pass when there is only 1 tile of space available. (shown in red)

However the erosion part creates weird cross shapes for the tiles... do you guys think it's normal ? I've highlighted it in green in the pic.
For me, the base of the voxel, when eroded, should still have a square shape (but bigger). I don't get why it's doing a cross shape, could it be that the erosion algo is approximated to just expand in X dir and Y dir ? Or am I missing something?

[Mikko Mononen]

Hi,

The voxel size should be 2-3 x the agent radius. Say, your agent radius is 0.4, and your tile size is 1.0, the voxel size should be 0.2. Among the other things, this should results the erosion to create a chamfered edge around the non-walkable areas. Another thing that is causing the cross shape is edge error, it should be around 1.5 (the default should work fine). Since your level is axis aligned shapes, it might be possible to have voxelsize = agent radius, I recommend the 2x, though.

--mikko