OgreCrowd: a crowd component for Ogre using Recast/Detour

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
Herb
Orc
Posts: 412
Joined: Thu Jun 04, 2009 3:21 am
Location: Kalamazoo,MI
x 38

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by Herb »

I have to echo Blender+C++....I'm having the same issue on Linux. :cry: 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++
Gremlin
Posts: 171
Joined: Tue Jan 03, 2012 1:38 am
Location: Brazil
x 3

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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 :D
Kind regards,
Romulo Romero

User avatar
Herb
Orc
Posts: 412
Joined: Thu Jun 04, 2009 3:21 am
Location: Kalamazoo,MI
x 38

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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. :)

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by duststorm »

ShortBus wrote: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.
Developer @ MakeHuman.org

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by duststorm »

Blender+C++ wrote: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.
Developer @ MakeHuman.org

Blender+C++
Gremlin
Posts: 171
Joined: Tue Jan 03, 2012 1:38 am
Location: Brazil
x 3

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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 :D
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
Halfling
Posts: 40
Joined: Fri Jul 30, 2010 2:40 am
x 1

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by van4dium »

great,great,GREAT work!!!!!

User avatar
nevarim
Gnoll
Posts: 675
Joined: Mon Jul 05, 2010 6:16 pm
Location: Pavia Italy
x 4
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by nevarim »

really great!!
i'm a noob until proven otherwise :D
used in my project ;) and thanks to everyone :D
Ogre 3d
Mygui
Skyx
Hydrax
MOC
CCS

TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 63

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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.
My site! - Have a look :)
Also on Twitter - extra fluffy

User avatar
cbibejs
Kobold
Posts: 31
Joined: Wed Feb 08, 2012 1:00 pm
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by cbibejs »

TheSHEEEP wrote: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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 63

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by TheSHEEEP »

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

But the navmesh just won't get any holes.
My site! - Have a look :)
Also on Twitter - extra fluffy

User avatar
cbibejs
Kobold
Posts: 31
Joined: Wed Feb 08, 2012 1:00 pm
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by cbibejs »

TheSHEEEP wrote: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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 63

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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! ;)
My site! - Have a look :)
Also on Twitter - extra fluffy

User avatar
cbibejs
Kobold
Posts: 31
Joined: Wed Feb 08, 2012 1:00 pm
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by cbibejs »

TheSHEEEP wrote: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
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 63

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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.
My site! - Have a look :)
Also on Twitter - extra fluffy

TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 63

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by TheSHEEEP »

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

Image

Image

It is pretty clear it navigates around the obstacle.
So I wasted a day or two on a non-error :D
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.
My site! - Have a look :)
Also on Twitter - extra fluffy

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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.
Developer @ MakeHuman.org

Naglareph
Gnoblar
Posts: 10
Joined: Fri Jul 18, 2014 9:18 pm
Location: Paris, France

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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.

Image
(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
Gremlin
Posts: 196
Joined: Tue Aug 08, 2006 6:45 pm
x 14

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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
Gremlin
Posts: 196
Joined: Tue Aug 08, 2006 6:45 pm
x 14

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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);

User avatar
nevarim
Gnoll
Posts: 675
Joined: Mon Jul 05, 2010 6:16 pm
Location: Pavia Italy
x 4
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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
i'm a noob until proven otherwise :D
used in my project ;) and thanks to everyone :D
Ogre 3d
Mygui
Skyx
Hydrax
MOC
CCS

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by duststorm »

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

Lax
Orc
Posts: 421
Joined: Mon Aug 06, 2007 12:53 pm
Location: Saarland, Germany
x 19

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by Lax »

Hello Folks,

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

Like:
JumpRunPath.png
JumpRunPath.png (113.48 KiB) Viewed 7028 times
I tried already a lot of OgreRecastConfigParams configuration params. But I'm not able to get a path around those obstacles.

Regards
Lax

Treon
Kobold
Posts: 37
Joined: Mon Mar 07, 2011 2:30 pm

Re: OgreCrowd: a crowd component for Ogre using Recast/Detou

Post by 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
Orc
Posts: 421
Joined: Mon Aug 06, 2007 12:53 pm
Location: Saarland, Germany
x 19

Re: OgreCrowd: a crowd component for Ogre using Recast/Detour

Post by 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

Post Reply