OgreCrowd: a crowd component for Ogre using Recast/Detour

[Herb]

I have to echo Blender+C++....I'm having the same issue on Linux. I have a seg fault everytime I call

Code: Select all

new InputGeom(terrainGroup)

I traced it to line 391 of RecastInputGeom.cpp

Code: Select all

verts = new float[nverts*3];// *3 as verts holds x,y,&z for each verts in the array

It's strange as nverts in my particular case is around 16K. That should not be an issue with memory on my system.... The actual error message is the following:

Code: Select all

malloc.c:2451: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Just trying to find the best way to load my Ogre terrain into recast, and this was how the sample program did it... Anybody have any ideas? duststorm, do you?

** EDIT - it's looking like somewhere in the constructor for the input geometry class memory is getting stomped on, and allocating a large chunk with the new float call hits an earlier issue. If I comment out that line and the rest of the constructor, it still seg faults....

[Blender+C++]

Hi Herb,
yeah it is a memory issue, as a temporary solution i just set to ignore plants,farns and only rebuild on trees,rocks,houses and big objects, thats what i did in order to move on, but if there is a way to free the intermediate cache data then it will probably work and it wont break it anymore...
anyways i hope you get this solved
Kind regards,
Romulo Romero

[Herb]

Just as a quick update, I did find the memory issue in the code... In RecastInputGeom.cpp, for the constructor

Code: Select all

InputGeom::InputGeom(Ogre::TerrainGroup *terrainGroup, std::vector<Ogre::Entity*> srcMeshes)

In this section of code within the constructor:

Code: Select all

         size_t size = ((MapSize*MapSize)-(MapSize*2)) * 6;
         meshIndices[trnCount] = new Ogre::ulong[size];
         // i will point to the 'indices' index to insert at, x points to the vertex # to use
         i = 0;
         for(int x = 0;;++x)
         {
             // skip rightmost vertices
             if((x+1)%MapSize == 0)
             {
                 ++x;
             }
             
             // make a square of 2 triangles
             meshIndices[trnCount][i] = x;
             meshIndices[trnCount][i+1] = x + 1;
             meshIndices[trnCount][i+2] = x + MapSize;

             meshIndices[trnCount][i+3] = x + 1;
             meshIndices[trnCount][i+4] = x + 1 + MapSize;
             meshIndices[trnCount][i+5] = x + MapSize;

             // if we just did the final square, we're done
             if(x+1+MapSize == (MapSize*MapSize)-1)
                 break;

             i += 6;
         }

The indexing into meshIndices can go OVER the size allocated so I had to put

Code: Select all

             if (i+5 >= size)
                 break;

in the for loop and things seem to be working fine now. At the moment, I'm just calling this constructor and passing in terrain data. Hopefully this is useful to someone.

[duststorm]

Is there any way to add new input geometry to the already generated mesh? The reason I'm asking is because I got a paged terrain and I'd like the navmesh to be rebuilt for each page individually.

Sure, have a look at the cube or pallet placement in the demo. Add your new object to the inputGeom, get a tile-aligned bounding box from the bounding box of that object and recalculate the navmesh for the affected tiles.

[duststorm]

if i set the terrain world size to 5000.0f the navmesh wont cover all the terrain areas and will look a little buggy like in the Picture

Try experimenting with the cellsize and tilesize parameters that you can set in the RecastCfg object passed to the OgreRecast constructor. Recast can handle any size of terrain, as long as the voxel resolution is adapted to it so it all fits in memory.

Lately I have been working on other projects, leaving little time to work much on OgreCrowd. But I will try to expand this component and incorporate the proposed fixes in the future.

[Blender+C++]

Hi DustStorm,
i tried to play with the celsize and increased its value and also with the tile size but it didnt work out, as Mikko told me , we have to find a way to free the intermediate cache data ...he also mentioned that ogre uses a kind of profiler which limits but as im not sure what profiler is then i cant tell where expand it ..but to me the better way is to free the int cache data..anyways thanks for coming by DustStorm i was getting worried already hehehe..it s been a while since we dont see you here
Thanks again and i hope we can get this issue fixed whenever you get the time to try it out!
Thanks again and kind regards,
Romulo Romero

[van4dium]

great,great,GREAT work!!!!!

[nevarim]

really great!!

[TheSHEEEP]

Time for some thread ressurection

I am also using OgreCrowd at the moment and it works fine to generate the NavMesh (also tiled) from whatever I throw at it!

However, I just cannot get CylinderObstacles to work.
If I create a ConvexShapeObstacle from an arbitrary mesh (I changed it so I could pass any Entity to it) it works well.
But if I create CylinderObstacles from the exact same Entity (using its bounding radius and height as an approximation), nothing happens at all.
Of course, I do call update() on the tile cache, and only after that I call drawNavMesh().

The navmesh is there and the cylinders are drawn (so they are indeed added), but there are no holes in the navmesh. I tried playing around with positions, radii and heights, but to no avail. Even though the internal recast & detour functions are called, the navmesh just wont have any holes.

Now, I could of course just use ConvexShapeObstacle, but I have hundreds of obstacles to add per navmesh and each ConvexShapeObstacle always causes a complete rebuild of the tile when added, so the performance is pretty bad.

[cbibejs]

Time for some thread ressurection

I am also using OgreCrowd at the moment and it works fine to generate the NavMesh (also tiled) from whatever I throw at it!

However, I just cannot get CylinderObstacles to work.
If I create a ConvexShapeObstacle from an arbitrary mesh (I changed it so I could pass any Entity to it) it works well.
But if I create CylinderObstacles from the exact same Entity (using its bounding radius and height as an approximation), nothing happens at all.
Of course, I do call update() on the tile cache, and only after that I call drawNavMesh().

The navmesh is there and the cylinders are drawn (so they are indeed added), but there are no holes in the navmesh. I tried playing around with positions, radii and heights, but to no avail. Even though the internal recast & detour functions are called, the navmesh just wont have any holes.

Now, I could of course just use ConvexShapeObstacle, but I have hundreds of obstacles to add per navmesh and each ConvexShapeObstacle always causes a complete rebuild of the tile when added, so the performance is pretty bad.

You can try to position obstacles in negative y until they inside of navmesh.Like this:

Code: Select all

mDetourTileCache->addTempObstacle(Ogre::Vector3(mPosition.x,mPosition.y-3,mPosition.z));

[TheSHEEEP]

I did that.
The debug representation clearly is inside of the navmesh.

But the navmesh just won't get any holes.

[cbibejs]

I did that.
The debug representation clearly is inside of the navmesh.

But the navmesh just won't get any holes.

Than you can tweak cfg values maybe.

Code: Select all

  m_cellSize = 1.0 
   m_cellHeight = 0.5
   m_agentMaxSlope = 50.0
   m_agentHeight = 2.0
   m_agentMaxClimb = 3.0 
   m_agentRadius =  2.0
   m_edgeMaxLen = 12.0
   m_edgeMaxError = 1.3
   m_regionMinSize = 8.0
   m_regionMergeSize = 20.0
   m_vertsPerPoly = 6.0
   m_detailSampleDist = 6.0
   m_detailSampleMaxError = 1.0

This are my values.They working fine with Cylinder Obstacles.

[TheSHEEEP]

Hmm, nope, that still doesn't work.
I am seriously thinking I hit a bug in Detour itself and asked on the official repo. It just doesn't make sense that no hole would be displayed.

But hey, using your values made my generation about 1/3 faster, so thanks for that!

[cbibejs]

Hmm, nope, that still doesn't work.
I am seriously thinking I hit a bug in Detour itself and asked on the official repo. It just doesn't make sense that no hole would be displayed.

But hey, using your values made my generation about 1/3 faster, so thanks for that!

I'm glad i help.i read your post at your link and noticed something your code seems like working but draw debug code not take account temp obstacles.Can you test some path finding so maybe everythings works but you just can't see holes because maybe just something wrong with debug code or maybe a bug like you said anyway if your code works you can atleast use it without seeing temp holes.

[TheSHEEEP]

Well, I use OgreCrowd for the debug drawing, so if a temp obstacle does not create holes there, it is rather a bug in OgreCrowd.
In the original recast & detour demos, temp obstacles definitely do create holes in the navmesh.
But I will try this out next, anyway.

[TheSHEEEP]

Oh, wow. Seems like you are right.
Here is two times the same path request, one time with an obstacle.





It is pretty clear it navigates around the obstacle.
So I wasted a day or two on a non-error
But thanks for the hint. I probably would have wasted some more days on this otherwise.

The obstacle representation seems a bit off, though, it looks smaller than it actually is, but that may be a problem of the used mesh.
And I still don't understand why no modification to the navmesh is shown, as the debug drawing code seems to be the same as it is in the recast demos.
But the most important thing is that it works.

[duststorm]

Hmm, it seems I'm a bit late to join in the discussion again
But indeed, temp obstacles are "hidden", they don't actually modify the navmesh, rather they are taken into account only by the detour navigation tool.
You can see this in my demo: temp obstacles are visualized using red cylinders. The crates and vases in the original demo are not temp obstacles, they are added to the input geometry and the navmesh for the affected tiles is re-generated. This results in the navmesh actually being changed.

So if you want to debug/visualize your temp obstacles, just draw some cylinders in your scene like I did in my demo.

Short summary of pros and cons of both:
temp obstacles
+ faster
- only cylinder shaped
- only obstacle, cannot introduce new walkable parts

obstacle by regenerating tile (tilecache only)
- slower (but doable if number of tiles to modify is low, eg only 1)
+ obstacle can be any shape
+ actually modifies the navmesh, can also introduce new walkable areas (eg the wooden pallets in the demo)
(+ updates navmesh visualization, only useful for debug really, and for visualizing temp obstacles you could as well draw a cylinder mesh)

Temp obstacles are really really fast, you can for example use them to make the other agents avoid the player (used in the demo: "control obstacle"), meaning that it is possible to add and remove temp obstacles in new locations every frame.
If the obstacle shape does not match a cylinder, you can try using multiple obstacle cylinders of different sizes.

[Naglareph]

Hello,

I started using OgreCrowd in my project, but I have a bit of a problem with it.

I currently have three instances of Ogre::Terrain* contained in one Ogre::TerrainGroup.
When the three terrain were next to each other, the navmesh and pathfinding worked just fine.
But for gameplay reasons and such, I stacked my terrains one above the other.

Ogre::Terrain One = 4000, 2000, 4000
Ogre::Terrain Two = 4000, 1000, 4000
Ogre::Terrain Three = 4000, 0, 4000

But the NavMesh just stays on the lowest terrain (terrain three) with all the geometry of the others stacked on itself.


(It gives quite the headache)

I believe the answer to my questions could be in RecastInputGeom.cpp but the code is quite complex and I don't know where to put my head first.
I did try modifying y vertixes as they were put into recast, but it doesn't change anything.

Any kind souls know where/how to solve this problem ?

Many thanks,

PS : Sorry for my English, it isn't perfect.

[cloud]

I've been playing around with this a bit and I happened to notice with OgreRecast::getFilter and a test with two different area types one water one ground and found that setting the filter, i.e. mRecast->getFilter().setExcludeFlags(SAMPLE_POLYFLAGS_SWIM) didn't work as intended, went straight htrough the water, but if you change the function to return the pointer instead all is well.

[cloud]

Not sure if anyone wants this but I managed to get off mesh connections to work, was simple in the end, uncomment the code that says they arn't working and to

Code: Select all

bool OgreDetourTileCache::buildTile(const int tx, const int ty, InputGeom *inputGeom)

add the line

Code: Select all

m_tmproc->init(inputGeom);

somewhere near the top,this is because it was using the geom in the OgreDetourTileCache in the callback rather than the one passed in.
Then you can do something like

Code: Select all

geom->addOffMeshConnection(start.ptr(), end.ptr(), recast->getAgentRadius(), 1, area, flags);
geom->addOffMeshConnection(end.ptr(), start.ptr(), recast->getAgentRadius(), 1, area, flags);

[nevarim]

hi
i'm trying to compile and i have this error

1>------ Build started: Project: OgreRecast, Configuration: Debug Win32 ------
1> BaseApplication.cpp
1>f:\ogrecrowd-master\samples\src\baseapplication.cpp(141): error C2664: 'OgreBites::SdkTrayManager::SdkTrayManager(const Ogre::String &,Ogre::RenderWindow *,OgreBites::InputContext,OgreBites::SdkTrayListener *)' : cannot convert parameter 3 from 'OIS::Mouse *' to 'OgreBites::InputContext'
1> No constructor could take the source type, or constructor overload resolution was ambiguous
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


on this line
mTrayMgr = new OgreBites::SdkTrayManager("InterfaceName", mWindow, mMouse, this);

compiling with vs2012

anyone solved this problem?

thanks
Nevarim

[duststorm]

I think this is because in newer versions of OIS the API changed a bit.

[Lax]

Hello Folks,

is it somehow possible to create a navigation mesh that does operate on x, y base?

Like:

JumpRunPath.png

I tried already a lot of OgreRecastConfigParams configuration params. But I'm not able to get a path around those obstacles.

Regards
Lax

[Treon]

Hey,

I have a question about recast, it is possible to generate a 2D texture out of the generated mesh? could be used for a "minimap" preview. Maybe it's a bad idea? thinking that perhaps it will be lot of holes everywhere, but perhaps adding some "smooth factor" to just take the surface without connections when generate the 2d texture. If someone has a good idea of how this can be done, feel free to comment. I bet more people want to do the same for different usage.

[Lax]

Hi,

has somebody success using new Ogre::Terra system with terra, especially the RecastInputGeom?

Instead of using:

Code: Select all

InputGeom::InputGeom(Ogre::TerrainGroup *terrainGroup, std::vector<Ogre::Entity*> srcMeshes)

The function should be like this:

Code: Select all

InputGeom::InputGeom(Ogre::Terra* terra, std::vector<Ogre::Entity*> srcMeshes)

Terra works a bit different of Ogre::TerrainGroup, so I'm stuck, building the mesh for recast out of it.

I hope somebody has already adpated Ogre::Recast for Ogre 2.2 Terra...

Best Regards
Lax