Saturday, March 12, 2011

Layers in Detour

Well.. this may look like a unmeasurable step in no direction at all, but it is indeed layered tile pieces working in Detour! There are a lot of rough edges to be fixed, but I'm glad I got this far.

Some things were a bit painful to debug. Looks like the tile stitching needs to be redone at some point in the future. As you can see in the above picture, the navmesh is missing a detail mesh. I have an idea how to make a semi good detail mesh really quickly.

Anyways, once I check in the stuff it means that Detour and Recast APIs will change a bit. I will write migration guide once I have polished the code a bit.

8 comments:

  1. Looking quite promising, Mikko. Is it my imagination or is the resulting navmesh alot more "coarse" coming out of this?

    ReplyDelete
  2. Yes and no :) The navmesh polys are about the same, there are a couple of extra vertices thought. So the data that is used for most of the operations is about the same.

    What is most different in the above picture is that the detail mesh is missing. Detail mesh captures the height differences on those curved surfaces. The way the detail mesh is currently build is too time consuming for regenerating tiles quickly, but I have an idea how to improve the heigh accuracy and still keep the process really fast.

    ReplyDelete
  3. Yes, it was mainly the top right case that tweaked my "hang on a second" reflex. I'll wait until you're finished then before making stupid remarks about the WIP :)

    ReplyDelete
  4. Why do you need a special detail mesh? Wouldn't it be possible to simply map the query-position on the 2D grids?

    ReplyDelete
  5. @btolputt, ok :)

    @YAY, that is one potential solution. The problem with that is how to store the heighfield in such case?

    Keeping all the tiles uncompressed is too memory consuming. But maybe some kind of cache of currently used layers could work and evict them if not used recently. Or maybe some other format which is much more compressed than the heighfield, like, a triangle mesh... ;)

    Anyways, it needs further testing. For example animated character foot planting could benefit from the heightfield data since it can also describe high frequency detail (i.e. discontinuities like stairs). I'm currently trying to get the layer stuff up to the par of the existing solution and then see if it could be improved.

    ReplyDelete
  6. Are your heightfield precise enough to avoid artifacts when used for foot planting ?

    ReplyDelete
  7. It is not going to be as accurate as something you would get from physics raycasts, but it is more accurate than the detail mesh that is stored in the current recast implementation.

    Definitely not AAA FPS quality.

    ReplyDelete
  8. This is the reason why we're sticking to exact ground representation in Golaem Path, we need the data for animation.
    But there's a tradeoff in memory footprint and the perfs.

    ReplyDelete