Sign in to follow this  
  • entries
    235
  • comments
    509
  • views
    172053

Pathing Fix

Sign in to follow this  

81 views

Pathing Fix

Last night I decided to put some of the cool new physics-based weapons in something resembling a real game level, so I brought
up the editor and dropped some throwing knives and an axe into the level, saved it, then ran it through the game engine.

The good news is that the weapons worked very well. The bad news is that the AI pathing stopped working for some reason,
although it had been working on that level before. I ran through another test level, and the pathing was working, so I loaded up the working level, then saved it in the editor, then ran it through the game. Now this one was broken also.

So, working on the physics somehow screwed up the paths. Turned out it was the fact that some things in the editor considered
their origin to be at the bottom of a mesh or entity. This is convenient for placing things on their feet. Of course, this origin is not ideal for, say, the center of mass of a physics system. So, it was just a mismatch between differing origin standards. Once I sorted that out this morning, the path started working again on the Temple of Arkhana level. Here is a shot of a path successfully being found over the bridge, but not into the water.



Another section of the level showed the fountain, which has a ramp up, which is the only way up into the fountain, but the
path system was treating the whole thing as connected. Of course, this was due to the symmetrical paths hacks I put in last week or so, where for some reason going a->b and then going b->a was not working, even on flat ground. As a hack, I made all paths symmetrical, but this caused a problem with the fountain, where you could drop down off the fountain successfully from anywhere, but could only get back up from the ramp. So, I decided to go back, with fresh eyes, and fix this once and for all.



It turns out it was a fairly easy fix. I had overloaded the idea of NavigationNode.mID == 0xfffff to mean an invalid node. This is fine for neighbor checks, but it created a bug whereby I was finding the valid node, but its id was still 0xffff b/c it was still invalid, thus about half of the links where being marked as invalid inadvertently. So, I fix this bug, and also added a separate valid field instead. So, now asymmetrical links are working. The code still needs some tweaks, as I am finding valid links that should not be marked as such, but its much closer now.

Here is a shot of the enemy approaching the player, and a physics-based boulder in the background.

Sign in to follow this  


4 Comments


Recommended Comments

You know, looking at that last screenshot, are you planning on applying any kind of filtering to the shadows? They look kind of sparkly in screenshot form (does it look better in motion?)

Share this comment


Link to comment
This particular shot does look that way, but it's not that usual. I used to do fake shadows that were smoother, but they had rarer but worse artifacts with leaks.

I don't plan on making them softer, but I do have two ways to clean them up :

a. There is a shadow resolution factor that effects how many texels each shadow gets. I plan to add a per-item factor on top of this that can prioritize certain items lower or higher

b. Right now I am not fitting the shadow frustum to the character's local bounding box like I should. So, because of the sun angle, the shadows don't fit as well into the atlas as they could and also look worse then they would if they were lined up vertically.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now