AI Libraries for Panda3D

I did everything again and uploaded every file and source code. Hope this can help you and me much more.

First I created plane with 3x3 faces in Blender 2.49b:

and exported it with Chicken R85:

Then I removed the face in the center:

and again created egg-file:

After that I converted the egg-files

D:\Programme\Panda3D-1.6.2\bin\egg-trans -C -o mesh1.egg mesh.egg
D:\Programme\Panda3D-1.6.2\bin\egg-trans -C -o col_mesh1.egg col_mesh.egg

to and

Finally I created the csv-file

meshgen mesh1.egg col_mesh1.egg

and I got

I ran the programm again with this files and again the same behavior. If you want to have a look on the code:
Not really nice coding but should work.

I really hope you can find the mistake and I hope that I made it.

If you need more information or i have missed to upload a part of the code or something else, please let me know!

This is good info!..Will check it out and get back to you.

Would there be a way to generate a navmesh from a collision scene?

Do u mean a scene created in Panda with collision boxes and so on?

Yes and level based collisions.

But reading more about navmeshes ( ) I think its probably better to draw them by hand.

Then i came up with a second question: would be able to convert a navmesh drawn in blender to your csv representation?

It is easier to implement it by drawing by hand and it isn’t too much work for the artist too I feel. This is why we chose this direction.

We create a plane with subdivisions as a grid in max, maya or blender and export it as an egg from which we generate a navigation mesh and create nodes for path finding.

The more dynamic creation of path finding is something we looked into earlier on but was out of scope then. We also looked into Recast and Detour but that was in its research phase and was hard to integrate into Panda for our project.

Thanks for that detailed info peerpanda. It really helped. So we have narrowed down the problem and it is being caused due to Blender. By taking a closer look at the .csv file we found out that the row and col indices are not matched against the node positions, and this is why you were getting the weird behavior with pathfinding.

We had tested our pathfinding with eggs generated from blender previously and it had worked fine. However, when we create the .csv file using egg files that you provided, the data is getting corrupted. I am not sure what may be causing this. It might be an issue with how our mesh generation tool works and the way Blender stores its vertex data. We are currently testing more with Blender to see what the problem could be and provide a solution. Meanwhile, if you have access to Max or Maya, the pathfinding should just work fine.

Thanks for your patience!

To add to this, we think that Blender exports the vertices for a similar scene (in Max or Maya) in a different order (of vertices and quads). This will cause our mesh generator code to not create the mesh (navmesh.csv) correctly and hence the faulty pathfinding.

We did not test extensively with Blender as we were using Max and Maya at that time and so I guess will have to look into this a little more. Might even have to add a separate extension of the Mesh Gen for Blender.

I tried the same thing with 3ds max 7 and everything worked fine. But would be nice if you can support Blender, too.
Thanks for your fast and effevtive help!

Glad you got it working!

We know what the problem is with the Blender export -> meshgen. Currently we are looking into fixing it.

Will update the post when a fix is ready!

In the mean time since you have 3dsmax 7, you might be able to export your mesh from blender to a .3ds format and create the egg in max, just for the path finding to work.

Excellent library !

Some thoughts about new features:

  1. Defining forward vector for AICharacter. It’s hardcoded to -Y (or did I miss something ?), but several people has several settings. My characters are faced to +Y.

  2. Optonally instead of taking control on NodePath - just returning desired position and direction. This will make PandaAI universal and ready to use with physics cars for example.

  3. Movement looks quite predictable. Are you using always the same random seed ?

Hi derek,

  1. Yes it is hard coded as -y for now. Something to change for the future. We actually left it that way since orienting the model 180deg around is a simple requirement.

  2. We left it this way since there was a way to do what you ask. You can create an empty nodepath as an AICharacter and then get the position and orientation from it.

  3. By movement, do you mean the wander function? Because we did have an issue with our random number generator which would generate random numbers but in the same pattern. This is something we probably need to fix in a future version.

Thanks for the feedback.

Hi Derek,

Adding to what NNair posted, we felt that since Panda3D loads models in their -Y axis it wasn’t really necessary to have an axis toggle in there. We were using some core functions within Panda3D for the direction vector of the NodePath which will still return -Y as forward and so we left it was -Y axis.

Thanks a lot for the feedback.

Hmm, the Panda convention is that +Y is the forward direction.


Added to the to be fixed list. Control will be given for a user specified heading direction.


Sounds great. Btw by moving I mean wandering, yes.


hmm, If it’s +Y direction that is normal for Panda3D then it should be +Y. David, the lookAt function uses the original orientation of the 3D asset to rotate it to face the location we want it to. So if the 3D asset created in Maya is in -Y then it will be reverse, right?

Derek, We had some trouble with the random seeding with wander. That is something that definitely needs to be added.


The lookAt() function rotates the +Y axis of the model to face the indicated direction. If your model was created with his nose looking down the -Y axis, then lookAt() will appear to rotate your model facing the wrong direction.

It is a very common mistake for models to be created looking down the -Y axis, because that means the modeler gets to look him in the face when he creates him. But “forward” means looking into the screen, not out of the screen.


Hmm, I got it. So can I add a toggle in the lookAt() function so that it turns to look at the specified direction through time t rather than immediately doing so?

Or should i just write my own?

We usually do that sort of thing with an interval.