[Tool] Navmesh Creator

[caytchen]

thanks.
doing exactly as you/me said and still missing doodas. Particular case is
WORLD\\WMO\\KALIMDOR\\OGRIMMAR\\ORCHOVELORGRIMMAR.WMO - hut on the left of orgimar front gates, kalimdor_40_29. In the game this wmo has interior (shelf, couple barrels), but it has 0 doodasSet. However if i am drawing doodas referenced in MODR chunks - those doodas are present there + bunch of junk doodas. Same story if i render all doodas from MODN chunk of wmo instance - proper ones + bunch of junk.
However, this wmo has 5 doodas sets defined, and those are correct ones.. but why doodas set # in modf is 0?

0 is a perfectly valid doodadSet index. It doesn't mean that it has no set at all.

[ostapus]

yes, but that set (which is always/mostly "Set_$DefaultGlobal") has 0 # doodads

---------- Post added at 11:49 AM ---------- Previous post was at 11:44 AM ----------

ok, going to ask for favor, if someone can check kalimdor_40_29, the hut on the left of orgrimar gates (on the left if facing to the gates) has any interrior doodads (except one barrel which comes from general doodads for this adt)?
coz according to game view, sets 1 and 3 should be rendered (there are 2 instances of this wmo on that map, sets # 2,4 are junk sets), but again, set # in wmo info is 0

tia

update: fixed it, again modf structure info taken/stolen from wowmapper was incorrect (the size of flags is not int32 but rather in16)

[cvccbum]

Does anyone have an example or something to point me in the right direction on porting R&D to C#? I am not looking for a hand out, just not sure where to start. I have made the navmesh files, but am unsure how to read them correctly. I have looked at the R&D source and I see how they're doing it, I'm just stuck getting it to work in C#. Right now my bot is using a pathing system very similar to Pirox bot, and I would love to start using a navmesh instead. Any help is appreciated.

[namreeb]

Porting it to C# will be very painful. I believe if you search the R+D discussion group on google you will find a posting of someone who has done it. In my opinion it is better to write yourself a C++/CLI wrapper and expose the methods/data types which you will be needing. If you already have the code to generate your meshes (I'm assuming that code must be C++), then you can forget about all of Recast and need only expose a few methods in Detour. This has the added benefit of making it almost free to update your copy of R+D as Mikko makes changes to it.

[dook123]

Doing a C++ wrapper is the way to go as Namreeb has said, I currently use RD in C# this way and it works very well.

edit--

Any suggestions for cs/ts settings, I am getting zig zagging movement...

edit--

I was returning the wrong coords... oops -_-

[amadmonk]

Anyone keeping up with Mikko's recent (last few weeks) work to incorporate dynamic mesh changes?

I've been trying to avoid putting navigation information in my steering lib (and vice versa) and I'm wondering if anyone's keeping up on this as a possible "stay out of the fire" alternative.

[namreeb]

I have been following it religiously. Basically the process of making a mesh with Recast is as follows:

- Rasterize/voxelize input geometry
- Create span field
- Filter unwanted spans
- Build regions
- Merge regions
- Create contours
- Merge contours
- Extract triangles
- Merge triangles into convex polygons. This is your mesh.

Now, you can do the first three steps and still potentially add geometry. This is what Mikko is suggesting. Rather than meshing your terrain and saving the mesh, he is suggesting you perform steps one through three, and save those results. Then, when you are in-game you complete the meshing process. This gives you the opportunity to insert objects prior to completing the remaining steps.

Moreover, you can repeat the process easily as you still have your cached results for steps one through three of the bulk of your geometry.

It's also worth noting that time wise, step one I believe takes generally 50-75% of the overall build time. So while there are quite a few remaining steps, they go relatively quickly. Mikko's tests have him completing the remaining steps in approximately 20ms.

Any suggestions for cs/ts settings, I am getting zig zagging movement...

I posted the settings I had been using with Recast a week or two ago. Just search.

[dook123]

I posted the settings I had been using with Recast a week or two ago. Just search.

Funny how you overlook things, I have been over that page a couple times and missed it. Navmesh is currently working but I think I will test out your settings, I know I need to consider height and width of characters still.

[namreeb]

Mikko has just posted an update to his blog for those interested: Digesting Duck: First Iteration of Temporary Obstacles Checked In

[amadmonk]

Yeah, that was actually what prompted me to ask about it; it seems like he's getting close to having a working solution. Since I'm just a lazy leecher when it comes to nav stuff, I was wondering if any of the "big boys" were keeping up with Mikko's work on the topic (last time I spoke with you about it, from what I remember, you weren't too impressed with the dynamic re-meshing method, but my memory sucks from too many years of abusing too many things).

[namreeb]

Well, he hasn't really changed anything here. There is no new math involved. He's just saying wait to do the last steps until you know about the new objects. That's one step up from just remeshing the whole thing. Meh, I'm not too impressed compared to Mikko's usual work. Seem like a bit of a cop out. He is continuing to investigate ways to do it more directly. So am I.

That said, this approach does work.

[Megamike55]

Below are the settings I used when I was using Recast. Note that, though its not specifically documented, many of these settings are dependent on the others. That is why I made up a few variables of my own and set the Recast parameters in terms of them. This way I don't have to remember the relationships. For example, the cell size must perfectly divide the tile size. Another example is you must provide at least enough geometry beyond the tile boundary to account for half of an agent width (I think).

For accuracy, you want to pick a cell size that will nicely divide your agent's radius and a height that will nicely divide your agent's height and maximum step size. By nicely I don't necessarily mean divide exactly, but close to it. The closer you are, the more accurate you will be. However, to exactly divide everything perfectly, you'll have a cell size so small that your meshes will be enormous.

As for tile size, the problem I had with Recast was that with large tiles you can get long and skinny mesh polygons. This can give you some non-optimal paths because of the string pulling algorithm being used in Detour at the time. This may or may not still be the case, but currently I am experimenting with MCNK sized tiles.

I think MaiN does either four or 16 tiles per ADT.

        private const float T...;

For anyone having as much trouble getting your nav mesh perfected as I am, here are some clarification questions that will hopefully help us (I have nav meshes generated for the whole world, but my navmeshes overlap badly and I end up with zig-zag movement between ADTs so I'm trying to fix that. I incorporated the information generously provided by namreeb but these are my questions to kind of get it all together in my head)
1) So you should provide about 10 or 11 world units of extra border geometry, right?
2) After providing the extra geometry,

	// Set the area where the navigation will be build.
	// Here the bounds of the input mesh are used, but the
	// area could be specified by an user defined box, etc.
	rcVcopy(m_cfg.bmin, bmin);
	rcVcopy(m_cfg.bmax, bmax);
	rcCalcGridSize(m_cfg.bmin, m_cfg.bmax, m_cfg.cs, &m_cfg.width, &m_cfg.height);

This bit of code (sorry if it is out of date a little, I don't constantly grab the latest Recast updates) should be set to restrict the bounds to the original ADT bounds, not inclusive of the extra geometry?
3) Terminology: Cell = what, exactly in Recast usage. Is it the dimensions of one voxel?
4) Terminology: Region = what, exactly in Recast usage. This one I never really understood.
5) I personally use a verts-per-poly of 3. This gives me only triangles to deal with, which at first was easier than allowing recast to do 4-6 verts per poly, then having to store / read and search within polys instead of simple triangles. Do other people do the same, who aren't using Detour?

I think that covers the areas I'm uncertain about. I'm especially unsure about question #2. EDIT: #2 - The more I think about it, the more I am certain that I have to set it as so. Could someone confirm this anyway?

[namreeb]

1) So you should provide about 10 or 11 world units of extra border geometry, right?
2) After providing the extra geometry,

	// Set the area where the navigation will be build.
	// Here the bounds of the input mesh are used, but the
	// area could be specified by an user defined box, etc.
	rcVcopy(m_cfg.bmin, bmin);
	rcVcopy(m_cfg.bmax, bmax);
	rcCalcGridSize(m_cfg.bmin, m_cfg.bmax, m_cfg.cs, &m_cfg.width, &m_cfg.height);

This bit of code (sorry if it is out of date a little, I don't constantly grab the latest Recast updates) should be set to restrict the bounds to the original ADT bounds, not inclusive of the extra geometry?
3) Terminology: Cell = what, exactly in Recast usage. Is it the dimensions of one voxel?
4) Terminology: Region = what, exactly in Recast usage. This one I never really understood.
5) I personally use a verts-per-poly of 3. This gives me only triangles to deal with, which at first was easier than allowing recast to do 4-6 verts per poly, then having to store / read and search within polys instead of simple triangles. Do other people do the same, who aren't using Detour?

I think that covers the areas I'm uncertain about. I'm especially unsure about question #2. BTW: Love this thread, lots of great info.

1.) It depends. While that should be enough, its important to mention how you arrive at that value. You want to include at least two multiples of your defined agent radius. In other words, you want to leave enough room for the agent to walk around the outside edge of your tile.

2.) This should be answerable from the Recast settings I have provided. In short: bmin/bmax define the box of the tile, not the input geometry. That is, if you were to give Recast an entire ADT you could get back a tile for just a chunk of it by giving the appropriate bmin/bmax/etc. values.

3.) Cell is a voxel. See The Voxelization Process | CritterAI for a description of voxels. There are other pages on that site which have very helpful descriptions/graphics of the process Recast uses.

4.) A region is a collection of spans in the height field which meet a certain criteria. The previously linked site has some information about this. Also useful for describing regions is a post pendra made on this forum some time ago:

for y in height dimension
for x in width dimension
for span in cell at x,y
if span is not already in a region
if span has neighbor to the left, mark it same region as that one.
else if span has neighbor above, mark it same region as that one
else make it the first span in a new region
end
end
end

5.) Two thoughts. Firstly, your mesh can always be broken into triangles regardless of your vertsPerPoly figure. This is what the detail mesh is. Secondly, Mikko has done some testing and found a vertsPerPoly of 6 to be generally optimal. See his slides on the process here: https://sites.google.com/site/recast...castSlides.pdf

For the verts per poly figure its the fifth or so slide from the bottom, but that pdf includes much more useful information besides that.

[ostapus]

i am storing compressed tile info addition to navigation data tiles ( 1 to 1, each nav data tile has corresponding compressed heightfield data) and when higher level nav function (the one which actually moves the character) detecting that character is stuck (time to travel from point a to b is greater than "supposed to be" time) - it will set temp obstacle object right ahead of character "stuck" point and regenerate affected tiles and path.

[amadmonk]

And... Mikko gave up (for now): Digesting Duck: My Recent Failures in Polygon Clipping