jme3-libraries-ai, path finding and navmesh

Troubleshooting ai
1

Hi all - I am about to embark on npc pathfinding in my game, and I’ve done a bunch of reading about what already exists and what doesn’t in JME

I keep seeing references in these forums to importing the jme3-libraries-ai library, but I can’t work out how to do it - its not in the list of plugins or libraries in jme3 beta 1. Do I really have to grab the source from monkeyzone or something?

I don’t mind writing my own A* pathfinding but I’d rather not if it already exists…

Also, it seems I’d need a navmesh - as I understand it, this is not something you generate on the fly - its something your generate before you ship the game?

2

I suppose you mean its not in 3.1 alpha? Because it definitely is in the 3.0 stable plugin list.

3

Oh yes of course - I mean the 3.1 alpha version. Durr.

I’ll check again. I am positive its not there.

4

No its not in 3.1, none of the plugins are available for 3.1 yet, 3.1 is alpha.

5

Okay, well I might see if I can get it running under 3.1 alpha - but I can’t seem to find the source. Is it not in the jmonkeyengine source?

6

https://code.google.com/p/jmonkeyplatform-contributions/source/browse/#svn%2Ftrunk%2Fjme3-artificial-intelligence%3Fstate%3Dclosed

7

brilliant thanks, wish me luck! I am proceeding on the assumption that using this library will be easier or better than rolling my own…

8

Thanks, normen. Another enhancement for this wiki page:
http://wiki.jmonkeyengine.org/doku.php/jme3:contributions

9

I added the code into my project, it failed to compile because in com.jme3.ai.navmesh.NavMeshPathFinder it uses the method interpolate on a Vector2f - this method doesn’t exist.

It looks like interpolateLocal is a suitable replacement. It compiles now. Lets see if I can get it working :smiley:

10

now I am getting “Warning, normal of the plane faces downward” in the console which seems to repeat forever - or a tleast a very long time. Any ideas?

11

Do all your normals go up (outside)?

I don’t know if this navmesh plugin uses CSG or voxels.
If it uses voxels, you only need to make sure normals are correct.
If it uses CSG, you might need water-tight meshes (no holes, no intersecting faces).

Question to the jME gurus: Wasn’t there a GSoC project to create a Recast binding for jME?

12

I am generating a navmesh from a heightmap - currently a 128x128 black png…

I am currently trying the get the smallest possible program that will produce a navmesh, so my next step is to remove the heightmap and just create a basic geometry. Perhaps its got something to do with how I generate the terrain…

13

I don’t know, in jME 2 you could activate debug shapes for all normals and see where they are facing.
Maybe jME 3 has a similar feature. I will google it…

14

Hm… I did not find anything. In jME 2 you could simply press “N” key and all normals showed up as red lines. We should have something like that in jME 3 too, I think.

Edit:
There is some material showing normals as colors + If you see something and culling is on (which is the default) then you know that normals face up.

15

I guess it’s something else - maybe something went wrong when you

You could use Vector2f.clone() and then .interpolateLocal() - since Local operates on the Vector instance itself.

And here is another thing you could try:
Just use a plane or a custom mesh or maybe try a sphere or cube and look what’s happening when you run the Navmesh generator on it.

16

Actually interpolate did it locally, thats why its been renamed in 3.1

17

Yeah i guessed that it did, but its good to know for sure :slight_smile:

18

So, I tried a cube and it gave me 10 warnings of “Warning, normal of the plane faces downward”. What on a cube occurs 10 times? 12 vertices, 8 points, 6 faces hmmm

I tried a plane, but a plane is a math construct not a shape. I thought of trying a surface but the NURBS things hurt my tiny little brain :confused:

I tried http://javadoc.jmonkeyengine.org/com/jme3/terrain/heightmap/AbstractHeightMap.html#normalizeTerrain(float) - normalising the heightmap, but clearly this doesn’t do what I thought it did, because the issue persisted…

I made a terrain heightmap 128x128 and it does eventually complete. I am going to play around and see if I get actual useful pathfinding out of it, then dive back into the navmesh code and see if I can’t divine the answer via osmosis. Perhaps if I look at the code long enough, the answer will reveal itself…

19

A cube consists of 12 triangles with 2 of them pointing up, 2 pointing down, 8 not pointing up.

Search for Quad (that’s what I mean). Also try a sphere.

Also check what you actually get (is it empty?, if not empty then what’s in it?).

Recast is the de facto standard for small or indie projects. It’s voxel-based and had a long evolution.

20

18 vertices, 12 triangles. That leaves 10 triangles whose normals are not positive Y, 2 negative Y and 8 0 Y. There we go! Does a terrainquad/terrainpatch have normals pointing down as well I wonder…

I’ll try a quad and a sphere.

good pioint.