navArea Editor Demo Videos

[Pixel Perfect]

Updated the first post with the final video this morning showing the techniques applied to the whole test level. No commentary on this as it's more 'in game' focused. Copy of the link below (again best watched using the 480p option):

 

http://www.youtube.com/watch?v=L8sn5kA7eKs

[Richard Simpson]

Oh man, this is too cool pixel! for the destructable objects... does your editor automatically break up the model like UDK does? Or would it have to be modelled in parts?

 

Looking forward to seeing more of this.

[Pixel Perfect]

for the destructable objects... does your editor automatically break up the model like UDK does? Or would it have to be modelled in parts?

Thanks Richard. In answer to your question .. no it's not that sophisticated so you need to, as you suggest, model the parts externally. However to add them to my engine is simple, just a question of filling out a series of properties in an ini file associated with the main model file and the engine does the rest for you. You can assign how much force is needed to trigger the break or explosion and it supports any number of parts. You can even assign a burnt model to substitute for items which are marked as just flammable.

 

I actually produced the broken parts for the items in the video using the original models and gmax and I know nothing of modeling! Making all the Newton physics files is a pain though!

[Sooshi]

hey Pixel, great stuff man, one suggestion though. You may want to tone down the speed of the NPC's as they are seeking through the level, the speed is kind of too fast and doesnt match the animation properly in my opinion. But im sure you have already noticed this and are not concerned as you are primarily concerned with testing things out. Looks awsome man, I am such an RPG nut and I cant wait to implement my own pathfinding solution in my Zelda/ICO clone that I am starting later on this year after "whats bugging you" is done. But mine will not have navamesh solutions though.

[Pixel Perfect]

Yeah, the animations all run fine when it's not being frapped lol, with no foot skating! However, it does show a problem in my code as it's supposed to be able to cope with all that. That's something I do need to look at. But yes, as you say, I'm not too bothered about the fine detail just now, just trying to get all the key components in place first and I'll go through a major refinement process once that's done. I’ve picked up on a lot of things though putting this together … the list is getting quite long! That will inevitably keep me out of mischief for a while when I get round to fixing it all

 

Good to hear about your RPG plans. Good luck with that Kevin

[TylerH]

In regards to the foot skating, should be as simple as modulating either your animation, pathfinding movement, or both, by AppSpeed.

[Pixel Perfect]

Yeah, its just some silly bug thats crept in there somewhere. I did some stuff on modulating the movement speed to reflect the gradient and I've obviously screwed something up

[Richard Simpson]

Thanks Richard. In answer to your question .. no it's not that sophisticated so you need to, as you suggest, model the parts externally. However to add them to my engine is simple, just a question of filling out a series of properties in an ini file associated with the main model file and the engine does the rest for you. You can assign how much force is needed to trigger the break or explosion and it supports any number of parts. You can even assign a burnt model to substitute for items which are marked as just flammable.

 

I actually produced the broken parts for the items in the video using the original models and gmax and I know nothing of modeling! Making all the Newton physics files is a pain though!

 

 

Ah cool. Thanks for the answer. B)

[Pixel Perfect]

Just a quick update to say that I've now coded some additional path finding visual feedback into the Editor. The 'Test Pathfinding' function now not only displays the final calculated path in blue with an NPC walking it but also all of the grid tiles taken into consideration whilst running the A Star algorithm and displays those in red along with the elapsed time in thousandths of a millisecond using a high precision timer. It will even sequence through these in slow motion (one every 1/4 of a second) so you can see the exact sequence of checks as they occurred when the algorithm was run.

 

This gives the designer much more visual information on the performance of the system and allows for better fine tuning. This is great for playing around with heuristics and visualising the effects of any changes. It also gives good visual indication of where geometry layouts result in inefficient path finding using the A Star algorithm and allow you to do something about it or at least make decisions about how path finding in those areas will be executed. (This is a well recognised issue with A Star where, in the worst case scenario, certain combinations of start and end points combined with geometry can end up with it searching through practically every node on the grid before resolving the path).

 

As my system can divide long path searches over multiple frames where needed this is less of an issue but the visual feedback can result in minimisation of these issues by aiding the designer tweak the level design.

 

I'm off on holiday with my family later tomorrow (a complete break from computers for a while ) but will be concentrating on developing some real AI capability for my engine and editor on my return.

[AggrorJorn]

That sounds really cool Pixel. Can't wait to see that in a working example (^^hint)

[Pixel Perfect]

I updated the 2.24 Leadwerks Island Demo today to run in 2.40 in order to see how well my path finding would work with that type of level. I found I was able to use a single navArea to cover the entire Island and it took about one and a half minutes to process the geometry. Tested NPCs walking the terrain and it all worked perfectly, very pleased with the results. I now believe my navArea approach is pretty much suitable for anything I care to throw at it.

 

I've included a couple of pics below:

 

 

[AggrorJorn]

Very cool pixel. How large of an area are we talking about here?

[wailingmonkey]

that looks awesome, Pixel! I don't recall from watching your vids, but is there a 'buffer' property that one can assign,

for instance, if you wanted to allow somewhat 'close' proximity to a tree?

 

Keep up the good werk, dood!

[omid3098]

very good pixel!

[Pixel Perfect]

Cheers guys!

 

How large of an area are we talking about here?

The Island demo is a half kilometre square area (512x512 @ 1m per tile)

 

 

is there a 'buffer' property that one can assign,

for instance, if you wanted to allow somewhat 'close' proximity to a tree?

Currently, the path finding resolution is determined by the grid size and any obstacle within a grid will result in a non walkable area but this is only used to find the route from the first node on the path to the closest node to your destination. The movement system is designed to then move you from the last node to the target position if flagged to do so. So if you specify a position directly behind a tree which happens to be within a non walkable area the moveToPosition command will get you there using the path finding to get you as close as possible and then finally move you up to your chosen position. The path finding is an aid but does not restrict your ability to move an NPC anywhere. If you choose to collide it with a wall by taking the NPC right up to it then it will allow that! This allows for cover positions etc where you might want to get 'up close' and also works on the principle of 'the game designer knows best'. Otherwise, it will only accept target destinations that are not in non-walkable areas.

 

Not sure if this answers your question or not

[Mumbles]

The Island demo is a half kilometre square area (512x512 @ 1m per tile)

 

512 metres squared? as in 262,144 square metres?

The first measurement sounds really small, but the second makes it sounds ridiculously large... Your system copes with that size without any slowdown?

 

What's the density of your NavArea? 1 cell per 1 unit? Or a little less dense than that?

[Pixel Perfect]

What's the density of your NavArea? 1 cell per 1 unit? Or a little less dense than that?

A little less dense, I'm using a 250 by 250 grid as the geometry density is not large on this type of level with plenty of space between non walkable tiles. As the Island doesn't actually cover the entire terrain I could have brought the grid boundary markers in and reduced this to further increase performance but it was easier to just set them to the extents of the terrain.

 

Yes, the system copes with this size without any real slowdown but if a slow processor was struggling you could break it down into say 4 smaller linked navAreas. Linking them along paths and natural topographical boundaries is really easy for this type of terrain. Hierarchical searches across multiple navAreas can be carried out over multiple game loops helping maintain overall frame rates but it’s rarely needed unless you are driving a lot of NPCs.