• Content count

  • Joined

  • Last visited

About thrice

  • Rank
    Advanced Member

Contact Methods

  • Twitter
  1. 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
  2. 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...
  3. 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)
  4. Link to cpu profile of app using 3.2 (now FUBAR) version 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.
  5. 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.
  6. I can give the update a try tomorrow if the nightly is what triggers the npm build (so whenever fix is pushed to npm)
  7. 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?
  8. Right, but I am not referencing in my project at all, and still seeing the performance issue. Fingers crossed
  9. Is it possible to easily disable the physics engine in your project, and update to 3.2 just to rule that out as the culprit? Because I am seeing the behavior without any physics enabled on my scenes (and not sure if the sponza demo is using physics but I would imagine not). ^ (unless as I was theorizing earlier, somehow physics is getting auto enabled or something, since this all did start happening as soon as cannon.js was included as part of the bundle. I doubt that is it based on profiles and what not but the timing of cannon.js all of the sudden being packaged with babylon / performance issues arising, does seem suspicious.)
  10. @Deltakosh To be clear, I assume this fix has nothing to do with the performance issues I and others are seeing with 3.2 correct? (because performance issues are happening outside of sandbox).
  11. Of the profile output? Sure but I'm no expert at interpreting the output, and not entirely sure what normal looks like. Here are some shots of what appears to be relevant. One thing that does seem curious is on the line graph, there does not appear to be a line for GPU memory as far as I can tell. Also the warning on the animation frame fired / recurring handler. -- it does seem consistent with the behavior I am seeing in my electron app (mostly doing nothing, and fps is < 60, well in this case < 10 fps). Also worth noting that when I had my app upgraded to the newest version, I ran it on my laptop (new macbook pro), to make sure it wasn't a computer thing/setting. Performance was consistent with my current computer (2015 iMac). -- And I just ran sponza on my macbook pro also to make sure, performance is < 10 FPS there as well. Are you guys not seeing < 10 FPS ?
  12. On the sponza scene? sure.
  13. That's a good point. I will try to find time to switch back to newer version to get the output in next couple of days. In the meantime, I may or may not have noticed something that could be helpful in terms of reproducing. The sponza demo scene , is running for me at < 10 FPS consistently. I don't ever recall seeing it that low in the past, perhaps it is suffering from the same issue(s)? Also, the resize behavior you pointed out is consistent with that scene as well, if I shrink the window down super small, FPS not changing. Consistent < 10 fps
  14. Profile from alpha version - I'm not entirely sure what to make of it though. Seems like cpu issue if I'm reading it right, but still unsure as to why. And also if I'm reading it right, render % seems lower, which would lead me to believe it should actually be performing better.
  15. Actually: @aWeirdoNow that I'm looking at your playground/reading your post closer, it kind of proves my point above. No mesh is being disposed in the first playground, therefore dispose isn't being triggered. It seems to be happening upon adding a mesh to the highlight layer, so looking at the changed code, I'm not sure how that fix would have fixed it, since that code path shouldn't even be getting hit at that point (and that's the same behavior I am seeing in my local project as well) @Sebavan