Walkabout Navigation Toolkit help thread

#101 Mm, so the basic idea would be to use the update script methods to rebuild parts of the navmesh on the fly, at two points: when the object first starts moving (and therefore isn't on the navmesh any more), and when it stops moving (and should be again considered an obstacle). Those calls look like:

WalkaboutUpdateAll(%movingObj, true);
WalkaboutUpdateAll(%stillObject);

The trick will be calling those at the right time. I haven't used PhysX objects before; if they have a 'rest' state like I think T3D's builtin physics does, you might want to try to hook into that. Or, you could call the first function at the point where you apply the impulse to the crate (and add a flag to the object to make sure you don't rebuild the mesh twice if two explosions happen close together). And if worst comes to worst you could schedule an update function that checks the crates' velocities and updates the navmesh as necessary.

#102 Daniel: Thanks for that. I was on the right track. Let me give that a try and I'll report back my progress.

I was using Bullet initially ... but had an issue with the Bullet objects and their collision meshes. Updated to PhysX and the problem went away.

I must admit, the UAISK and Walkabout integration does quite a good job of getting around the obstacles, but when the crates clump in an area than they tend to get a little stuck. 8-}

#103 Before moving the crates? Is the navmesh not taking the crates' size into account?

Also, do you mean the Bullet shapes weren't being turned into a navmesh properly? I should probably have a look at that - I've never bothered with T3D's physics library implementations myself.

#104 @Daniel: Yeah, I add the Crates in to the map ... build the NavMesh and the NavMesh actually appears below the Crates and not around them. This is happening in both Bullet and PhysX ... not sure where the problem could be.

I'll take a screen shot and show you what I mean.
Screenshot

The white crate is a static shape, the red crates are PhysX Crates. I thought it might have something to do with this code (navMesh.cpp):

mTypeMask |= StaticShapeObjectType | MarkerObjectType;

I can confirm that the PhysX side is working 100% correctly ... I added PhysX Objects from the Pacific Demo, one of the packs from a 3D Site, and the Office Furniture Pack from Winterleaf ... so I know it isn't the PhysX side of things.

The collision thing was only for Bullet and had nothing to do with Walkabout ... I added the crates and regardless of the model setup ... as soon as they were added I could walk right through them although they responded to impulse effects ... and sometimes they fell through the ground plane. I gave up eventually and switched over to PhysX ... much happier now.

Edit: Added screenshot to show you what I mean.

#105 Sorry, I just realised that it should have been pretty obvious to me. In navMesh.cpp, line 814:

getContainer()->findObjects(box, StaticObjectType, buildCallback, &info);

You'll need to include more typemasks if you want non-static objects to be included in the build. I'm not sure what typemask would be most suitable. The physics shape classes must all use DynamicShapeObjectType, but that includes Items, Vehicles and Turrets as well, so you may have to take care when building your meshes.

#106 ended up using

getContainer()->findObjects(box, StaticObjectType | VehicleBlockerObjectType, buildCallback, &info);

And tacking on VehicleBlockerObjectType to rigidshapes this end for that, like so:

RigidShape::RigidShape()
{...
mTypeMask |= VehicleObjectType | DynamicShapeObjectType | VehicleBlockerObjectType;
...}

Since, to quote the code it'sself:

ConsoleDocClass( VehicleBlocker,
   "@brief Legacy class from Tribes, originally used for blocking Vehicle objects.\n\n"

   "@note This is no longer useful and should be deprecated soon.\n\n"

   "@internal\n"
);

It exists to be checked against in the various sCollisionMoveMask entries for vehicle derivations, but without an actual object assigned a typemask, it's pretty much entirely vestigial.

#107 Good idea! I would definitely look at making Vehicles part of the navmesh at some point too (especially slow-moving ones), but that's a pretty game-specific need.

#108 Daniel, are you going to update walkabout for 3.5 as well?

#109 FYI, I have just integrated Walkabout into 3.5 using winmerge, and it works very well. Actually no need for a new release.

#110 Sorry I didn't get back to you - great to hear it's working with 3.5. The one tricky part may have been the navigation code I added to 3.5, but if you only enable one module at a time you should be right.

#111 hey there, great work with walkabout

are there any update plans,
something to extend walkabout for water planes and water in general?

#112 Yes, I'm just very slow about it! Once I've finished my tutorial on using the navigation code I submitted to T3D 3.5, I'll resume some Walkabout updates.

#113 hehe, i was just asking out of curiosity and its never bad to give a coder some slap on the neck
just to remember him^^

anyways i find it great that you are not simply abandoning your contribution to teh T3D MIT Version.
Creating a How to Manual is a great way to introduce ppl to walkabout!

#114 Daniel, I plan to purchase on feb 3rd, I already know its a great pack, just got a quick question.... I know this provides pathfinding, with UAISK will my enemy also crouch and seek cover when shot or takes damage?? Sorry if this is the wrong place to ask....

#115 Hey Donnie - the integration with UAISK is pretty basic, but it's easy to do. Your characters will run for cover when damaged, and use pathfinding for their normal movement. I don't have any sort of crouching implemented, unless the UAISK does that itself. Hope that answers your questions!

#116 I highly recommend adding Steve's pose fix until the Committee comes back online if you're interested in AI crouching.

#117 Great thank you Dan and Richard...

#118 Has anyone gotten this working with a 3.5 build of Torque 3D MIT? Previous posters mention no changes, but I encountered this issue with the easy install method and not the WinMerge one.

17>..........EnginesourceT3DgroundPlane.cpp(361): error C2039: 'getFrustum' : is not a member of 'SceneRenderState'
17>          ../../../../../Engine/source/scene/sceneRenderState.h(57) : see declaration of 'SceneRenderState'

I have narrowed is down to this code.

// Update the geometry.
   createGeometry( state->getFrustum() );

I still need to verify, but I am going to assume that getFrustum was replaced with getCullingFrustum.

createGeometry( state->getCullingFrustum() );

I looked at the history of the file on the GIT repository (github.com/GarageGames/Torque3D/blob/b32e7688c2a2a8af3831fdf01719fbebe387e59d/En...) and so I think I am on the right track.


History file:

/// Returns the minimum distance something must be from the camera to not be culled.
      F32 getNearPlane() const { return getFrustum().getNearDist();   }

      /// Returns the maximum distance something can be from the camera to not be culled.
      F32 getFarPlane() const { return getFrustum().getFarDist();    }

Latest file:

/// Returns the minimum distance something must be from the camera to not be culled.
      F32 getNearPlane() const { return getCullingFrustum().getNearDist();   }

      /// Returns the maximum distance something can be from the camera to not be culled.
      F32 getFarPlane() const { return getCullingFrustum().getFarDist();    }

Seems to compile and work, not really in a position to test right now, but hopefully it will work.

#119 Hey Dan, nice pack and thank you for your hard work!! One question, after install, my shape editor is no longer on the pallete, i have to go to the editors drop down list to run it??

#120 Hey Quinton, sorry I didn't get back to you - I haven't encountered that issue. I've just started a fresh merge of 3.5 into Walkabout so I'll get back to you sometime this weekend.

Hey Donnie - yes, unfortunately the default editor palette has only a fixed size, and I think the order is determined by some sort of sort - so the shape editor ends up getting bumped off the end. I haven't looked into it, but you might need to modify the GUI file that defines the editor palette.