This is TypeScript code and I am trying to pass object of type Scene, but it requires BABYLONJS.Scene, whats the difference between them?
When should I use the static members from BABYLONJS.* and when should I instantiate objects of these types? I expect to work in a consistent way.
This issue occurs with many objects. I do not want to always use as any to handle this case, this breaks TypeScript, makes it pointless, right?
Hi StanislavChankov,
You are correct that using as any dramatically reduces the benefit of using TypeScript by essentially telling the compiler to ignore any type errors it thinks it encounters. The error you’re encountering is most likely coming from syntax that isn’t really on the line where the red underline is; that’s just where the compiler can detect something it doesn’t understand. Without seeing more of the code, it’s difficult to say for certain, but I suspect that this error is simply caused by TypeScript not being able to be certain that your scene variable actually is a BABYLON.Scene already. Probably the easiest way to track this down would be to find where that variable is declared and explicitly declare it to be a BABYLON.Scene; for example, if that variable is currently declared using a line like
const scene = createScene();
you might replace that line with
const scene: BABYLON.Scene = createScene();
This explicitly tells TypeScript that that variable is supposed to be a BABYLON.Scene. That probably won’t eliminate all errors, but it should move them to a more informative location as, instead of complaining about CreateLines(...), TypeScript will start complaining about wherever it thinks it’s trying to put a value in scene that it isn’t sure is a BABYLON.Scene. (For example, if the createScene() function from the above code wasn’t declared to explicitly return a BABYLON.Scene, TypeScript might complain about that instead.) In this way, by making types explicit as you work backward through the TypeScript errors, you should be able to find the real place where syntax ambiguity is causing TypeScript to be uncertain whether a variable has the correct allowable type or not. Hope this helps, and best of luck!
Adding @RaananW
more context: TypeScript: types incompatibilities · Issue #9407 · BabylonJS/Babylon.js · GitHub
Hi,
It would be great to see how you import and include babylon.js in your project, and maybe the project source code itself if possible.
It feels to me like you have two different type definitions that collide for some reason. Might be our issue, and this is why I want to see code. It seems to me like the loader and babylon itself define the class differently. And I agree - this seems odd.
I would also recommend moving to the es6 version of babylonjs instead of the UMD, especially if you work with typescript, as UMD is more targeted at JS native users (but should support typescript as well). ES6 is more modern.
Regarding the other two examples (material and standardmaterial etc’). - this is the expected behavior. A material is not a standard material (but the other way it is). I don’t know where you got this error, but the same goes to texture vs. base texture. If you try to assign a base texture to where a texture is needed, you might have an issue, but not the other way around.
Yeah, I think I found the right types.
Standard importing
import { AbstractMesh, Scene, SceneLoader, StandardMaterial, Texture } from ‘babylonjs’;
I am no more using BABYLON.*, but instead the type only
for example: Instead of
new BABYLON.Texture();
new Texture();
The source code:
Thank you for your help!
I am very happy with babylonJS, but there are plenty to learn 