What is TileMesh and how it difference to SoloMesh

[nguyễn hữu]

Hi, i'm new to recastnavigation. I just discovered it 2 days ago. I'm interested and want to use it in my project. I just too stupid and lazy then i decide to ask you guys instead of reading code. Excuse me :D
1. What is TileMesh and how it difference to SoloMesh? Which one faster on query?
2. I watch the slide http://digestingduck.blogspot.fi/2010/02/slides-from-past.html, and understand how the SoloMesh constructed, then how about TileMesh
3. How to add temporaty obstacle to SoloMesh?

[Jimmy James]

Solo mesh builds one big mesh. Tile mesh builds it up out of lots of little tiles. Good if you want to build your world dynamically. Don't know which is faster on query.
If you want temp obstacles look at the temp obstacles example. I'm pretty sure Mikko said he wanted to remove solo mesh from the demo at one point, so I wouldn't bother with it.

[nguyễn hữu]

Yes, thank you. I found the demo has alot of code. It's confusing me. Also the core API are bright and clear, but all the 'handle', render, some helper function, all in same place, so hard to read. As the code raise, i think memononen should organize it. I think sometime readable are important than optimize.

Vào 14:34:22 UTC+7 Thứ hai, ngày 10 tháng ba năm 2014, Jimmy James đã viết:

[Jimmy James]

It was very difficult for me at first, but I understand it better and better the more I use it.

[Mikko Mononen]

Good points. The demo project has grown out as more features has been implemented. How would you organise the demo project? What kind of questions you have had as you started learning Recast?

--mikko

--

---
You received this message because you are subscribed to the Google Groups "recastnavigation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to recastnavigati...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jimmy James]

What I would do at every point where you're building the mesh, place a link to your blog explaining what that part does visually. I found a webpage that did just that for recast a few weeks ago, but I can't remember where it is right now. It had images for every step of the build process. It was very well done.

Another thing, parts of the tools code is in massive blocks. You want to break those out into bite sized functions. One for each tool mode.


    enum ToolMode
    {
        TOOLMODE_PATHFIND_FOLLOW,
        TOOLMODE_PATHFIND_STRAIGHT,
        TOOLMODE_PATHFIND_SLICED,
        TOOLMODE_RAYCAST,
        TOOLMODE_DISTANCE_TO_WALL,
        TOOLMODE_FIND_POLYS_IN_CIRCLE,
        TOOLMODE_FIND_POLYS_IN_SHAPE,
        TOOLMODE_FIND_LOCAL_NEIGHBOURHOOD,
    };

[Jimmy James]

There is a really nice Recast documentation project underway. I would make sure people can find that.

http://www.stevefsp.org/projects/rcndoc/prod/

On Tuesday, March 11, 2014 5:21:26 PM UTC+11, Mikko Mononen wrote:

[nguyễn hữu]

Actually people can build document by themself, because you included the doxygen project.
Here are my noob oppinion about demo organization.
- Every function that does not belong to any class, static void, static bool, static bla bla bla, better group in a class named RecastHelper, or Utilities, or Geometry, ....
- As render are depend on engine, i hope render section will seperate to logic section. Like this,
class Sample_TempObstacles, class Sample_TempObstacles_Render, class render which need an instance of Sample_TempObstacles as an init param.
- Loging info i think would be seperate too, struct Sample_XXX_LogInfo, which hold log infomation, logic class build them, render class access them to bring it into screen.
- I don't have much experience on algorithm. I hope there will have name of the classic algorithm before the implementation, so i can search for them :D Yeah, classic algorithm only, i mean the famous algorithm like dijkstra, prim, kmp, levenstein edit distance.... sorry for my poor english.

Vào 17:01:44 UTC+7 Thứ ba, ngày 11 tháng ba năm 2014, Jimmy James đã viết:

[Jimmy James]

Agree with these suggestions 100%. I have seen people complain of the rendering code not being separate before.


Also Mikko, with the samples... IMO you should assume people are going to use your samples as is and try to override them.

Its much easier to learn a lib, when you can get something/anything working in a short amount of time. In some of the samples, you have structures and functions hidden in the .cpp files. These need to be accessible from the headers, if you want to override the samples.

[Ben Hymers]

This article is super-useful for understanding Recast. It's documenting a port of Recast so it's not completely accurate but provides a rough overview with diagrams:

http://critterai.org/projects/nmgen_study/

[Ben Hymers]

I agree that rendering, logging etc. should be abstracted out of the samples. I also agree that although the samples aren't intended to be used directly, people will either use them or copy/paste code from them, so they should be structured more like real-world applications.

I don't agree that free functions should be moved into a class though - in fact I would go the other way and move many of the functions currently contained in dtNavMesh and dtNavMeshQuery out of the classes where they don't need access to any private methods or fields. They should definitely be namespaced though.

[Jimmy James]

Yes, its excellent. That's the website I mentioned above.