They aren't used for Recast+Detour, but they are used for the RecastDemo app.
They aren't used for Recast+Detour, but they are used for the RecastDemo app.
Funny question, serious answer: the name Sample_D3dAreaById implies that it's a "sample" which displays (via "Direct3D") areas filtered by their IDs. If you actually read the code and extract the stuff used to parse the map data you can neglect everything related to rendering the actual map geometry.
Actually this project began on linux as one can see on the the front page of the project (look at the screen for version 0.1). And I suspect it to take less than a few lines of code to make it compile on linux if you strip out the windows related stuff like Direct3D.
Agreed.
By the way, apart from the size_t => unit32_t in mverchunk.h which I mentioned (which is not really Linux related), rest was pretty straightforward. To the point I was thinking that it's so close that 2/3 #ifdef WIN32 could be added quite easily. If you wish I can help.
The size_t thing was breaking the tool because although it compiled on my 64-bit system, at run time, sizeof(MVER chunk) was always 4 bytes too large, thus breaking the ADT/WDT parsing at the MPHD step.
Thanks,
Last edited by Nonal; 02-08-2011 at 03:37 PM.
No I was referring to my wowmapper project, which started on linux (ubuntu).
Yes, size_t is nothing linux related, I probably just overlooked it since it's only present in the mver chunk struct and I didn't noticed it myself because I've been writing it on 32bit windows/linux. I changed it to uint32_t in the trunk now. Thanks for the hint.
No problem, in fact there may be another issue around. With this fix I see no more parsing errors, but .obj files look quite corrupted (viewed from mm3d which is the tool I used for my own MPQ parsing code). This made me stop looking at Detour/Recast for now. I am installing a windows compiler in order to compare extracts from windows side, but I suspect there may be another 32 vs 64 bits issue in the code, or something similar. I can help to debug it if this issue is confirmed (I have MPQ/ADT/WMO knowledge).
Thanks,
A side note:
Rival's cell size is inappropriate for mcnk sized chunks: 1600/3 is not a multiple of 0.35, therefore you get empty spaces between some tiles:
broken mesh
You should use generation data similar to namreeb's suggestion.
That is, let cs depend on your voxels per tile (cs = 533.3333... wu / 1800 voxels), not the other way round or choose a "common" value like 1/3.
The actual value of cs isn't important, as long as it properly aligns with 1600 / 3.
Last edited by Bananenbrot; 02-09-2011 at 12:24 PM.
Hello, while i was waiting for developer of bot im using to implement some functions to continue my work
i discovered Recast+Detour and started to do resreach , downloaded countless versions of WoWMapper none of them worked
if I downloaded source it got compile errors if I downloaded Compiled one it just open and closes , i've entered values correctly but still or it crashed.
I'm asking you to upload compiled functional Wowmapper to extract maps to .obj
(sorry for writing with zero posts, im longtime reader of this forum and community )
Countless Thanks for possible help
Maybe i am to stupid but what code do you exatly use to save and load more than one tile. I'am going crazy on this shit o.O
dtCreateNavMeshData builds a tile, and dtLoadTile or some such thing loads it. Is that what you're wondering?
Is there another tool besides wowmapper which dumps all maps to navmesh which works with recast&detour?
The only navmesh file I got fully worked was delivered in this tutorial.
Is someone still able to compile WoWMapper lol? I'm getting errors which are not understandable :S
Wowmapper Compiles fine! You need to inluce the missing files! But wow mapper needs an update becouse its broken.