• Content count

  • Joined

  • Last visited

About thrice

  • Rank
    Advanced Member

Contact Methods

  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. -- 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 ) , 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.
  3. 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 ))
  4. 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
  5. 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.
  6. 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. 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.
  7. 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, 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:, 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.
  8. 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
  9. 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...
  10. 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)
  11. 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.
  12. 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.
  13. I can give the update a try tomorrow if the nightly is what triggers the npm build (so whenever fix is pushed to npm)
  14. 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?
  15. Right, but I am not referencing in my project at all, and still seeing the performance issue. Fingers crossed