Ok so I have some rooms in my game where the entire room is dynamic. i.e. the floor moves and changes heights to make different terrains. Now my problem is I don't know how to get the navmesh to calculate over this area.

I know how to set obstacles to dynamically change the mesh but setting an obstacle does not seem to calculate new NavMesh it only takes away.

I thought that the Game::World.pathBuild() function would do the trick but it doesn't seem to exist anymore :O

Here's a video showing my problem:
http://www.youtube.com/watch?v=FV7AWk63z...e=youtu.be

Sooo... I take it it's not possible then? i.e. navmesh can only be calculated on terrain and those objects embeded in terrain?

Look at PathObstacle(). Recalculating is very slow but in your case you have to do it only once.

Thanks but as I stated in OP:

(07-01-2013 10:45 AM)Scarlet Thread Wrote:  I know how to set obstacles to dynamically change the mesh but setting an obstacle does not seem to calculate new NavMesh it only takes away.

I already know how to and already do set obstacles if you do it properly. That is not my problem. Obstacles only take away from Navmesh calculated from terrain objects. It does not add any new Navmesh on top of those obstacles.

The speed hit doesn't seem so bad from setting obstacles, but maybe in a big open world it would. Like you said in this case I only do it once. Though even for other objects say a dynamic box with physics I only set the obstacle once every x milliseconds / frames and only if it is moving.

Either way I'm planning on buying out the "Setting Path Obstacles in the Background Yhread" contribution closer to release of my game to help speed it up.

Greg could you please confirm or deny the possibility of building new Navmesh on top of dynamic objects that aren't embedded in the terrain. thanks.

this is an interesting question for me..
well i am working on a space game and i have large areas with nothing, i set in the model editor for planets for example that they will block...

my question is: does the navmesh only work in 2d?
i need a pathfinding algorithm to locate the correct path in 3d... any ideas?

I think the waypoint system is set up for pseudo 3D, and wouldn't work so well in a space game. I could be wrong about this, though.
However, it should be very easy to make dynamic waypoints. With space, there is so much empty area that actual objects should be easy to avoid. Try something like: check a ray from start to end. Each object encountered, use a cross-product * radius of the object * 3 or so and make a waypoint next to the body that you would have otherwise hit.

This is, however, very much off-topic, and unfortunately, I don't use the navmesh so I'm at a loss for this type of issue.

(07-03-2013 06:48 PM)xzessmedia Wrote:  this is an interesting question for me..
well i am working on a space game and i have large areas with nothing, i set in the model editor for planets for example that they will block...

my question is: does the navmesh only work in 2d?
i need a pathfinding algorithm to locate the correct path in 3d... any ideas?

Hey man, you should talk to Donik about this one he has thought about it a fair bit. I think the idea is that because there is so much empty space its more about avoiding other objects than it is pathfinding.

You've mentioned something in the video about ability to draw decals only on selected objects while they currently draw on top of the terrain - I'll add that functionality to the next release.

Game::World.pathBuild() I think it now has "2D" added into the name, however this is only for the old 2D path system in EE 1.0

I see that you have a bottom floor, and then on top of it boxes appear, do you need to have pathmesh created on top of the boxes as well? If no, then you can just have pathmesh created at the bottom, and then add path obstacles for the boxes.

If you need however to recalculate full navmesh, then you can try using this:
PathMesh.create
it requires MeshBase of all of the meshes in the area, area coordinates, and PathSettings
you'd need to setup custom PathSettings (areaSize member can be obtained from Game.World.settings . areaSize), all other members currently would need to be entered manually, you can open World Editor and copy the values from path settings.

Once you have a PathMesh object for that area, you need to call Game.World.path().set(&path_mesh, and area coordinates)
this is however non const method (set) but the path() returns const object, but you can convert it to non const object using this way:
define 2 global functions:
<TYPE> TYPE& ConstCast(C TYPE &x) {return (TYPE&)x;}
<TYPE> TYPE* ConstCast(C TYPE *x) {return (TYPE*)x;}
ConstCast(Game.World.path()).set(..)

Oh, forgot about the last thing, probably I'm repeating myself, but.. your video looks awesome

XD Thanks so much. That will help a lot.

Yeh I will need to calculate full navmesh because that floor you see isn't actually a floor with boxes apearing above them those are all pistons or columns packed closely together at the same height to make a floor. Have a look at this screen shot. You'll see each 2x2 block can have any height it wants , each map is based on an xml file containing heights so I can set it dynamically just by drag dropping xml files into it's parameters.

PathMesh.create is very CPU intensive, that's why it's precomputed in EE 2.0 editor, and then just loaded in the game.
Creating multiple PathMesh objects on multiple threads works fine, I'm doing this in EE 2.0, perhaps you have a different problem in your codes.

(07-04-2013 01:56 PM)aceio76 Wrote:  Hi just a quick question, Esenthel -- I have tried doing PathMesh.create() and while it may be ok for sporadic nav mesh changes, I had a hard time when I was calling it several times a second, and attempting to multi-thread it didn't work out so well. Do you have any advice? Scarlet Thread, I wonder if you will come into the same issues...

Possibly though I only have to recalculate once every time this room changes and that doesn't happen too frequently.. At most once every 5 - 10 seconds but usually more in the minutes time frame and not at all if I'm not using the room.

I guess I'll have to see when I implement this.

If it's taking long, you can create PathMesh on secondary thread, once it's ready, then link it with Game.World.path on the main thread.

(07-04-2013 01:25 PM)Esenthel Wrote:  You've mentioned something in the video about ability to draw decals only on selected objects while they currently draw on top of the terrain - I'll add that functionality to the next release.

next release will have this feature:
-new function "void SetStencilValue(Bool terrain=false)" which can be called before drawing meshes in RM_PREPARE (and should be reseted to default value afterwards) to specify that the mesh should be rendered with "terrain stencil value" which affects drawing of 'Decal' objects with their 'terrain_only' member enabled

(07-04-2013 02:34 PM)Esenthel Wrote:  

(07-04-2013 01:25 PM)Esenthel Wrote:  You've mentioned something in the video about ability to draw decals only on selected objects while they currently draw on top of the terrain - I'll add that functionality to the next release.

next release will have this feature:
-new function "void SetStencilValue(Bool terrain=false)" which can be called before drawing meshes in RM_PREPARE (and should be reseted to default value afterwards) to specify that the mesh should be rendered with "terrain stencil value" which affects drawing of 'Decal' objects with their 'terrain_only' member enabled

Awesome. Thanks

Thanks for adding the Decal feature it helps heaps. I can now draw my character selection decal on anything I want omitting a few things Like characters that I don't want it to draw on.

Thanks a bunch that fixed a big graphical problem.