• Content count

  • Joined

  • Last visited

1 Follower

About inteja

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. @Nodragem yes it's only a basic boilerplate to get node.js, babylon, colyseus and related dependencies setup for multi-player. A decent starting point for any multi-player 3D game. The rest is up to you. On the Colyseus site and Github repositories there's various examples showing how to use Colyseus for multiplayer games and chat, but none of these use Babylon at present. I'm sure @endel would welcome pull requests to the BabylonJS + Colyseus Multiplayer Boilerplate if anyone wanted to flesh it out more to say a simple game of tic tac toe or checkers or something.
  2. Switched from default preview to cdn (stable) inspector: BABYLON.DebugLayer.InspectorURL = ''; That worked. Thanks @Deltakosh
  3. Arghhh .... I should have just RTFM ... I see now in docs that preview version of inspector is loaded by default from Sorry I should have seen this before. Will try that.
  4. Hi @Deltakosh . I'm a bit confused. How could the inspector version be misaligned?
  5. The issues I'm experiencing locally don't seem to be evident in the playground with either stable 3.2.0 or 3.3.0 alpha 12 Could be something to do with my local environment or codebase ... but strange though. Not critical as I can easily do without this inspector functionality but I just thought it worth reporting.
  6. @Deltakosh I'm using latest stable babylonjs 3.2.0 npm package
  7. Locally I am getting the following error when trying to change any individual material's properties (e.g. switch a material to wireframe etc) in the inspector. Another example is say changing the alpha fraction - I can input the new value but pressing enter results in the same error and nothing happens and the alpha text input box doesn't disappear. babylon.inspector.bundle.js:2 Uncaught TypeError: Cannot read property 'notifyObservers' of undefined at n.set [as value] (babylon.inspector.bundle.js:2) at n.validateInput (babylon.inspector.bundle.js:2) at n._validateInput (babylon.inspector.bundle.js:2) This functionality seems to work fine in the playground and changing global scene properties (e.g. wireframe rendering) in my local environment also works fine.
  8. Thanks @Deltakosh Good information to know.
  9. inteja

    I see dea...through mesh, i wan't

    If I understand correctly, take a look at Camera.minZ Here's another thread/post I found that describes how it works
  10. Thanks @dbawel Yes my experimentation and questions above were prompted by that post - it inspired me to try out a few different approaches including what you've suggested. My current project has a pretty deep structure and it's not that convenient to apply all assets in the one loader.onFinish() call at the same time. My application is more dynamic than that, which is why I was curious about whether my approach of passing an array of assets around makes any sense given it seems like I could just do new BABYLON.Texture(path, scene) at any point in time after all assets have been loaded and in theory it shouldn't impact memory usage or performance ... maybe.
  11. Another related question 🙂 If I load a .babylon of .gltf model using the AssetsManager, does the AssetsManager consider the asset fully loaded when that file is loaded or when that file and all textures etc referenced by that file are loaded?
  12. On the particles 101 doc page there's an embedded PG which uses a nice steam/smoke sprite sheet texture from PatrickRyanMS's github repo. I was just wanting to know if it's OK to use this texture. I couldn't find any contact details on Patrick's github profile to ask him and not sure if he's active in this forum. Looks like he works for MS so maybe someone here knows him @Deltakosh @davrous?
  13. I read in another thread that BabylonJS intelligently handles multiple uses of the one texture for optimal performance i.e. internally if the texture path is the same then no extra vram is used for subsequent new textures with the same path. I suspect I've been overcomplicating things up until now but here's some related questions. Question 1 If I load my textures with AssetsManager like so: var textureTask = assetsManager.addTextureTask("my-texture", "./path/to/my-texture.jpg"); Are the following methods of applying the textures equivalent behind the scenes (i.e. neither uses more VRAM)? // Method 1 textureTask.onSuccess = function(task) { material.diffuseTexture = task.texture; } // Method 2 - elsewhere in application after assetsManager.onFinish() has been called. material.diffuseTexture = new BABYLON.Texture("./path/to/my-texture.jpg", scene); Question 2 What I've been doing up until now is assigning loaded assets to an assets array which I then pass around to various objects to use what they need like so: textureTask.onSuccess = function(task) { assets[] = task.texture; } // Stuff ... var myCustomObject = new CustomObject(assets); // In CustomObject ... material.diffuseTexture = assets["my-texture"].clone(); The reason for the .clone() is when I need different uv scale and offset per instance. If my method 1 and 2 are functionally equivalent and don't result in any additional vram usage or performance hit then I'm wasting my time passing around an array of loaded assets when I could simply instantiate a new texture with the same path that I know has already been loaded by AssetsManager. Can anyone shed some light on this? How do other people manage this efficiently?
  14. inteja

    Gizmo's and mesh dragging behaviors

    Looks awesome! Does this work with children & groups e.g. TransformNode, or just Mesh?