• Content count

  • Joined

  • Last visited

Everything posted by thrice

  1. 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?
  2. 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.
  3. 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.
  4. 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
  5. @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
  6. 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 (23 versus 11) So, this furthers my belief that some change in the library itself is causing the slower performance. _.groupBy(, 'isWorldMatrixFrozen')) Object {false: Array[466], true: Array[1443]} _.groupBy(_.invokeMap(play_game.scene.babylon.meshes, 'isEnabled')) Object {true: Array[616], false: Array[1293]} _.groupBy(, 'areNormalsFrozen')) Object {false: Array[1313], undefined: Array[596]} _.groupBy(, 'areNormalsFrozen')) Object {false: Array[91], undefined: Array[154]} 256 _.filter(, _.isUndefined).length 11 _.groupBy(_.invokeMap(_.compact(, '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]}
  7. 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)
  8. 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
  9. 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
  10. Also here is screenshot of profile, all I did was pointer over a few cards to trigger hover states
  11. @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(, 'isWorldMatrixFrozen')) Object {false: Array[430], true: Array[1395]} _.groupBy(_.invokeMap(play_game.scene.babylon.meshes, 'isEnabled')) Object {true: Array[487], false: Array[1345]} _.groupBy(, 'areNormalsFrozen')) Object {false: Array[1263], undefined: Array[576]} _.groupBy(, 'areNormalsFrozen')) Object {false: Array[91], undefined: Array[143]} 256 _.filter(, _.isUndefined).length 23 // (note: ^, is this a problem that there are 23 undefined values in _.groupBy(_.invokeMap(_.compact(, '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?
  12. @aWeirdo Thanks for reproducing! @Sebavan and thanks for fix
  13. Hey Delta! I'll try and dig into it again this weekend. Unfortunately I can't just run it without electron ATM because of the way I am loading assets (via the node process) - Ya I wasn't expecting you to be able to reproduce the getQuery issue was more hoping someone knew what it meant, or possibly what it could allude to in terms of the code itself. I will get a profile if I can't figure out what is going on. Honestly the bigger issue is the fact that my go to tool for figuring out what is going on(simply, engine.drawCalls), has been removed, and I am unable to load any of the new instrumentation stuff currently, so I can't even see if my current draw calls matches bumped version draw calls. I had a similar issue in the past IIRC, which I saw the drawCalls spiking after upgrading, so I was able to determine that a large number of the meshes that I load off screen and disable (for the sake of tooltips/hover states), were being loaded in at 0,0,0, which was being covered up, so basically the camera was trying to render hundreds more meshes than it should have been. - The reason I think it may be different this time is the strange webgl error, but IDK. Will try and debug it further when I have time.
  14. If however, I add the highlight layer after the scene is going, it won't add the initial draw calls initially. - Additionally, the dispose behavior I cited in the issue is still causing it to trigger, however it does seem semi sporadic, i.e. sometimes the first dispose call after adding the highlight layer triggers the additional draw calls, sometimes it takes a couple disposals. - BUT the important thing to note about all this is: As soon as the additional draw calls are triggered by the 1-2 tries of disposing meshes, even though only 1-2 meshes are being disposed, the draw calls are spiking from 110 to 210ish, everytime, consistently (regardless of the number of meshes destroyed). I.E. there are a bunch of invalid mesh references in the above screenshot, but if Iazy load the highlight layer and trigger the issue, it will look fairly correct, though there will still be an entry for the last disposed mesh. Since I am unable to reproduce on playground, please see my console logging of the behavior below: (the play_game.highlight_manager.rebuildHighlights() method is creating the highlight layer initially). Also note, clearly I have an issue with the mesh id property on the destroyed mesh, but don't think it's related. Also note: both meshes I disposed in this session are either instances or clones. The behavior doesn't appear to be specific to one or the other either, just sometimes takes a couple of disposals before I see the increased draw calls
  15. BabylonJS Editor Toolkit - Version 3.1 Alpha

    Looks pretty cool! Will this export shaders then? Also, is it easy enough to pick stuff out of the exported content? i.e., I really mainly would only likely use a tool like this to export materials/shaders. Is it possible to export shaders bought from the unity store, pick them out of the code and bring into project? Because that would be epic. Been converting shaders by hand and it's a huge pain, and I don't even know where to start with the HSGL or whatever shader format the unity ones are in, in terms of converting.
  16. I'm using chromium, app is packaged via electron. So, I can't switch to a diff browser to run it ATM to see if I get different results/debug. I'm going to downgrade back to previous version for now.
  17. Trying to load the debug layer is now throwing
  18. Ah, thanks for the draw call info. I will look into it further.
  19. I'm well aware, I'm simply trying to help out and narrow down what could have changed between versions to cause issues in my project locally.
  20. @Arte Don't click this if you have epilepsy (really), but: any example of passing variables to the shader to use as a discard threshold. A more practical example on cyos I was working on, I was trying to get a decent looking 2d smoke plane shader working, almost looks decent but not quite: Point is, I would imagine there is some way to pass the dimension of the sphere in the scene to the shader, and use the discard keyword to cutout the pixels that are not relevant. Whether by redrawing the sphere via the dimension in GSGL, or to recreate the area you want to discard, or what not. Although I'm barely able to understand building 2d shaders at this point, so I'm just the idea guy. I still haven't fully grasped the vertex shader side of things yet, and I'd imagine that would somehow be important as that seems to manipulate the shape. Also it looks like discard doesn't work w/ vertex shader, so IDK.
  21. Sorry for the title but I can't think of a better way to explain what is happening. Basically it's like there is some gravitational force on the left side of my screen, which is causing CERTAIN mesh calculations to appear incorrectly. I.E., my planes show up at the right place on screen, hover trigger actions fire as the mesh is entered by the mouse at the correct position. What isn't working is: renderOutline = true, along with children action planes which I dynamically display when the mesh is hovered on -- And as far as I can tell, whatever is causing renderOutline=true to show incorrectly, seems to be the same thing affecting the hovers. (also, dynamicEdgesRendering works fine, but render outline does not?) Much easier to show via screenshots: ^ Each card on board with renderOutline = true As you can see, as the meshes get closer to the left side of the screen, the further left the outline is pulled. ^ With enableEdgesRendering = true , calculation seems perfect here And finally, the dilemma. These are the hover planes I was talking about. Basically, when a card is hovered on, I pull out a plane which is parented to the card_on_board_plane, x_offset = card_on_board_plane.width - 0.5 (because I need to track when the actions plane is hovered on to keep it open, so it SHOULD be showing up just before the right edge of the plane) - So card #3 in the picture is unable to have its actions activated But the problem seems to apply to my scene as a while, i.e. - each card has a hover state (as you can see in last picture as well) - But even if I hover on a card which is in the players hand (I pull the hover states left of the absolute position of the card being hovered on), and that card is on the left side of the screen, the hover state gets pulled further left than if I hover on the right side of the screen. Given that renderOutline seems to be exposing the underlying issue (and enableEdgesRendering is showing dimensions being calculated perfectly), whatever it may be, I'm hoping there is a simple explanation for what I am seeing, or something dumb I am doing that is causing it. Anyone have any idea?'
  22. Transparency in Babylon gUI?

    Containers/controls have an alpha value you can set to < 1 for transparency