University of Southern CaliforniaUSC
USC ICT TwitterUSC ICT FacebookUSC ICT YouTube

Steering around pawns and navigation mesh | General SmartBody Discussion | Forum

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Steering around pawns and navigation mesh
January 12, 2014
3:37 pm
Avatar
Member
Members
Forum Posts: 10
Member Since:
January 12, 2014
sp_UserOfflineSmall Offline

Hi! I'm using smartbody and ogre in a game engine that's scriptable by python. I'm trying to get steering to work, either around pawns or using a navigation mesh, and I have some questions on the matter.

 

Please note I'm using my own python wrappers in the code below, but they closely follow the c++ code.

 

1) Regarding steering around pawns

Steering around characters simply works. To steer my characters around a pawn however, I'm assuming I need to call:

pawn.setStringAttribute('collisionShape', 'box')  # I've also tried other shapes

 

The character then steers around a box that is actually much larger than the mesh I'm attaching to the pawn. Setting the collision shape size through

pawn.setVec3Attribute('collisionShapeScale', x, y, z)

has no apparent effect, though pawn.getVec3Attribute('collisionShapeScale') returns the correct values.

 

Furthermore, due to the way certain meshes are modeled, in ogre they actually appear farther than their x,y,z position. This means that SB places the bounding box farther from where the mesh appears.

 

Both the above problems would be solved if one was able to manually set the position of the edges of the collision bounding box.

 

Also, am I right to assume specifying the mesh I'm using has no effect on steering?

 

2) Regarding steering by means of a navigation mesh

 

I believe the docs on the subject are outdated. Is the following the current right way to set up a navigation mesh?

navigation_mesh_name = 'living_room_floor.obj'
navigation_mesh = scene.getNavigationMeshManager().createNavigationMesh(navigation_mesh_name)
navigation_mesh.buildNavigationMesh(navigation_mesh_name)
scene.setNavigationMesh(navigation_mesh_name)

 

Moreover, assuming the navigation mesh is properly set up, would telling a character to move outside its bounds really do nothing?

January 14, 2014
1:35 am
Avatar
Admin
Forum Posts: 983
Member Since:
December 1, 2011
sp_UserOfflineSmall Offline

1) I think there is a scaling problem related to steering with the pawn bounding box - I'll need to fix that. Right now, the steering can only handle rectangular objects, not circular or arbitrary triangles. The latest version of SteerSuite handles more types of collision obstacles - I'll have to talk to the authors to incorporate that.

 

2) I'll have Andrew Feng who worked on the navigation mesh code answer that question.

 

Ari

 

January 14, 2014
1:57 am
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Regarding 2), you are right that the doc needs to be updated and the way you describe is correct to setup the navigation mesh given that 'living_room_floor.obj' is already loaded as a resource in SmartBody.

 

As for telling character to move outside of the navigation mesh bound, the navigation mesh will find a path from start position to target position of the character. If either of these positions are far outside the bound of navigation mesh, the "SBNavigationMesh.findPath" API function will not return a path. As a result, the character would not move. 

 

Andrew

January 14, 2014
10:47 am
Avatar
Member
Members
Forum Posts: 10
Member Since:
January 12, 2014
sp_UserOfflineSmall Offline

Thanks very much for the replies, guys!

"I think there is a scaling problem related to steering with the pawn bounding box – I'll need to fix that. Right now, the steering can only handle rectangular objects, not circular or arbitrary triangles. The latest version of SteerSuite handles more types of collision obstacles – I'll have to talk to the authors to incorporate that."

I'm especially looking forward to the solution to the scaling issue!

"the way you describe is correct to setup the navigation mesh given that 'living_room_floor.obj' is already loaded as a resource in SmartBody."

SBNavigationMesh::buildNavigationMesh returns true, so I'm (hopefully correctly) assuming it's being properly loaded.

"As for telling character to move outside of the navigation mesh bound, the navigation mesh will find a path from start position to target position of the character. If either of these positions are far outside the bound of navigation mesh, the "SBNavigationMesh.findPath" API function will not return a path. As a result, the character would not move."

The .obj I've tried to use is a simple plane. I've been testing it only by telling the character to move outside the bounds, though that didn't work. Maybe I'm facing a modeling/scaling/orientation issue?

Now that I know I've set up the navmesh correctly, I'll investigate further. I'll let you know how it works out!

January 14, 2014
8:03 pm
Avatar
Member
Members
Forum Posts: 10
Member Since:
January 12, 2014
sp_UserOfflineSmall Offline

OK, SBNavigationMesh::findPath works perfectly, but only when I manually tell the character to go to the points findPath returns. Steering w/ navmesh does not seem to automatically trigger when I send the character to a single point.
Am I forgetting to activate it somewhere? The only relevant property I'm setting is this one:

steer_manager.setEnable(False)
character.setBoolAttribute('steering.pathFollowingMode', False)
steer_manager.setEnable(True)

January 15, 2014
8:44 pm
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Yes, the system didn't use the navimesh automatically when processing a locomotion command ( so it doesn't query the navimesh to find a path ). Since the steering engine (SteerSuite) has its own A* path finding and other heuristic rules to avoid obstacles, I don't want to mix it too much with navimesh at least for now. So right now navimesh is only used as a structure for querying a collision free path to feed into locomotion command.

 

"steering.pathFollowingMode" is to enable a simplified steering method we implemented. It basically just try to force the character to stay on the course of a given path without considering the obstacles. It doesn't resolve any dynamic obstacles, but sometimes it is more stable than steersuite when the environment doesn't have other moving obstacles.

 

Andrew

January 16, 2014
8:32 am
Avatar
Member
Members
Forum Posts: 10
Member Since:
January 12, 2014
sp_UserOfflineSmall Offline

Alright, thanks for the clarification!

August 5, 2015
2:50 pm
Avatar
Member
Members
Forum Posts: 11
Member Since:
July 29, 2015
sp_UserOfflineSmall Offline

Hey!

 

I'm using Irllicht as a graphics engine and the irrlichtsmartbody.py as a reference.

I changed the scene scale to 1.0 (and removed the *10 upscaling), generated a navigation mesh, now every time I call navigation_mesh.findPath it returns a big amount of data. When I feed this data to the locomotion bml execution the character starts spinning around at some point on the path. I think it's because he cannot hit the exact position sent to the locomotion command from the find path array. The locomotion works fine if i set the scene scale back to 0.1 but the animations are all wrong (the character takes a step then takes the Vitruvian man position then takes another step with the same foot etc.). I have also tried trucating all of the floating point data:

    vec_x: -10.000000 vec_y: 0.100000 vec_z: -10.000000
    vec_x: -12.309334 vec_y: 0.130000 vec_z: -8.393520
    vec_x: -13.156239 vec_y: 0.130000 vec_z: -7.804373
    vec_x: -14.593750 vec_y: 0.130000 vec_z: -6.804373
    vec_x: -14.993750 vec_y: 0.130000 vec_z: -6.404373
    vec_x: -15.593750 vec_y: 0.130000 vec_z: -5.804373
    vec_x: -15.993750 vec_y: 0.130000 vec_z: -5.404373
    vec_x: -16.993749 vec_y: 0.130000 vec_z: -3.404373
    vec_x: -16.993749 vec_y: 0.130000 vec_z: -2.704372
    vec_x: -16.993749 vec_y: 0.130000 vec_z: 0.995628
    vec_x: -16.993749 vec_y: 0.130000 vec_z: 1.695629
    vec_x: -15.993750 vec_y: 0.130000 vec_z: 3.695629
    vec_x: -15.593752 vec_y: 0.130000 vec_z: 4.095627
    vec_x: -14.993750 vec_y: 0.130000 vec_z: 4.695629
    vec_x: -14.593750 vec_y: 0.130000 vec_z: 5.095627
    vec_x: -12.593750 vec_y: 0.130000 vec_z: 6.095627
    vec_x: -11.793749 vec_y: 0.130000 vec_z: 6.095627
    vec_x: -5.693750 vec_y: 0.130000 vec_z: 6.095627
    vec_x: 0.406250 vec_y: 0.130000 vec_z: 6.095627
    vec_x: 6.506252 vec_y: 0.130000 vec_z: 6.095627
    vec_x: 12.706249 vec_y: 0.130000 vec_z: 6.095627
    vec_x: 13.506253 vec_y: 0.130000 vec_z: 6.095627
    vec_x: 15.506252 vec_y: 0.130000 vec_z: 5.095627
    vec_x: 15.906250 vec_y: 0.130000 vec_z: 4.695629
    vec_x: 16.506252 vec_y: 0.130000 vec_z: 4.095627
    vec_x: 16.906250 vec_y: 0.130000 vec_z: 3.695629
    vec_x: 17.906250 vec_y: 0.130000 vec_z: 1.695629
    vec_x: 17.906250 vec_y: 0.130000 vec_z: 0.995628
    vec_x: 17.906250 vec_y: 0.130000 vec_z: -2.704372
    vec_x: 17.906250 vec_y: 0.130000 vec_z: -3.404373
    vec_x: 16.906250 vec_y: 0.130000 vec_z: -5.404373
    vec_x: 16.506252 vec_y: 0.130000 vec_z: -5.804373
    vec_x: 15.906252 vec_y: 0.130000 vec_z: -6.404373
    vec_x: 15.506252 vec_y: 0.130000 vec_z: -6.804373
    vec_x: 13.783194 vec_y: 0.130000 vec_z: -7.804373
    vec_x: 13.369722 vec_y: 0.130000 vec_z: -8.044335
    vec_x: 10.000000 vec_y: 0.100000 vec_z: -10.000000
    <locomotion target="-10 -10 -12 -8 -13 -8 -15 -7 -15 -6 -16 -6 -16 -5 -17 -3 -17 -3 -17 1 -17 2 -16 4 -16 4 -15 5 -15 5 -13 6 -12 6 -6 6 0 6 7 6 13 6 14 6 16 5 16 5 17 4 17 4 18 2 18 1 18 -3 18 -3 17 -5 17 -6 16 -6 16 -7 14 -8 13 -8 10 -10"/>

but that only helps a little.

Is there a way to avoid this? Am I generating my navigation mesh improperly (I use Blender Game mode to generate the mesh, I have tried about 20 different settings)? Maybe a way to speed up the animations to make the scene 0.1 look natural?

August 5, 2015
5:26 pm
Avatar
Admin
Forum Posts: 983
Member Since:
December 1, 2011
sp_UserOfflineSmall Offline

The scene scale should match the size of the character, where '1.0' indicates that units are in meters, or '.01' indicates that units are in centimeters, etc.  That number is also used during steering and retargeting to scale the motion/animation as well as the steering space grid.  What size is the actual character (in units?)

I have also seen that problem when the grid size is not set well; there are a number of parameters (see manual on page 117) to play with.

If you still can't get it working, you can send me a video and your model.

Ari

August 5, 2015
5:49 pm
Avatar
Member
Members
Forum Posts: 11
Member Since:
July 29, 2015
sp_UserOfflineSmall Offline

What exactly do you mean by character size (mesh_scale, getSize although that returns a vector, or something else)?

As I mentioned I'm using the irrlichtsmartbody.py example with some changes, and it's using sinbad - I don't think I touched anything regarding his size (I did change how he is rendered in Irrlicht - downscaled to orginal from *10).

I didn't realise the steer agent had anything to do with it, I'll play around with its settings.

 

Update: I set "steering.pathFollowingMode" to True (I was trying to do that earlier but before the createStandardControllers() retargetBehaviorSet() and I didn't notice the error denoting the missing attribute in the log), and the character does not spin around anymore, he still walks a little bit slow. I'll play around with other settings further.

The path finding also works if I set steering.smoothing to False, which I would guess is more desirable since according to the documentation the pathFollowingMode is a "simple path finding without obstacle avoidance", which, if I understand correctly, turns off collision shape detection.

My  steer manager gives me:

gridDatabaseOptions.gridSizeX: 35.000000
gridDatabaseOptions.gridSizeZ: 35.000000
gridDatabaseOptions.numGridCellsX: 70
gridDatabaseOptions.numGridCellsZ: 70

Is there any way to tell what those values should be?

 

Thanks for the help, I really appreciate it.

August 6, 2015
4:42 pm
Avatar
Admin
Forum Posts: 983
Member Since:
December 1, 2011
sp_UserOfflineSmall Offline

I ran the code using sbgui and the OgreDemo.py in data/examples which will work with the following changes:

1) Since the Sinbad character uses a scene scale of .1, you need to make the navigation mesh 10x bigger, and subsequently the path bigger as well by 10, so the new path should look like this:

bml.execBML('*', '<locomotion target="-100 -100 -120 -80 -130 -80 -150 -70 -150 -60 -160 -60 -160 -50 -170 -30 -170 -30 -170 10 -170 20 -160 40 -160 40 -150 50 -150 50 -130 60 -120 60 -60 60 0 60 70 60 130 60 140 60 160 50 160 50 170 40 170 40 180 20 180 10 180 -30 180 -30 170 -50 170 -60 160 -60 160 -70 140 -80 130 -80 100 -100"/>')

 

2) Change the grid size of the steering manager to cover the entire space:

scene.getSteerManager().setDoubleAttribute("gridDatabaseOptions.gridSizeX", 100.0)

scene.getSteerManager().setDoubleAttribute("gridDatabaseOptions.gridSizeZ", 100.0)

scene.getSteerManager().setEnable(False)

scene.getSteerManager().setEnable(True)

 

3) On the character, enable faster turning by setting the angular gain higher:

scene.getCharacter("sinbad").setDoubleAttribute("steering.paLocoAngleGain", 5.0)

 

I have uploaded a video of this here:

 

Please let me know if those changes work for you.

Ari

August 17, 2015
1:19 pm
Avatar
Member
Members
Forum Posts: 11
Member Since:
July 29, 2015
sp_UserOfflineSmall Offline

Sorry for the late reply.

I'm most likely going for Brad and Rachel in the end, so I think I'll just drop Sinbad for now, and from the example python scripts it seems like they both have a character scale of 1.0.

Thanks for the help, your replies explain a lot about the api and the general idea of scale.

Forum Timezone: America/Los_Angeles

Top Posters:

jwwalker: 80

jyambao: 52

rbaral: 47

adiaz: 30

WargnierP: 29

lucky7456969: 28

mbarros: 28

avida.matt: 26

JonathanW: 24

laguerre: 23

Member Stats:

Guest Posters: 69

Members: 122101

Moderators: 3

Admins: 4

Forum Stats:

Groups: 1

Forums: 5

Topics: 531

Posts: 2495