Recast + 2D obstacles

377 views
Skip to first unread message

Patrick Baggett

unread,
Mar 29, 2013, 2:42:36 PM3/29/13
to recastna...@googlegroups.com
Hi all,

I'm completely new to Recast, so please pardon my ignorance if this question sounds a bit daft. I'm looking at taking the output of the tool RUBE, a list of 2D collision shapes, and generating a 2D navmesh from them (i.e. z = 0 for all points). This doesn't quite look like follows Recast's notion of using only the "walkable" areas of the ground, i.e. the ground itself has polygons.

In effect, what I'm hoping to achieve is closer to taking a large 2D rectangle that represents the entire area of the level (bounding box) and subtracting from it the set of all shapes produced by RUBE. The result is the walkable area -- if you are an infinitely tiny point moving around. I was hoping to use Recast to generate a walkable area if you are an object of some given size and shape. Is such an operation supported (i.e. an implicit floor) and if not, how might I trick Recast into producing the desired results?

Patrick Baggett

Mikko Mononen

unread,
Mar 30, 2013, 1:03:09 AM3/30/13
to recastna...@googlegroups.com
Hi,

Your idea should work. That is, render the background (walkable area)
as one large rectangle with walkable flag set on, and then render all
the blockers slightly higher than the background with walkable flag
set to non-walkable.

--mikko
> --
>
> ---
> 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/groups/opt_out.
>
>

Patrick Baggett

unread,
Apr 18, 2013, 3:35:19 PM4/18/13
to recastna...@googlegroups.com
Hi all,

I've been working on the solution of generating a 2D nav mesh, and so far I've got a  heightfield where I'm rendering it as:

rcRasterizeTriangle(ctx, bl, br, tr, RC_WALKABLE_AREA, hf);
rcRasterizeTriangle(ctx, tr, tl, bl, RC_WALKABLE_AREA, hf);

where bl, br, tr, tl are vertices containing the bounds of the level, with a Y position (height) of 0.0.

I'm then rasterizing the level's geometry with a height of (arbitrarily) 0.25f and a different area ID (0x01).

The only thing is, I'm not 100% sure if I set up the heightfield properly. In rcCreateHeightfield(), I set the 'ch' parameter [height of a cell] to something like 0.25f, my intent being that 0.0 is ground plane,  >= 0.25 is the geometry. Again, ideally, I want the geometry to be "infinitely" tall, i.e. no navigation under or over the geometry.

Can anyone tell me if I'm on track, or if not, point me to functions that I should be using? Also, if I'm not giving enough info, just let me know.

Patrick


Mikko Mononen

unread,
Apr 18, 2013, 5:17:23 PM4/18/13
to recastna...@googlegroups.com
Hi,

You should be able to do the following:
1) render the base walkable area as a rect using RC_WALKABLE_AREA, at y=0
2) render the blockers using RC_NULL_AREA at y=agentHeight/2

If you need to mark certain walkable areas, You can use the convex area marking, or render additional geometry in second pass at y=0.0 (or something between 0 and < stepHeight).

Also make sure the triangle winding of your blocker geometry is correct. I recommend building a little tool or something which allows you to use the debug draw functions to see that each step of the process goes right. 

Your agentHeight can be for example 2*agentRadius, something sensible like that. Use this article as an example for the rest of the params: http://digestingduck.blogspot.com/2009/08/recast-settings-uncovered.html


--mikko

Patrick Baggett

unread,
Apr 18, 2013, 5:22:34 PM4/18/13
to recastnavigation
Thanks for the tips Mikko, those make pretty good sense and the link helps a bunch.

What is "correct winding" -- clockwise or counter-clockwise? Is there any way to specify "two-sided" so I can just side-step this issue? :X

Patrick

Mikko Mononen

unread,
Apr 18, 2013, 6:08:53 PM4/18/13
to recastna...@googlegroups.com
I think the correct winding is CCW. But actually, it does not matter :) If you would use one of the functions which classifies polygons based on slow, then you would need to have correct winding.


--mikko
Reply all
Reply to author
Forward
0 new messages