thrice

Members
  • Content count

    96
  • Joined

  • Last visited

Everything posted by thrice

  1. thrice

    Apple deprecates openGL

    When this was announced the other night I tried frantically googling things thinking the sky was falling. What I've learned from it (which may or may not be correct, correct me if I'm wrong): Each browser has it's own translation layer which translates things differently on OSX. On PC as davrious stated above, https://github.com/google/angle does all translation, down to directX. - It looks like on OSX angle is aiming to be translating over to vulkan which will fill the gap once deprecated. I haven't figured out what mozilla or safari are using (possibly forked version of angle for firefox: https://github.com/mozilla/angle), and maybe something already translating to metal for safari? Also the thing that I've still not been able to figure out concretely, webgl (on all non desktop devices) is based on OpenGL ES. which is completely separate from opengl. Some people are saying opengl ES support is NOT being deprecated, and won't be affected. (So basically, even though apple is saying we are deprecating opengl from iOS, it won't affect webgl to any degree on phone/ipad). So the good news is, as far as I can tell, the sky isn't falling, or at least not entirely.
  2. in 3.5 scene was rending at 60 fps, now I'm stuck around 45 fps as soon as I upgraded to 3.7 Even worse, load time of the scene increased from 28ish seconds to 75 seconds. My only hint is a cryptic webgl warning being thrown WebGL: INVALID_ENUM: getQuery: invalid parameter name but even then, I doubt it's responsible for the 15 fps drop (maybe the initial loading increase, IDK) Any ideas? -- side issue Additionally, I tried looking at drawCalls, as that was my KPI in the past for figuring out why frame rate was so low, and I am met with an unhelpful "drawCalls is deprecated. Please use SceneInstrumentation class" warning, and draw calls returning 0. So I instantiate the instrumentation, and I still don't see draw calls. I would think having that metric easily discoverable is pretty important?
  3. 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
  4. 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...
  5. 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)
  6. 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.
  7. 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.
  8. I can give the update a try tomorrow if the nightly is what triggers the npm build (so whenever fix is pushed to npm)
  9. 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?
  10. Right, but I am not referencing in my project at all, and still seeing the performance issue. Fingers crossed
  11. 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.)
  12. @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).
  13. 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 ?
  14. On the sponza scene? sure. https://www.dropbox.com/s/ge6mc8olk4nsly8/sponza_lte_10fps_Profile-20171218T145557?dl=1
  15. 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 https://www.babylonjs.com/demos/sponza/ , 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
  16. 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.
  17. https://github.com/BabylonJS/Babylon.js/issues/2624 This is still an issue for me. Was unable to reproduce on playground, however adding some additional information, maybe someone will have a clue as to what's going on because as of now I can't really use the highlight layer. When the scene is first loading up (and my meshes are being created for the first time), and a highlight layer is created while this is happening, I see a ton of undefined meshes stored in the highlight layer, which I have no idea where they are coming from. 85 to be exact. (note that at no point am I manually adding any meshes to the highlight layer) - The draw calls are now going from 110 to 220, so there are 110ish additional draw calls being added, even though the highlight layer isn't doing anything. These mesh ids, also don't appear to be valid anymore.
  18. 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
  19. @aWeirdo @Sebavan I think this issue is larger than just the dispose trigger. I monkey patched your change into my local project and realized, I'm now actually seeing the draw call multiplication as soon as I add a mesh to the highlight layer (not disposing any meshes, so that code doesn't get called yet). I'll have to dig into it further tonight or this weekend likely, but - created a brand new sphere at center of my scene and did, highlight_layer.addMesh(mesh, play_game.BABYLON.Color3.Red()) Jumps up from 91 draw calls to 186
  20. For comparison, here are the counts from the 60 FPS 3.1.0-alpha3.5 version: - Summary: there are actually slightly fewer meshes/materials active in the newer version - but also, in the newer version, you'll note that there are 487 meshes enabled, versus 616 in old version. So if anything you would think it would be rendering faster. The one and ONLY count that appears higher in the newer version, is count of undefined meshes in the _activeMeshes.data (23 versus 11) So, this furthers my belief that some change in the library itself is causing the slower performance. _.groupBy(_.map(play_game.scene.babylon.meshes, 'isWorldMatrixFrozen')) Object {false: Array[466], true: Array[1443]} _.groupBy(_.invokeMap(play_game.scene.babylon.meshes, 'isEnabled')) Object {true: Array[616], false: Array[1293]} _.groupBy(_.map(play_game.scene.babylon.meshes, 'areNormalsFrozen')) Object {false: Array[1313], undefined: Array[596]} _.groupBy(_.map(_.compact(play_game.scene.babylon._activeMeshes.data), 'areNormalsFrozen')) Object {false: Array[91], undefined: Array[154]} play_game.scene.babylon._activeMeshes.data.length 256 _.filter(play_game.scene.babylon._activeMeshes.data, _.isUndefined).length 11 _.groupBy(_.invokeMap(_.compact(play_game.scene.babylon._activeMeshes.data), 'getClassName')); Object {Mesh: Array[91], InstancedMesh: Array[154]} _.groupBy(_.invokeMap(_.compact(play_game.scene.babylon.meshes), 'getClassName')) Object {Mesh: Array[1313], InstancedMesh: Array[596]} play_game.scene.babylon.materials.length 712 _.groupBy(_.invokeMap(_.compact(play_game.scene.babylon.materials), 'getClassName')) Object {ShaderMaterial: Array[7], GradientMaterial: Array[1], StandardMaterial: Array[702], PBRMaterial: Array[2]} _.groupBy(play_game.scene.babylon.materials, 'isFrozen') Object {false: Array[712]}
  21. Well since the instrumentation stuff was added after the current version, it's hard to compare apples to apples. I'm going to go through and do the lodash counts on older version right now though to see if there are any discrepancies. Oh also, may be worth mentioning that I'm running my app with renderEvenWhileInBackground = false, I'm not sure if that has any affect on the idle time shown in the profiler or not (I clicked to debugger tools ,which freezes the app, started profile, clicked back into app to resume, and then triggered some hover states and what not)
  22. I'm not sure how lodash would make anything slower, its just a (heavily optimized), utility library, does not affect performance. I'm running those calls from the console, not like it's part of the render loop or anything. -- Regarding the canvas size: Nope I tried that actually. Shrunk it to pretty much phone size, seemed to run about the same
  23. Also in the comments of my profiling I did a count of materials .isFrozen, because that is a new property / optimization I hadn't seen before - Thought maybe it was recently added and all materials were frozen before by default. Anyways, I just did a _.invokeMap(play_game.scene.babylon.materials, 'freeze') on all 600+ materials, and while it looks like frame rate bumped up SLIGHTLY (seems to be hovering around low 50's now), it is still much lower than the consistent 60fps when nothing is going on, that I see with the older RC version
  24. Also here is screenshot of profile, all I did was pointer over a few cards to trigger hover states
  25. @MackeyK24 sorry for slow response, just saw you tagged me. - I'm just finally digging back into this. - I can tell you though that I don't use cannon for anything, so not sure thats the culprit. Unless it somehow is autoloaded/started in newer release or something? (I do see when I yarn install the latest version that it adds cannon as a dependency by default). So I just updated to latest release, and scene instrumentation now working for me (yay) - good news and bad: GOOD news is the issue regarding the scene load time seems to be fixed, and it is loading about the same amount of time as my locked version branch. BAD news is FPS is still sluggish. Upper 40/low 50s - @Deltakosh I've collected some output from various instrumentation calls, was hoping you could take a look and see if you see anything abnormal, because I'm not sure exactly what to look for. - Also I did some grouping and counting of other objects in the scene that in my limited experience, have seemed to affect performance the most (and I've optimized scene to do many, i.e. freezingWorldMatrix and disabling meshes that are not currently in use, of which I have many, because my project is a card game and I render a master list of all the relevant cards off screen for sake of hovers and what not) activeMeshesEvaluationTimeCounter { "_startMonitoringTime": 48000.035, "_min": 0, "_max": 125.875, "_average": 1.927268518518444, "_lastSecAverage": 1.3325480769225089, "_current": 2.6350000000020373, "_totalValueCount": 324, "_totalAccumulated": 624.4349999999758, "_lastSecAccumulated": 17.705000000009022, "_lastSecTime": 47866.435000000005, "_lastSecValueCount": 14 } renderTargetsRenderTimeCounter { "_startMonitoringTime": 85556.585, "_min": 0, "_max": 0, "_average": 0, "_lastSecAverage": 0, "_current": 0, "_totalValueCount": 660, "_totalAccumulated": 0, "_lastSecAccumulated": 0, "_lastSecTime": 0, "_lastSecValueCount": 660 } frameTimeCounter { "_startMonitoringTime": 47999.685000000005, "_min": 0, "_max": 2674.9200000000055, "_average": 28.738333333333202, "_lastSecAverage": 6.943367346938894, "_current": 6.405000000006112, "_totalValueCount": 162, "_totalAccumulated": 4655.609999999979, "_lastSecAccumulated": 229.41500000000087, "_lastSecTime": 47396.780000000006, "_lastSecValueCount": 31 } engine.gpuFrameTimeCounter { "_startMonitoringTime": 0, "_min": 0, "_max": 2800898000, "_average": 14517034.810126582, "_lastSecAverage": 4680863.636363637, "_current": 4774000, "_totalValueCount": 316, "_totalAccumulated": 4587383000, "_lastSecAccumulated": 45263000, "_lastSecTime": 85156.96, "_lastSecValueCount": 10 } engine.shaderCompilationTimeCounter { "_startMonitoringTime": 73101.945, "_min": 0, "_max": 60.06500000000233, "_average": 12.432499999999386, "_lastSecAverage": 15.997708333332412, "_current": 15.690000000002328, "_totalValueCount": 36, "_totalAccumulated": 447.5699999999779, "_lastSecAccumulated": 0, "_lastSecTime": 73117.63500000001, "_lastSecValueCount": 0 } // these lodash methods if you're not familiar with the library, are just calling the properties/methods and grouping by the count of the results _.groupBy(_.map(play_game.scene.babylon.meshes, 'isWorldMatrixFrozen')) Object {false: Array[430], true: Array[1395]} _.groupBy(_.invokeMap(play_game.scene.babylon.meshes, 'isEnabled')) Object {true: Array[487], false: Array[1345]} _.groupBy(_.map(play_game.scene.babylon.meshes, 'areNormalsFrozen')) Object {false: Array[1263], undefined: Array[576]} _.groupBy(_.map(_.compact(play_game.scene.babylon._activeMeshes.data), 'areNormalsFrozen')) Object {false: Array[91], undefined: Array[143]} play_game.scene.babylon._activeMeshes.data.length 256 _.filter(play_game.scene.babylon._activeMeshes.data, _.isUndefined).length 23 // (note: ^, is this a problem that there are 23 undefined values in _activeMeshes.data?) _.groupBy(_.invokeMap(_.compact(play_game.scene.babylon._activeMeshes.data), 'getClassName')); Object {Mesh: Array[91], InstancedMesh: Array[143]} _.groupBy(_.invokeMap(_.compact(play_game.scene.babylon.meshes), 'getClassName')) Object {Mesh: Array[1263], InstancedMesh: Array[576]} play_game.scene.babylon.materials.length 690 Object {ShaderMaterial: Array[7], GradientMaterial: Array[1], StandardMaterial: Array[682], PBRMaterial: Array[2]} _.groupBy(play_game.scene.babylon.materials, 'isFrozen') Object {false: Array[692]} // ^ this freeze / isFrozen on materials option, I've just recently seen in docs, is this new and or could this be related? Was it auto freezing in the past or something like that?