thrice

Members
  • Content Count

    103
  • Joined

  • Last visited

Everything posted by thrice

  1. Wondering if anyone has an example of using a spritesheet or texture atlas with instance meshes, or if this could be added to the roadmap as it seems like a pretty core/important feature? (Or if it isn't possible?) I've been having to do some pretty awful things in an attempt to work around the lack of support for that. Currently all the examples of using a atlas/sheet that I've seen, do not work with instanced meshes, since when you createInstance on a mesh, it is using/must use the same material. So if you modify the (uOffset, vOffset, uScale, vScale), you are mutating the texture itself. - So I didn't think it was possible, but then I saw this post: So I thought maybe it was possible. However it looks like if you setVerticesData of an instanced mesh, it mutates the source, playground below for example. https://www.babylonjs-playground.com/#IZACWJ#6 So is it even possible to have instanced meshes with different verticesData to benefit from the merged draw calls or not? --- ALSO: Does anyone happen to know if the math changed on setVerticesData calculations after babylon 2.3? I've copied code from the babylon-atlas library, but it's returning the wrong frame, and it's upside down (and the frame data is in the correct format). So hoping maybe just a simple change to get it working, but math is hard. https://github.com/andyhall/babylon-atlas/blob/master/index.js#L198
  2. Conceptually, it's starting to make more sense after looking into the source code.I need to read more about shader attributes as I don't think I really understood what they were doing until this point.
  3. The situation is this: While attempting to improve performance by doing some ugly things with sprites, which use onAfterWorldMatrixUpdatedObservable, hook, I noticed an issue in my scene: Basically: I have one main board mesh which almost everything minus player hands are parented to (not directly, but each player has a board which is parented to the main board mesh, etc). -- The issue is, when I parent a mesh to the board, and I add an onAfterWorldMatrixUpdatedObservable hook, it is getting called every single frame. -- Which leads me to believe that possibly every object which is part of the main board mesh descendants tree, is also having their world matrices updated on every frame,which could obviously hopefully account for some of the performance issues that I've been having. (The same mesh, unparented, does not have onAfterWorldMatrixUpdated being called each frame.) I browsed the codebase, but didn't see anything obvious which could be causing this behavior. So I am wondering if anyone knows of any gotchas or non obvious places or things that could be causing the worldMatrix update. -- I can likely solve it by recursively freezingWorldMatrix of all the children, however I would like to figure out what is going on as well.
  4. Thanks delta, -- that is mostly what I thought. I am seeing different behavior, it is firing the onWorldMatrixUpdated on every frame for all of it's non worldMatrixFrozen children, when none of those things should be changing. - I am stuck on version 3.1.alpha5 ATM, so if there were any bugs with anything ^ which were fixed after 3.1.alpha5 that could be helpful to know, but I'll dig into the issue further.
  5. -- That said ^, I still think it would be really useful to have built in to the framework if it's possible, as an StandardInstancedMaterial or InstancedAtlasMaterial or something like that. Reasons being: I tried using sprite manager, but aside from the fact that I couldn't use it anywhere where I wanted a non billboard mode mesh (which is probably 75% of the draw calls in my scene, i.e. cards which need to be able to rotate), there were too many issues. Different (worse) rendering quality when sprites are far from camera, having to track parent/position manually with onWorldMatrixUpdated, translating parent size to scaling which is a hack in itself, etc. But the main dealbreaker /reason I can't use it at all, in most places in my scene, is because of lack of rotation. If there was a InstancedAtlasMaterial or whatever, it would be hugely beneficial as not only could my draw calls be reduced by a huge amount (I would estimate my on average 100 draw calls I could cut in half easily, and that's without caching what would be really large textures like my card images at all). But the biggest benefit would be having a consistent API to work with, i.e. not having to use a different mechanism entirely (i.e. SpriteManager, or gui texture), to optimize things. also almost all of the examples I've seen people post of using Atlases/sprites with meshes (i.e. this library https://github.com/andyhall/babylon-atlas ) , seem fairly pointless to me (at least for a great many use cases, without something like ^), unless I am missing something. At least from my limited experience, drawCalls (in general), seem like the #1 key performance indicator for optimizing speed, and when using a library like the one above, there is a good chance you can end up with the same number of drawCalls, since you end up having to create a new mesh (or clone) for each use of the texture. (Which in almost all of my use cases, creating an instanced mesh with a new texture instead of an atlas, saves me way more draw calls than I would by using the atlas). -- Granted that's not taking into consideration complexity of the mesh being rendered, but in my scene 95% of my meshes are planes, and I haven't seen nearly the performance boosts from using clone+atlas compared to createInstance+nonAtlasTexture -- But point is, having support for this would allow for best of both world / total draw call annihilation.
  6. Hi Delta -- it makes sense in theory, however I am unsure how I would go about implementing/ tracking that. If I'm understanding correctly: You are saying to use one shader material, shared by many instances. In that case, how would I let instance 1 know to use uOffset X and instance 2 use uOffset Y, for example? Because if I'm using a shader material, and I say for example, material.setVector2('uvOffset', new BABYLON.Vector2(1,1)) or whatever, then I'm still going to end up modifying the shader material on all instances. Unless I am missing something? (also, figured out the setVerticesData, I didn't copy over a false param from the constructor of texture as in library to invert it because I had no idea what it was doing (would love more named param constructors i.e. mesh builder style in future ))
  7. I'm using it in two angular projects, one angular 5, one angular1. Def not angular problem, however could be related to canvas size as stated above. One other thing to check is scene.getEngine().getHardwareScalingLevel(). 1 is the default, anything < 1 = higher quality, anything > 1 = lower quality I would also take the postprocess out of the equation for now as well
  8. 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.
  9. 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?
  10. 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
  11. 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...
  12. 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)
  13. 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.
  14. 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.
  15. I can give the update a try tomorrow if the nightly is what triggers the npm build (so whenever fix is pushed to npm)
  16. 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?
  17. Right, but I am not referencing in my project at all, and still seeing the performance issue. Fingers crossed
  18. 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.)
  19. @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).
  20. 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 ?
  21. On the sponza scene? sure. https://www.dropbox.com/s/ge6mc8olk4nsly8/sponza_lte_10fps_Profile-20171218T145557?dl=1
  22. 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
  23. 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.
  24. 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.
  25. 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