yeah bake to mmaps is the hard part. I can for example move mesh vertices and save tiles from within the client
But adding new vertices and polys and baking them in is much harder. Would gladly see what you come up with.
@scimmy
your pm is full...
Ye I drew the objects boxes like you did just for visualizing. Some objects I used the scale from the vtable function and it looked alright. but for some I had to correct it.
In the end I tried some node adjustment in my nav code to get around objects ,but the easiest and best result was just TraceLining in a sort of Wide angle and strafing left or right and then recalc path every time.
Never really gets stuck if done like that, and for my needs this was the best solution.
Yes, I think the same as you.
Find path:
path.jpg
Agent:
agent.jpg
The question is how to make the right choice when this happens?
choice.jpg
Wow, that's the hard way, unless your navmesh generator tool already has the feature to do this for you. If you only want to cut game objects from the navmesh there are easier ways. Unless u want to dynamically do that and your navmesh supports the "TempObstacles", then thats the way.
obb is much better.
obb.jpg
The next step is to introduce:
https://www.red3d.com/cwr/steer/
I meant something like this:
gos.jpg
No, going to database of private servers is not reliable. As I said, if u want to dynamically block the object on navmesh while in game then TempObstacles in the navmesh is the only way. But if u want to statically do it then u can transform the collision vertices of the object like u did above for the bbox and record it for navmesh generation. Only u dont need to add it to the map as an object, it makes it much harder, recast supports other ways to cut objects from the navmesh like boxes and convex volumes. it is much easier to create a convex volume from the vertices and use it in navmesh generation.
Thank you for your suggestions and reminders.
If the database is not trusted, it means that the data of the dynamic gameobject cannot be obtained. That is to say, the static method is not feasible unless sufficient accounts are used to collect data.
Then there is only dynamic avoidance. Under normal circumstances, navmesh can avoid 80% of obstacles, and use certain AI pre-judgment to avoid them through the Strafe Left/Right and Turn Left/Right, instead of directly hitting them as before. What needs to be worried about is the avoidance behavior itself, which may bring the character into a dangerous area.
When the character stands at the door of orgrimmar bank, within 100 yards, there are 58 gameobjects in total.
After removing the static gameobjects that have been baked into mmaps, there are 26 remaining.
After reducing the distance to 50 yards, there are 6 left.
If the detection distance is set to character speed x 5 seconds, only 4 are left. When it is stopped, there are only 0.
When remove the gameobjects without collision, the number will be further reduced.
So we don't need kdtree when using obb.