"Shaky" path when using Offset Simple Smooth Modifier

Beginner Questions
#1

Hi there,

I have my AI rotating towards the direction of its delta movement.

When I use a Simple Simple Smooth Modifier with the following settings:

Uniform Length = true;
Max Segment Length = 5;
Iterations = 2;
Strength = 0.5;

The movement rotation is quite smooth, no matter the direction the agent is travelling.

However if I change to an Offset Simple Simple Smooth Modifier with the following settings:

Iterations = 2;
Offset = 3;

When moving along an essentially straight diagonal, their facing direction wobbles left to right.

You can see the two paths generated here: https://i.imgur.com/kFuDPWr.png

I should also note that axis aligned (horizontal and vertical) sections are perfectly smooth.

I can’t quite figure out why this is happening, is it because there is a minor offset occurring between each individual node? Do you have an idea of how I could fix this?

Thanks!

#2

Hi

The offset mode assumes that the path has been simplified before (using e.g. the funnel modifier or the raycast modifier). Otherwise it won’t really work well.
To be honest I have never really liked the offset simple mode because it is quite unstable, but it has been kept for backwards compatibility reasons.

#3

Oh wow, I had never tried Raycast Modifier, it makes my path much, much nicer! Now they tend to walk in the middle of areas, rather than hugging walls! By adding a thickness to the raycast it also seems to take care of what I was trying to solve with the Offset Simple, which is them bumping into things when rounding corners?

#4

Nice that it works well for you.
The raycast modifier will not move the path away from corners though, it will only remove intermediate points when there is a possible straight path. If you want them to stay away from corners more you could try

#5

Yes, I’ve just realised that, hehe. Is there a reason why these points wouldn’t have been simplified using the Raycast Modifier?

https://i.imgur.com/uPCKIz5.png

The only thing I check for collisions with is walls, of which there are none.

I reduced my Pick Next Waypoint Distance from 10 to 5 which also seems to have helped. Though I’ve just looked up the documentation for erosion (and seen this forum post) and that seems like it might do exactly what I’m after.

#6

Hi

A higher quality setting on the raycast modifier will usually simplify those points as well (at the cost of a higher performance overhead).
See the animation here: https://arongranberg.com/astar/docs/raycastmodifier.html

#7

Ah, I see erosion is actually somewhat functionally similar to the diameter, which I’m already using. Is there a benefit to using one or the other? (Erosion can add tags to surfaces, which I assume means instead of marking as non-walkable I could just set a higher cost, but that doesn’t really benefit my situation.)

#8

Erosion will also remove nodes around ledges, which the collision diameter will not detect. So it depends on what you want to achieve. Erosion is also generally slower. The collision diameter can also be set to any floating point value, while the erosion can only be set to integer values.

#9

That makes sense. When you say ledges do you mean areas without walls but that are unwalkable? I think maybe that might be a 3D specific thing? (I’m in a top-down, 2D game.)

#10

Yeah. Like at the top of a cliff. For a 2D game that wouldn’t really happen in most cases.

#11

I tried setting the quality to the highest, however I’m still getting a few artifacts. Is this just inevitable?

https://i.imgur.com/KbxZVgA.png

#12

Yeah, sometimes it cannot remove everything unfortunately. Making something that would simplify it as much as possible would unfortunately be very CPU heavy, which wouldn’t be very suitable for a game.
Using the graph raycasting is usually faster and more accurate btw (if you were using the 2d physics option). Though of course it does not provide a thick raycast.

#13

Hah, I was actually just wondering which would be faster. I seem to be getting an almost identical result in terms of bumping into things (minimal) between physics and graph, but it looks like it’s smoothing out the spot I was highlighting earlier:

https://i.imgur.com/WVQB01C.png

So it looks like that might be the winner!

1 Like
#14

It’s interesting that the raycasting via graph moves the path towards the door frame a bit more. As I’d have thought it would detect the door frame as an obstacle?

https://i.imgur.com/oj2w23m.png

Oh though is that because like you said, it doesn’t use a radius to determine the eligibility?

So they do bump into some door ways, but because the path there is already just a single connection, I am not sure what I can do about that?

#15

Make sure you visualize the graph using the ‘Show Surface’ mode. That will allow you to see exactly which parts of the ground it will allow a straight line to go over.

In your case I have a feeling that you might want to increase the resolution of your graph a bit. It looks a bit too low res to be able to handle those details like the door entrance.

#16

Alright, I increased my resolution by changing the node size from 5 to 2, and then the diameter from 1.95 to 5.2 and the result is only hitting a very occasional corner! (The agent’s diameter is 10, so I suppose in my previous setup the collision tests were too small.) Plus it looks like he’s navigating doorways more naturally. I also don’t really see any noticable performance decrease? (The reason my original graph was fairly low resolution.) Though I have to apply this to the other graphs in the scene yet (multiple floors), so perhaps I will see it then.

For my own curiousity, how does the resolution affect where he approaches the door from? As I’d have thought because there was just the single connection he would be forced to take it through the center anyway?

#17

Note that the diameter is in terms of node widths. So 1.0 corresponds to the diameter being equal to the node size.

The agent will find the shortest path to the target, that’s really the only constraint.

#18

Yeah so previously my node size was 5, and my diameter 1.95, which is actually just short of my agent’s diameter (10). Whereas now I’m testing just over (10.2), which obviously solves a lot of the corner cutting, and I can’t even seem to detect a single reliable frame loss per second.

The only issue I’m still facing is open doors. I have tried to mark the area the door opens to with a tag, but the tags are seemingly ignored by the smoothing pattern, is that correct? Is it extremely expensive to instead recalculate the walkable area?

#19

There would barely be a frame rate loss in this case. It would take a bit longer to scan the graph, and path calculations would take a bit longer (but that is mostly offloaded to a separate thread anyway).

Yeah, the smoothers don’t take into account any world geometry or tags I’m afraid.

Depends on how often you do it. It’s not particularly expensive if you don’t do it too often and only update a small region of the map. See https://arongranberg.com/astar/docs/graph-updates.php (see also example scene 2)

#20

OK, maybe I’ll try marking the area as non-traversible instead. It will only happen at the start/end of opening a door, so it should be fairly infrequent.

Thanks so much for all of your help, it is all looking much, much smoother than before! One final issue I’m facing is below:

https://i.imgur.com/rouYXRe.gif

He is following a path, reaches the end and searches for the next, however the overcompensation to join the next path results in a waggle of adjustment (in that image, looking too far to the left before correcting). Is there somewhere I could fix this? It’s almost like he’s trying to go to a path node he’s already ‘passed’.