• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    ShiftedClock reacted to JohnK in [Solved] How would you display a message? Is CastorGUI still recommended?   
    CastorGUI is still available or you can use HTML and CSS or you could checkout Babylon.GUI
  2. Like
    ShiftedClock reacted to Gijs in [Solved] How to make UniversalCamera rotate without mouse down?   
    Hi, you can set
    engine.isPointerLock = true;  
  3. Sad
    ShiftedClock reacted to Deltakosh in ActionManager not firing OnKeyDownTrigger   
    Well this is expected actually  if you provide a context, this is a signal for babylon.js that there is already something working on the webgl context and we are a plugin (this is how the integration in PowerPoint works for instance)
    So in this case, the footprint is minimal as we do not own the canvas (so no event hooking etc..). i will mention that in the code comments
    Thanks a lot for your feedback!
  4. Like
    ShiftedClock reacted to Deltakosh in ActionManager not firing OnKeyDownTrigger   
    I updated the code comments to follow your idea:)
  5. Like
    ShiftedClock got a reaction from Wingnut in ActionManager not firing OnKeyDownTrigger   
    Alright, I figured out the problem. This has been one of the most intense multi-day debug sessions I've had in years.
    After littering babylon.max.js with console.log statements, I narrowed it down to the fact that Engine._onCanvasFocus wasn't firing, while manually adding an event listener to the canvas focus event worked fine.
    Then I noticed, that code was wrapped in a check for canvasOrContext.getContext. Ding ding ding. Winner winner, chicken dinner, as the kids say.
    The problem was with this part of my code:
    let canvas = <HTMLCanvasElement> document.getElementById("canvas2"); let gl = <WebGLRenderingContext> canvas.getContext("webgl"); let engine = new BABYLON.Engine(gl, true, {"preserveDrawingBuffer": true}); I had assumed that since the Engine's constructor took either a canvas or a context, that it would work fine with either.
    But WebGLRenderingContext doesn't have a .getContext property!
    I'm not sure if this is intended behavior, but the result is that the check for canvasOrContext.getContext silently fails (babylon.max.js line 11393, sorry, don't have the typescript line number).
    Since that fails, much of the following option and Observable setup fails. The else part of "if (canvasOrContext.getContext)" is simply missing all of the setup code.
    So, I think I discovered a bug in the engine? Or at least unintended behavior. I don't have the time or inclination to make the fixes and submit a pull request (this is my first week with Babylon afterall), but I hope someone can.
    For now I've switched back to passing canvas to the engine constructor, and everything works as expected.
    Side note: Having Scene.attachControl and Camera.attachControl have the same method name, while doing very different things, was a source of confusion for me.
    Edit: This may be intended behavior, just undocumented. It's very unintuitive that Observables aren't properly setup when passing a WeblGLRenderingContext to Engine, while HTMLCanvasElement works fine. The fact that you can't addEventListener on WebGL contexts is probably the source of that difference.
    A reasonable compromise would just be mentioning in the documentation that initializing Engine with a WebGlRenderingContext prevents (some?) Observables from being setup.
    Edit2: Apparently you can get the canvas from the context, so event listeners could still be setup, so long as the canvas is not null.
  6. Like
    ShiftedClock got a reaction from Wingnut in ActionManager not firing OnKeyDownTrigger   
    Good to know, thanks. Hopefully if/when someone runs into the same situation, something is there to say "Observables are not registered when using a WebGLRenderingContext." Either in documentation, code comments, or console warnings. Anything but failing silently with no indication as to why the Observables aren't being set up.
  7. Thanks
    ShiftedClock reacted to Pryme8 in Make a Perfect Plane to Fit Frustum   
    So, I can definitely figure this math out but I was looking to see if there is a quick trick anyone can think of to make a plane fit exactly into the camera's frustum.

    IE if I have a camera at (0,0,-10) and a view port that is 1:1 or even 1:1.5 ratio what size would a plane need to be to cover the whole viewport...  (I know I know simple math), I was hoping for a quick method if anyone has one though, no rush its not anything I actively need but would be useful for a side projects I am doing.

    Basically what ShaderToy is doing.

    Ill prolly just use this
  8. Like
    ShiftedClock reacted to jerome in Make a Perfect Plane to Fit Frustum   
    well, assuming that d is the distance from the camera to your plane, fov the camera fov angle and y the plane half height (and assuming that the frustum cam.minZ is still 1), then
    y = d * tan(fov / 2)
    and if x the half the plane width
    x = y * camera.aspectRatio
    if I remember well
  9. Like
    ShiftedClock reacted to jerome in Make a Perfect Plane to Fit Frustum   
    some little fixes imho :
  10. Like
    ShiftedClock reacted to brianzinn in Recommended way to get time between last frames in Observables? (i.e. deltaTime)   
    Unlike some other platforms - BabylonJS is very UNopinionated.  The Entity Component System of Unity follows a common design pattern of "has a" - instead of "is a" of traditional object oriented design, which is really nice for avoiding complex inheritance hierarchies.  Composition over inheritance has a lot of benefits in many situations.
    BabylonJS Animations can attach to anything even a plain javascript object and animate any property. That's really the beauty of the dynamic languages and as you know also with dynamic shader compilation
    There is one relatively new part of BabylonJS that does follow your idea of composing behaviours, so hopefully this provides some good ideas/code, too:
    Attaching a gizmo to a mesh is one example.  You can attach() and detach() them on the fly even to cameras
  11. Thanks
    ShiftedClock reacted to brianzinn in Recommended way to get time between last frames in Observables? (i.e. deltaTime)   
    There is definitely a learning curve with new engines - For me the best part is when something is new and there is a lot of learning!  There are some built-in animations and not sure how far along that will take you.  What kind of game are you building?
    One thing about delta time only is that for Easing/(s)lerp the deltaTime is not enough - maybe you store your progress or have constant animations where that is obviously not an issue.

    Here is a simple PG on position.x (like your behaviour) with built-in animations.
    There are some other tricks too - everything is well documented:
  12. Thanks
    ShiftedClock reacted to brianzinn in Recommended way to get time between last frames in Observables? (i.e. deltaTime)   
    Welcome to the forum!.  deltaTime is available on the engine:
    scene.getEngine().getDeltaTime() I've never needed to go to this level for animations.  Can you share your animation code as a playground?  I have multiple smooth animations running simultaneously without any low level coding, but not sure what you are animating.
  13. Like
    ShiftedClock got a reaction from brianzinn in Recommended way to get time between last frames in Observables? (i.e. deltaTime)   
    Thank you so much. I'm just animating properties of objects, like so, in createSphere.js:
    let sphere = new BABYLON.MeshBuilder.CreateSphere("sphere", {diameter: 2}, scene); sphere.Behaviours = []; // Shoehorning the Behaviours array onto the Mesh object. sphere.Behaviours.push(function(deltaTime) { this.position.x += 0.001 * deltaTime; }.bind(sphere)); // Insert more "Behaviours" here, from a central file. sphere.Update = function (scene) { let deltaTime = engine.getDeltaTime(); for (let i=0; i<sphere.Behaviours.length; i++) { sphere.Behaviours[i](deltaTime); } }.bind(sphere); Later in the scene's initialization, the gameObjects are loaded and their Behaviours registered:
    let sphere = createSphere(scene); scene.gameObjects.push(sphere); for (let i=0; i<scene.gameObjects.length; i++) { let go = scene.gameObjects[i]; scene.onBeforeRenderObservable.add(go.Update); } I'm trying to create something like an Entity Component System, so that I can compose GameObjects from Behaviours, and in turn compose scenes from those GameObjects.
    This project has an emphasis on smooth animations, defined in code. I'm rendering everything in a shader using raymarching (i.e. meshes are for physics, not drawing), and just using the game engine to keep track of the game world. Every frame the game Updates, then sets shader variables using gl.uniform1f, etc.
    I come from Unity (with some Phaser, CreateJS, and Love2D experience), so learning a new engine is always a process of "Out of the techniques I've learned over the years, which ones fit how this engine works? Do I have to define my own game loop? Is there a built-in Entity Component System? Or do they do things in a completely new way to me?"  I'm very open to learning new ways, but the initial learning can be cumbersome.
    Does Babylon have a preferred way of creating GameObjects in an Entity Component style? Or even a place to store them in the scene objects? Or am I approaching things the wrong way for Babylon? I may be trying to fit the ECS pattern to an engine that doesn't want it, for instance.
    Since I started using scene.getEngine().getDeltaTime() the stuttering has gone away. It's a joy to work with again, thanks Brian.