• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    thrice got a reaction from V!nc3r in 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.
  2. Like
    thrice got a reaction from Deltakosh in Huge performance hit after upgrading from 3.1.0-alpha3.5 to 3.1.0-alpha3.7   
    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
  3. Like
    thrice got a reaction from JackFalcon in Huge performance hit after upgrading from 3.1.0-alpha3.5 to 3.1.0-alpha3.7   
    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?
  4. Like
    thrice got a reaction from Arte in Boolean operations with meshes in a shader   
    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.
  5. Thanks
    thrice got a reaction from Borislav in Transparency in Babylon gUI?   
    Containers/controls have an alpha value you can set to < 1 for transparency
  6. Like
    thrice got a reaction from Wingnut in Issue with GUI control / attaching to mesh / click through   
    Nice! I think I need to familiarize myself with stack panel,, thought it was only part of the full screen api - that could simplify some of my code I think. however: the original objective I was trying to accomplish remains - Basically, in your example, it would be the equivalent of being able to click through to the plane, in the small portion of the stack panels that overlaps the plane behind it, that does not have a stack panel button in that space.
    But ya, I have it working the slightly more complicated way so not the end of the world, and design wise probably not the best UI doing it that way, but would have worked in this instance just because the buttons themselves aren't very tall so it's easy to click the plane behind it while hovered.
    P.S. Overflow handling/scrollbar would be amazing btw! Just throwing that out there @Deltakosh  
  7. Like
    thrice reacted to Wingnut in Issue with GUI control / attaching to mesh / click through
    Not complete yet.  Action manager on center cardPlane is not toggling .isVisible on the two stack panels (lines 43-65).
    It's ok... because 43-65 probably needs changing.  No need to toggle gui stackpanel .isVisible... because we should probably be toggling keysPlane and menuPlane .setEnabled(true/false).  Then the menuPlane and keysPlane will appear/disappear along with the gui they contain.  Wiser.  Next version.
    Good thing seen on console.  The parts of the green buttons... that are overlapping cardPlane, are NOT passing their clicks "thru" to the cardPlane's actionManager.
    I think this is on-objective.  By putting these two stackPanels on their own planes (keysPlane and menuPlane), we don't NEED to set their .isPickable to false.  The clicks on the buttons (portions that overlap cardPlane) are not clicking-thru to cardPlane.actionManager.  Yay!  So far, so good, I guess. 
    I need to remove the verticalAlignment crap from createButton, or do something different.  I want each added button to stack-from-center, like DK's stackPanel demo from the Babylon.GUI docs... stackPanel section.  In that demo, no verticalAlignment is set... so the added controls center-stack automatically.  More versions coming soon.  Anyone is free to jump-in and do tests, and make more PG saves. 
    Update: [link]  Click central cardPlane to toggle both stackPanel .isVisible... working well now.  But menuPlane and keysPlane remain visible, so I will be changing to mesh.setEnabled method... next.
    Update2: [link]  Click cardPlane now sets keysPlane and menuPlane disabled.  Works great.  But clicking cardPlane AGAIN.... should re-enable the two side-planes... and it doesn't, so far.  hmm.  SimpleButtons seem to have altered their verticalAlignment, too.  Not sure why... I didn't work-on that part yet. 
    Update3: [link]  There we go.  I needed ._isEnabled  (in lines 50 and 58).  I forgot the underscore.    Next-up, add 20 keywords and menu buttons, and make overflow-handling and scrolling-arrows for each side-plane, and and and... *sigh* 
  8. Like
    thrice reacted to jerome in SPS experiments   
    People usually love the Solid Particle System (aka SPS). Some of them sometimes ask for new features like the ability to extend it once created (coming soon) or for some extra speed by the ability to disable some computations.
    I made some study about how things could get faster. The short answer is : go to a lower lever in the implementation (replace the arrays of objects by typed arrays of floats, for instance), then use if possible other processes (GPU or workers).
    Well, here are the current status of my prototypes, so you can compare on your computer and browser the differences.
    The SPS of reference is really big, filled with 40K (yes, 40, 000 !) boxes and tetrahedrons. It's far more than we usually ask to a SPS with animated solid particles in the PG examples you could find in the forum posts. So your browser may suffer a bit ...
    Reference legacy SPS :
    Then comes the lighter typed array based version : 
    As you can notice, it's a bit faster. Not only because of the usage of buffers/typed arrays, but also because it has less features than the legacy SPS for now.
    Let's go on...
    [EDIT] (from here, your need to have a browser with sharedArrayBuffer enabled)
    Here comes his new friend, the worker based SPS :
    This one is really faster. In this version, the particle logic (what the user want them to do) is still in the main thread and the worker only computes the transformations (the final vertex coordinates from the particle rotations, positions, scaling values, etc).
    At last, here's the second worker version :
    It looks faster ... at least on my browsers.
    In this last version, the particle logic is deported in the worker. The main thread only carries for updating the mesh from the vertex buffers.
    In both worker versions, the worker computations are decoupled from the render loop. This means that the worker computes, then answers the main thread it has finished and this one just orders it to compute again, whatever the render loop is currently doing at this moment. The render loop just reads the data currently updated by the worker in a shared buffer (shared between the worker and the main thread)
    Next study step to come (not soon) : the GPU based SPS
    Please wait for a while until the frame counter stabilizes to the current average value if you run the tests.
  9. Like
    thrice got a reaction from Deltakosh in Bump Map throwing strange WebGL errors in my project   
    Looks like upgrading to babylonjs@3.0.4-beta fixed it
  10. Like
    thrice got a reaction from Dad72 in Extreme FPS dropoff after upgrading to 3.0 alpha   
    @Deltakosh I think the issue is more related to how the lib is structured, i.e. with the whole separation of the preview_release directory, and it having the latest version of the compiled code. I think it may make more sense to have the master branch contain the latest version, and when there is a stable release done, then there is just a branch/tag for the stable release.
    That way if someone wants to use master, they can just:
    yarn add
    Or if patches are made to stable and a build hasn't been released, and they want to point to the patched version with the fixes:
    yarn add
    (or npm equivalent)
    All of this of course is reliant upon having a package.json at the root of the repo as well
  11. Like
    thrice got a reaction from Deltakosh in cannot import BabylonJS 3.0 Canvas2D (ES6)   
    I was getting bit hard by this issue the other night, I eventually got it resolved by:
    1. Not exposing BABYLON on the window. It seems like when I was exposing babylon on the window in my webpack config, i.e.
    ` {test: /babylonjs\/babylon.js$/, loaders: ['expose?BABYLON']}`
    It was loading a different instance of the BABYLON library, from when I would
    `import BABYLON from 'babylon';`
    - It may have been related to the fact that I am building an angular-babylon wrapper, which I had partially abstracted into a package, which was including BABYLON as a dependency. - Or it was just, exposing BABYLON on the window was causing it to be duplicated, not 100% sure, but, here are some steps you can try to fix
    1. try removing expose if you are exposing BABYLON in your config, and add this instead:
            {test: /babylonjs\/babylon.js$/, loaders: ['exports?BABYLON']},
            {test: /babylonjs\/babylon.canvas2d.js$/, loaders: [ 'imports?BABYLON=babylonjs/babylon']},
    (the above is exposing the babylon library specifically to the canvas 2d lib, when it encounters the import "babylonjs/babylon.canvas2d" statement below)
    2.  make sure you are not exposing BABYLON on the window.
    3. I replaced all occurrences of
    ```import BABYLON from 'babylonjs';```
    ```import BABYLON from 'babylonjs/babylon';```
    (Not 100% sure the above is actually necessary, but burned entire night trying to fix and eventually got it working so didn't care to ask further questions)
    4. in your main js, or dependencies importing file, make sure to import babylon lib/Canvas2D once, i.e.
    import "babylonjs/babylon";
    import "babylonjs/babylon.canvas2d";
  12. Like
    thrice got a reaction from JohnK in Aligning a set of planes to another objects path/sides   
    Looks like that did it, except still suffering from upside down behavior (which ended up being easy fixed after backporting addRotation, as just needed to rotate z by Math.PI) - coolio
  13. Like
    thrice got a reaction from JohnK in Aligning a set of planes to another objects path/sides   
    Exactly what I was trying to do, thanks so much!
  14. Like
    thrice reacted to JohnK in Aligning a set of planes to another objects path/sides   
    Couldn't give a suggestion without trying it out to check it works
    It does in version 2.5
    but something has changed in latest version 3.0
    Did you know about this @jerome
  15. Like
    thrice reacted to hunts in Aligning a set of planes to another objects path/sides   
    @thrice check this out, click on the plane to make paths where you want the card to be positioned, you can make a "U" path by clicking at different point, wait for sometime the card will appear:
  16. Like
    thrice reacted to adam in Canvas2d, positioning rectangle at bottom left of tracked node   
    I'm currently working on a fix for this.