Why rcMarkConvexPolyArea uses an extruded xz-plane clamped intersection check instead of point-in-polygon?

[Gabriel Garcia]

Hello there! Love the project and plan to contribute to it eventually. But, I'm just wondering the reasoning behind the design decision of making rcMarkConvexPolyArea so:
"The y-values of the polygon vertices are ignored. So the polygon is effectively projected onto the xz-plane at @p hmin, then extruded to @p hmax."

Instead of using a Point-In-Polygon (PIP) algorithm such as the ray cast algorithm? I imagine due to the complexity that would be for the user to provide a properly winded polygon vert list? Is that something I could contribute maybe?

Cheers!

[Graham Pentheny]

Hey Gabriel.  The intent of this function is to allow for marking arbitrary polygon-bounded areas of the navmesh with specific area IDs.  This is often used for things like marking roads as lower traversal cost and swamps/mud as higher traversal cost.  Because only the farthest horizontal plane extents of an obstacle is necessary when marking its projected outline onto the navmesh, this function just squashes the polygon vertically and then extrudes it along z.  For example a 1m diameter sphere resting on the ground creates a cylindrical obstacle, which logically makes sense for an agent modeled as a capsule/cylinder.  This function is quite crude in its approach and it's easy to think of cases where it wouldn't work, but it's very often sufficient for many people's needs.  I suspect the documentation for that function could be a bit better to include this kind of rationale behind it.

Best,

Graham