olrehm

Members
  • Content Count

    18
  • Joined

  • Last visited

About olrehm

  • Rank
    Member

Recent Profile Visitors

721 profile views
  1. Unfortunately I have little to reproduce: I have a custom build hexagonal grid with out-of-the-box cylinders on it. The camera is a TargetCamera. In 2.5 clicking on a cylinder picks it (using scene.pick) in the current preview release, it picks the hexagonal grid tile below. I stepped through the non-minified BabylonJS code a bit, and it seems it has nothing to do with isPickable, isVisible or isEnabled() - it is actually the intersection check that seems to have regressed: https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.scene.ts#L2872 Sorry for not providing a minimal test case. I have downgraded to 2.5 for now, but I thought you still might want to take a look, and maybe you already have a hunch of what might be causing it.
  2. I unblocked myself by just putting the binaries along with the package.json into a github repo and pointing npm to that: https://github.com/rehmsen/babylon.js.2.6pre Not ideal, but good enough until the next release is out.
  3. Any chance you could publish a tagged version of the prerelease? Something like npm publish --tag next I see you are asking for feedback on the preview release on the GitHub repo home page, and this would make it easy for people using npm to install it without breaking folks who are tracking latest. It would also fix my problem (at the cost of living on the bleeding edge, but that's okay). I tried to point npm directly to your Github repo to get the current master, but that only seems to work when you have the package.json at the root of the repo: https://github.com/npm/npm/issues/2974 Out of interest: Why do you have the package.json in the Tools/Npm subfolder. Wouldn't it be much simpler to maintain a single package.json at the root instead of two in Tools/Gulp and Tools/Npm?
  4. I think I may have my answer: That separate file is new (4 days ago): https://github.com/BabylonJS/Babylon.js/commit/af71269db7a6f909b92124d02a615831480134e6 So it was just not released yet. Great, then all I have to do is wait it seems. Do you have a release schedule?
  5. TL;DR: When I run gulp on a fork, a file babylon.module.d.ts is created which is the one I would like to use. However, when I `npm install babylonjs` there is only babylon.d.ts, not the module version. Any idea why? Long story: A few months later, I am revisiting this. My PR (https://github.com/BabylonJS/Babylon.js/commit/b9218551147d0225feac0548214491f35b4f78e1) was rolled back because it was breaking something else. The original problem is (if I am not mistaken): The js and d.ts files of Babylon.js as provided by npm are incompatible. The JS source needs to be loaded like so: var BABYLON = require('babylonjs'); The corresponding TypeScript import would be import * as BABYLON from 'babylonjs'; However, that does not work with the given d.ts because it is not a module but instead uses ambient namespaces. One can get the types correctly like so: import 'babylonjs'; Which compiles fine to require('babylonjs'); But the JS file does not put BABYLON into the global scope - it returns it from the require. As the files are, I cannot come up with a Typescript import statement that would do the right thing both for the types at compile time and for the JS source at runtime. I forked the repo and ran `cd Tools/Gulp`, `npm install` `gulp typescript-all`, and that makes a file dist/preview release/babylon.module.d.ts, which is the same as dist/preview release/babylon.d.ts except that it has the `export = BABYLON` line I need - however, that file is not part of the the npm package that I install, despite being listed here: https://github.com/BabylonJS/Babylon.js/blob/master/Tools/Npm/package.json#L27 Any idea why that would be?
  6. Thanks David! What is your current release schedule? It looks like the last release was in June... is there any way to get the nightly through NPM?
  7. Next try: https://github.com/BabylonJS/Babylon.js/pull/1372
  8. I see I have not read your answer carefully enough: You add this code to the JS files, not to the *.d.ts. That makes it possible to require babylon from JS, but my problem is that I cannot require it from Typescript, because the d.ts is not in module format. The d.ts would need to have a export = BABYLON; somewhere. I will close my pull request, and see if I cannot make another one where I add the addition to the d.ts file.
  9. Not sure I understand your Gulp setup completely, but it seems to me that we should add `.pipe(addModuleExports("BABYLON"))` here: https://github.com/BabylonJS/Babylon.js/blob/5442cc9aa0b14a71a957db129b43062eafa041e4/Tools/Gulp/gulpfile.js#L101 That at least results in gulp typescript outputting a d.ts file that has the module.exports you are talking about in it. I'll send you a pull request after dinner...
  10. I can see where you have a task like that in your Gulp file, but it does not seem to work: mkdir tmp && cd tmp npm i babylonjs cat node_modules/babylonjs/babylon.d.ts | grep module.exports Returns nothing. Nothing here either: https://github.com/BabylonJS/Babylon.js/blob/f6b36e2a1abeee1e0fde239a9b62b16736b62b56/dist/babylon.2.4.d.ts And only the gulp tasks here: https://github.com/BabylonJS/Babylon.js/search?utf8=✓&q=module.exports Are you sure this works?
  11. I know that you do - that is exactly the problem: You have a mixin which is not compatible with lib.d.ts and which you do not expose but still use for parameters in your API. So callers cannot cast their HTML elements to your mixin - and then their calling code fails to compile. That is why I suggest to either make your mixin compatible to lib.d.ts by making the things you add optional - I think this would be accurate in this case since you really do not know if these properties exist, and you do have code checking that before relying on it. The other option is to export your mixin. But that is the worse solution in my opinion.
  12. Hi, I am using BabylonJS from Typescript, and ran into the following problem: const canvas = $element.find('canvas')[0] as HTMLCanvasElement; const engine = new BABYLON.Engine(canvas, true); Fails to compile with the message error TS2345: Argument of type 'HTMLCanvasElement' is not assignable to parameter of type 'HTMLCanvasElement'. Property 'msRequestPointerLock' is missing in type 'HTMLCanvasElement'. My interpretation of this is that HTMLCanvasElement as defined in lib.d.ts does not have this property, and that I am casting to that definition of HTMLCanvasElement, while BABYLON.Engine expects the one defined in babylon.d.ts, which does have this property. The problem is that BabylonJS does not export its own mixin version of HTMLCanvasElement, so I cannot even cast to that to pass it into BABYLON.Engine. So I am left with casting to any: const canvas = $element.find('canvas')[0] as any; const engine = new BABYLON.Engine(canvas, true); Which works but is somewhat ugly. I wonder if it would not be possible and better for babylons mixin to be defined like this: interface HTMLCanvasElement { requestPointerLock(): void; msRequestPointerLock?(): void; mozRequestPointerLock?(): void; webkitRequestPointerLock?(): void; } Anyways the calling code seems to be trying through all vendor prefixes, so marking these optional sounds like it would actually more accurately describe the situation - and it would mean that the type is compatible with libxml.d.ts' version. Any concerns? Should I send a pull request? Cheers Ole
  13. Hi, I am trying to use the BabylonJS npm package from Typescript with browserify. These are the issues I run into: If I just `require('babylonjs/babylon')` without import, Typescript complains `error TS2304: Cannot find name 'require'.` If I use `import BABYLON = require('babylonjs/babylon')` or `import BABYLON from 'babylonjs/babylon'` I get `error TS2306: File '/home/olrehm/Code/civ.ts/node_modules/babylonjs/babylon.d.ts' is not a module.` If I do not require at all, but use tsconfig.json or `/// <reference path="..." />` to pull in the babylon.d.ts, Typescript happily compiles, but I am missing any module loading statement for browserify to pull in the source I managed to somewhat make it work by adding `export = BABYLON;` to the end of babylon.d.ts making it a module and then import...from it. But of course I would rather not have to change this file that is installed through npm. I could also maybe make it work by passing babylonjs as "external" to browserify, to ensure that it is loaded though not required, but that means I need to write the dependency on Babylon into my gulp files, where I would much rather keep that information in my package.json. How are others doing that? I guess adding module: 'commonjs' to BabylonJS' gulp files would create a module that one can import/require - would that break some other approach? Ole
  14. Wouldn't it make sense to keep such 'polyfills' in a separate file, so that they can be included or excluded from the build depending on the typescript version used?