Navigation without physics?

[f13rce]

Hey everybody,

 

I'm still working on that game where you capture bases and spawn fighters. I've been struggling for a while with my laptop because too many units (fighters) cause an insane drop of FPS.

 

Fortunately I know this time that my code is no big mess like it was back when I made Ravage (oops). It seems that the physics I had to apply with the navigation was bringing it down a lot (~120 FPS to ~5 FPS with 32 units on the field (tested on my laptop (specs below))). So whenever a unit is being created, I use the following lines to move it towards a position:

 

model = Model::Box(1,1,1);
pivot = Pivot::Create();

pivot->SetPosition(0, 0, 0);
model->SetPosition(0, 0, 0);

model->SetParent(pivot);

pivot->SetMass(1);
pivot->SetPhysicsMode(Entity::CharacterPhysics);

pivot->GoToPoint(10, 0, 0, 3); //Doesn't get called every update. Only when initialized.

 

Unfortunately, GoToPoint() does not work anymore if you comment out the SetMass() and SetPhysicsMode(). Neither does it work to replace Entity::CharacterPhysics with Entity::RigidbodyPhysics (which makes sense though).

 

I've included the source of the testproject to check the FPS. Just make a new C++ project and replace the files with the ones in the attached .rar file. I used Fraps to display the FPS.

 

---

Even if I can't disable the physics, is there any way to improve the FPS nonetheless? I'm not calling GoToPoint() every update or something like that, so that doesn't seem the problem.

 

Laptop specs:

OS: Windows 8 64bit

CPU: Intel Core i7 Q720 @ 1.60GHz (8CPUs)

Memory: 6GB RAM

GPU: Ati Mobility Radeon HD 5400

 

Thanks in advance

 

Edit: I should also note that I don't need any physics. The landscape is flat and the units only need to be on one constant Y position. I only need the navigation.

TestprojectSource.rar

[beo6]

Is it still slow when you disable physics?

Because there is an slowdown issue with dynamic shadows.

Try to disable shadows and see if it helps.

[f13rce]

Thanks for the comment beo6.

 

It's running fine if I don't add any sort of physics, but then I can't make use of the GoToPoint() function as navigation. So I'm kinda stuck here.

I've already set the graphics on its lowest settings. Disabled everything that wasn't necessary. It's really the physics taking the FPS down while I don't need it aside from the navigation.

[Rick]

I thought there was another post talking about how you can get the path details somehow. Maybe you can use that information (I'm assuming it's a list of points) to move the objects yourself instead of using the LE character controller?

[f13rce]

Sounds like a great solution! Although, do you still remember where you can find that post? I've done a quick search through the forums and documentation but I couldn't find anything related to that specifically. I'll keep searching though.

[Rick]

Found it

 

http://www.leadwerks.com/werkspace/topic/7902-navmesh-findpath/

 

Undocumented class that's probably only available via C++?

[f13rce]

Thanks Rick. I'll try to mess around with it.

[Tim Shea]

Evayr, just keep in mind that there will be position offsets applied and findpath should work well. This has the added benefit that if you have squads/collections of units, you should be able to share paths (thus reduce pathfinding cost) using formations.

[f13rce]

I see, thanks for the hint. I also saw from the post Rick linked you had a variable called "path" from the type NavPath. How did you assign the path the variable should be using?

[Rick]

There is a NavMesh class that has a FindPath() function. I would think this would be the return type from FindPath()? I'm not at my home PC but that would make sense to me.

[f13rce]

Ah yeah, FindPath() does return a NavPath. Now all I have to do is to find out how NavMesh works.

 

Edit:

World* world = World::Create();
NavMesh* navMesh = world->navmesh;

NavPath* path = new NavPath();
path->navmesh = navMesh;
path = path->navmesh->FindPath(pivot->GetPosition(true), Vec3(10, 0, 10));

 

Seems to work. When I add this debug for loop:

 

for (int i = 0; i < path->points.size(); i++){
cout << i << ": " << path->points.at(i).x << ", " << path->points.at(i).y << ", " << path->points.at(i).z << endl;
}

 

I get the following result:

0: 0, 1.75, 0
1: 8.25, 1.75, 5.5
2: 10, 1, 10

 

Sooo it seems to work! All I have to do now is making the unit move from waypoint to waypoint. Thanks for the help!

 

Final edit: Results are in... and wow.

With my PC the FPS would drop to 1 FPS after 64 units spawned using physics and GoToPoint()..

With the new way of pathfinding I get 1 FPS after spawning 1135 units who don't use physics anymore.

That's about 94% increase in FPS in general. Thanks again!

[YouGroove]

Could it be possible to have that feature in Lua in the future ?

 

Such increase performance if you just use the path infos without physics should be available for Lua users.

 

Well any game not concentrated on physics would benefit such "LightWeight" navigation system, as Entities that would

follow navmesh would not have to care about physics and environment in lot of cases of games like pure RPG, MMo style, RTS, tactics turn based etc ...

[Rick]

I agree, Lua should have this information. For things like tower defense games this would be very handy.

[Josh]

The character controller is one area where the performance can still be optimized quite a bit. We will see improvement in the performance of this during the spring.

[YouGroove]

I agree.

 

But using pathfinding without any physics can suit lot of games styles. Just need to port this code to some Lua function :

NavPath* path = new NavPath();

path->navmesh = navMesh;

path = path->navmesh->FindPath(pivot->GetPosition(true), Vec3(10, 0, 10));

 

And this should be an option for people to be able to choose to use physics or not in Navmesh functions.

 

And the result without physics is unbeatable like tested by Evayr :

With my PC the FPS would drop to 1 FPS after 64 units spawned using physics and GoToPoint()..

With the new way of pathfinding I get 1 FPS after spawning 1135 units who don't use physics anymore.

[Tim Shea]

Keep in mind, Evayr's use case for this approach was that the laptop which he is temporarily using to develop is too slow to run Leadwerks properly. It is an impressive improvement and certainly worth considering for some game types, but in general game engines use physics systems for good reasons.

[YouGroove]

If you make some RPG, with characters distance management, world of warcraft (no physics, even characters passing throught others) or even more simple, believe me you don't care at all about physics.

And such big performance improvement is just lot more power saved, specially if your game already takes lot of CPU.

[Rick]

WoW has physics. It's not just about passing through characters. Anytime you jump or fall it's physics, and you generally can do both in RPG's. Not using physics is probably more useful in RTS's.

[YouGroove]

Navigation is for NPC not for player, in WOW the ennemies pursue you by running on ground they don't jump, they could use navigation without any physic caus no jump.

If your RPG don't have jump abilty : diablo and others style games, you don't care about physics, gaining 100 FPS in navigation from CPU would be great benefit in lot of cases.

 

One big thing is that you could TOTALLY get rid of the first person controller, so you could make a ball, or cylinder OF ANY SIZE (that would be the character collision obejct) that would just follow the navigation path. NO more strange FIXED character controller size, specially when your character figths and walk against some giants bosses.

[Josh]

The navigation path itself is calculated based on given parameters like height and radius. Different sized characters would require a separate navmesh, as some openings might be too small for one character's dimensions, but big enough for another one's.