Huge performance hit after upgrading from 3.1.0-alpha3.5 to 3.1.0-alpha3.7

[GameMonetize]

My problem is that I do not repro the performance issue anywhere not even on my phone. Sponza is running at 60fps even on my old Surface book

You can turn off physics completely by not referencing Cannon or Oimo.

 

EDIT: WAIT I KNOW WHY Please stay tuned

[MackeyK24]

Have you checkef out my space shooter 2 demo with physics... to see the problem

http://mackey.cloud/games/space2

 

[GameMonetize]

@MackeyK24 I guess this is because we fixed the way step is computed for physics. Let me ping @RaananW

[thrice]

4 minutes ago, Deltakosh said:

You can turn off physics completely by not referencing Cannon or Oimo.

 

Right, but I am not referencing in my project at all, and still seeing the performance issue.

 

5 minutes ago, Deltakosh said:

 

4 minutes ago, Deltakosh said:

My problem is that I do not repro the performance issue anywhere not even on my phone. Sponza is running at 60fps even on my old Surface book

You can turn off physics completely by not referencing Cannon or Oimo.

 

EDIT: WAIT I KNOW WHY Please stay tuned

Fingers crossed

[GameMonetize]

So it was because of the VRExperienceHelper which was turning scene picking on for interaction. I fixed that and the experience should be far better now.

Can you try Sponza again (after having cleared your cache) ?

[thrice]

23 minutes ago, Deltakosh said:

So it was because of the VRExperienceHelper which was turning scene picking on for interaction. I fixed that and the experience should be far better now.

Can you try Sponza again (after having cleared your cache) ?

Ok so on my macbook pro, if I reduce screen size to about 50% of screen, I am now getting 30 fps consistent (when stationary). If I reduce to 1/4 screen size I get to 60 fps, that's good news. Soon as I move however, it drops down to < 10 even with the smaller screen size. I think it may still be slower than it used to be, but I'm not entirely sure to be honest. -- And I can confirm that on my phone, performance is fine (60FPS), even when moving around (iphonex)

Can you let me know when there is a npm push with these changes so I can attempt to update within my project again, to see if performance is better now there?

[GameMonetize]

We will update it this friday I guess

In the meantime let me check if the VRExperienceHelper is not also turning on some unwanted postprocesses

Edit: nope we are good so please let me now when you will update to this version

[RaananW]

@MackeyK24,

I am not sure how fast the scene should run, but for me it runs smoothly.

Cannon is having a bit of a problem calculating the contacts to all of your impostors, so it is taking some processing power but still, the game runs in 60 FPS and with plenty of idle time. Sharing what I see (and note that it is a bit low-fps because of the recorder, not the game):

 

[MackeyK24]

Take a look at first space shooter

http://mackey.cloud/games/space

 

That is hoe it should play... and all the collisions are fine

 

[thrice]

2 hours ago, Deltakosh said:

We will update it this friday I guess

In the meantime let me check if the VRExperienceHelper is not also turning on some unwanted postprocesses

Edit: nope we are good so please let me now when you will update to this version

I can give the update a try tomorrow if the nightly is what triggers the npm build (so whenever fix is pushed to npm)

[GameMonetize]

Nope we push to npm manually ( @RaananW would you mind pushing the current alpha to npm?)

[GameMonetize]

If you are not using the VRExperienceHelper, I don't think it will change something.

By any chance, can you share two pages somewhere with your code? One without the perf issue and one with? I could then compare both

[RaananW]

@Deltakosh - 3.2.0-alpha0 was just published to NPM.

[GameMonetize]

Thanks man!

[MackeyK24]

Yo @RaananW  did you take a look at the first version using the 3.1 alpha before the cannon time step fix... its just way smoother and collision are are way better.

What can I do to my toolkit/code (babylon.js side) to get it back to the way it was using cannon...

Also.. Have you heard any news regarding Energy.js physics for babylon ?

 

Check out the first version: http://mackey.cloud/games/space

 

[RaananW]

@MackeyK24 - Why won't you apply more force to make it faster?I am not sure what the problem is...

the implementation of the step in 3.0 was (partly) wrong, and was fixed in 3.1. meaning, 3.1 is more physics-realistic when it comes to cannon. I am not sure how you move your objects, but if it is using liner velocity, simply double it. if it is using gravity, double the gravity. 

you have many objects created and disposed constantly, i once saw ca. 200 bodies registered in cannon. This is in general not a problem, maybe try creating collision groups (demoed here - https://github.com/schteppe/cannon.js/blob/master/demos/collisionFilter.html , can be added using the native elements in the impostor options). But again, this is CPU related, and not speed related like you describe.

[thrice]

So, I just update to most recent npm build and now I'm getting < 5 FPS   , may or may not be related to whatever was going wrong originally, because this seems to be something gone horribly wrong. ugh.

[thrice]

Link to cpu profile of app using 3.2 (now FUBAR) version https://www.dropbox.com/s/dfppq3nfauwpciq/dm_bad_with_resize_CPU-20171222T173429.cpuprofile?dl=0

And screenshot of the same 

 

I hardly know where to start with this though, since when I initially created this thread when I updated to 3.1.0-alpha3.7, I was seeing a 30ish FPS drop. Now I am seeing consistent < 1 FPS , totally unplayable, can barely move my mouse around the screen. So it's may be even harder to narrow down what the cause is, since there could be multiple causes now.

[thrice]

Ok so: lets forget about the FUBAR version for now and go back in time to original upgrade -- In an effort to narrow down the scope of the issue, I tried upgrading from alpha 3.5 to alpha 3.6, and I am seeing the 30ish FPS drop there. -- so, it appears that the initial FPS drop happened between 3.5 and 3.6 - ALSO, this is the first time that cannon is being included as part of the package as well. Seems suspicious. (once again not referencing cannon in MY code directly, but it does get included in the build since it was added as a BJS dependency)

[thrice]

Grasping at straws, but I really want to point the finger at cannon (even though I am not using cannon in my project), the dramatic performance drop as soon as it's included as part of build seems really suspicious. I am also see a strange (but in the past has been harmless), message from webpack, i.e.

 

WARNING in ./~/cannon/build/cannon.js
Critical dependencies:
24:432-439 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
 @ ./~/cannon/build/cannon.js 24:432-439

 

So it makes me wonder if maybe, since cannon uses alot of the same class/function names as babylon, somehow upon compilation something is going wrong and is being overwritten by cannon. Once again seems unlikely but, IDK...

[MackeyK24]

On 12/22/2017 at 1:42 AM, RaananW said:

@MackeyK24 - Why won't you apply more force to make it faster?I am not sure what the problem is...

the implementation of the step in 3.0 was (partly) wrong, and was fixed in 3.1. meaning, 3.1 is more physics-realistic when it comes to cannon. I am not sure how you move your objects, but if it is using liner velocity, simply double it. if it is using gravity, double the gravity. 

you have many objects created and disposed constantly, i once saw ca. 200 bodies registered in cannon. This is in general not a problem, maybe try creating collision groups (demoed here - https://github.com/schteppe/cannon.js/blob/master/demos/collisionFilter.html , can be added using the native elements in the impostor options). But again, this is CPU related, and not speed related like you describe.

I didn't think that would be my solution.. only because I thought gravity was really -9.81 so I would have to double that, that seemed a bit weird so I didn't think that was the FINAL solution to problem that would go into my toolkit for everyone to use.

about the 200 bodies... I was really creating and destroying to see HOW MUCH IT COULD HANDLE (and version 3.1 alpha was pretty smooth). And I was also testing my DISPOSE CHAIN making sure everything got disposed when using my manager.safeDestroy method... if 200 bodies are still registered then something in cannon is NOT UNREGISTERING on disposal... I will have to look at that... Is there a way to manually "UNREGISTER" a physics body, if so I will put that in object disposal code...

I was really gonna clean up the asteroid and enemy ships and RECYCLE from pre-created asteroids or dynamically create up to a certain number then start recycling... Something like that.

But if you say to simply DOUBLE all the velocity values (still a little concerned about having to double gravity which should be 9.81) but I will give that shot

Thanks for the help

[GameMonetize]

@thrice: I need to get a live repro here. We are shooting in the dark without that. 

Other option: can you do a diff between babylon.max.js in bot package (3.5 and 3.6)

30fps is HUGE. There must be something obvious and based on your screenshot there is NOTHING below 5% of CPU time

 

only problem is that 81% spend in Chrome "program". Which means that the culprit is in NATIVE code (or idle).

[thrice]

19 hours ago, Deltakosh said:

@thrice: I need to get a live repro here. We are shooting in the dark without that. 

Other option: can you do a diff between babylon.max.js in bot package (3.5 and 3.6)

30fps is HUGE. There must be something obvious and based on your screenshot there is NOTHING below 5% of CPU time

 

only problem is that 81% spend in Chrome "program". Which means that the culprit is in NATIVE code (or idle).

I get that we're shooting in the dark without it, that's why I've tried to be as detailed as I could with the profiling so hopefully someone would see something that would lead me to the issue. -- Unfortunately, can't produce a live repro atm due to app being wrapped with electron, and even then I still have a rails/node server separate that need to be run for it to work, so it's not possible atm.

That's a good idea on the .max file, I tried looking through the commits on github but wasn't easy to see what all changed between versions. I'll give that a shot

 

[MackeyK24]

Yo @RaananW or @Deltakosh What is the PROPER way to DISPOSE a mesh with a physics imposter on it ???

How do I make sure that instance is UNREGISTERED with physics engine so I dont have 200 bodies still registered in cannon ???

The latest physics changes to how we deal with cannon not only screwed (or how I was using it before does not quite work) the movement, but my disposal code as well.

Please bro, help help to clarify what I got do in my framework to deal with the Cannon Js changes from 3.1

 

 

[RaananW]

There were no major cannon.js changes in 3.1... Nothing really  changed other than the ticker. and the parenting system (which is a general issue, not cannon's).

Disposing - dispose the impostor and then the mesh itself. if it doesn't work, please let me know so I can investigate it.

Te reason for this is - A mesh and an impostor are loosely coupled. you CAN set mesh.physicsImpostor, but it is certainly not a must. It was mainly done since not only meshes can have a physics impostor. you, as a developer, need to take care of your impostors and dispose them manually. It is like that since 2.3 (If I am not mistaken), has nothing to do with 3.1 changes.