search

senoutouya / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

Inefficient path calculated in certain circumstances #200

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Have a navmesh like on attached screenshot

What is the expected output? What do you see instead?

It should choose the obvious path

What version of the product are you using? On what operating system?
r338 , Linux 64 Bit with 64 bit polyrefs ( using 32bit polyrefs does not solve 
problem )

Please provide any additional information below.

I've attached the mesh used to reproduce the problem too

Original issue reported on code.google.com by tizb...@gmail.com on 4 Apr 2012 at 8:54

Attachments:

GoogleCodeExporter commented 9 years ago 
This is expected behavior for nav meshes. See my blog post on topic: 
http://digestingduck.blogspot.com/2010/08/visibility-optimized-graph-experiment.
html

The problem is large polygons right next to smaller polygon. Tiled navmesh 
often gives a bit better results.

Original comment by memono...@gmail.com on 5 Apr 2012 at 10:59

GoogleCodeExporter commented 9 years ago 
yeah i've tried tiled navmeshes , but i would need so small tiles that i'll end 
up with an insane count of tiles (i'm talking of milions of them ), couldn't 
you implement an option on recast that limits polygon size?

It's not a problem on our application having more polygons, it will also 
increase detail mesh precision

Original comment by tizb...@gmail.com on 5 Apr 2012 at 11:45

GoogleCodeExporter commented 9 years ago 
ah , i've forgot to say that it is already a tile the one on screenshot, to 
make it work properly i have to make it composed of 32*32 tiles , and i have 
already 60k of these "big" tiles

Original comment by tizb...@gmail.com on 5 Apr 2012 at 11:47

GoogleCodeExporter commented 9 years ago 
Basically , to make it clear , i need an option on navmesh generation , that 
gives the result of a tiled navmesh with smaller tiles on a single bigger tile

Original comment by tizb...@gmail.com on 5 Apr 2012 at 11:55

GoogleCodeExporter commented 9 years ago 
Splitting the polygons is not trivial to implement, but I'll try to find some 
time to take a look at it.

Original comment by memono...@gmail.com on 5 Apr 2012 at 4:56

GoogleCodeExporter commented 9 years ago

Original comment by memono...@gmail.com on 16 Sep 2013 at 7:02