How does babylonjs-loaders work when using "webpack" with typescript and babylon.js?

[nogalo]

I used Babylon.js in Javascript projects, in Typescript projects, using webpack, using React. Never had an issue that I couldn’t solve. I am also using Threejs/React-Three-Fiber. I used PlayCanvas, I used AFrame, I used Sketchfab, I used Threedium. My opinion, Babylon.js is the simplest engine, most powerful engine and best engine to work with regarding the community, as you can find literally any answer within the community. Not to mention that documentation is superior to any other engine, just check out the Three.js and Babylon,js docs. Please, don’t come here with that attitude. If you like other engines more, you are free to use them. But you will miss out a lot.

GLHF

[florentraff]

It’s not attitude. Ok maybe a little, but I edited my post to be a bit more thoughtful.

I’m just giving my opinion and feedback. I think that for at least some demographic of the user base that finds themselves attracted to Babylon, after seeing the promotional material there’s a sudden and surprisingly steep learning curve to get started that they maybe don’t see coming. At least I didn’t, and I would appreciate a bit more documentation, specifically, on how to get a project started in vscode and also explanations as to why I would do it the way RaananW has in his github project. Just a little more “why” and a little less “what” on setup stuff would be helpful for noobs imo.

It’s not a comment on the documentation in general, or the quality of the engine once you are indeed up and running. Sounds like you really love it.

[rdw1]

I think one major issue that the team has been struggling with is determining what knowledge they can presume users to have, especially in terms of unrelated web ecosystem tools (npm, webpack, etc.) and maybe even 3D fundamentals.

Too much and new users are overwhelmed, too little and it gets overbearing. There are many different users, each with their own goals and different levels of existing knowledge. This is not easy to solve

The docs can certainly be improved, but you would need to define first what users and tasks a given piece of documentation is intended for. Some also don’t care about understanding and just want stuff to work, while others need to have all the background information (which is indeed often lacking).

Say, for example, you want to improve the new user experience in this particular case:

• User knows nothing about the JavaScript ecosystem and its tooling
• They’ve some programming knowledge and read the MDN JavaScript guide
• They know nothing about 3D rendering (what is a Mesh, Texture, Material, …)
• They may not even be a native speaker of English and could have troubles understanding the docs (oops…)

You’d have to lay a LOT of groundwork first before they can really understand what’s going on. Or you’d have to exclude anything used in the real world initially and slowly introduce it with a more extensive tutorial. Either case will leave a lot of users behind since they have different needs and expectations.

Either choice is already putting a lot of limitations on what the docs can and cannot include… and it’s probably not even the lowest common denominator since there’s people who are primarily (tech) artists, just want to render a model they created in Blender/from GLTF etc. without necessarily needing all the JS tooling, inexperienced/hobbyist programmers, etc…

My point being, if you feel the docs are lacking (which I agree with, for the record), maybe you can provide the details needed to ensure an article is written with a user such as yourself in mind:

• What is your goal?
• What is your existing knowledge?
• What are your expectations and preconceptions of and about BabylonJS?
• What format and learning style would you prefer?
• How extensive and detailed should an appropriately difficult tutorial be?
• Are you fine with being referred to 3rd party docs and reading up on prerequisites first?
• What level of overall complexity is manageable to you?
• Should those third-party tools be included or excluded? (simplification vs. real-world use case)

There’s probably many other considerations, but answering these would likely be a good starting point. Basically, “some demographic” needs to be more closely defined or else it would be difficult to make sure there’s appropriate documentation for them.

[RaananW]

That’s a very interesting discussion TBH.

First, my personal opinion (NOT the team’s! this will come later ) -

Babylon is a mainly a web tool. And as such, we are doing our best to make it as compatible as possible with the web standards that are available. As a web tool, it can be used as any other web framework available out there. Babylon is a framework. There is little to no “magic” in the code. We are creating a proxy between a developer and web APIs such as WebGL or WebGPU to simplify the process of working with them.
Just like any other web tool, you need to know the basics of web in order to work with it. It is true that babylon uses APIs that are uncommon with many famous web frameworks, but still - it is still used just like the others. And it can also be integrated into other frameworks. When you start working with React (or angular, or vue, or fresh, or the other 1428957 frontend frameworks out there) you need to know how it is working before everything is working as you want it to. Try to “bend” those frameworks to your needs and not work the way they expect you to work, and…

It is true that frontend frameworks (most of the time) provide you with an environment where you can work with the default values that they think are right. But if you want to dive into the deeps and add support for other things, you will need to know what you are doing and how the other module/component/framework works in order to incorporate it into your project. Ask yourself - do you know what build environment is used when running the default create-app in react? or angular? do you know the inner doings of those frameworks? If you haven’t used them long, the answer is probably no.
Babylon offers the same. We offer a very simple way of using babylon in your project. UMD and global-namespace assignments has been here for a long time. It might not be the best practice, but it is working, and compatible, and will work with most if not all of the tools available. So you have a simple way to get started. But just like the other frameworks, if you really want to do what you are planning, you will need to get to know the framework and its environment to have a good time.
Want to work with typescript? good for you! But you will need to know how typescript works! You can’t simply “import” a glb and expect it to work. You need to know how glb is being consumed, you need to know that typescript doesn’t have a clue what glb is, and you will need to know how to combine the two.
Want to use es modules? Awesome!!! You will need to know how import works. just like you needed to know how amd or commonjs works. Don’t know? that’s fine as well. But then only the default, known scenarios will work well for you.
Want to combine Babylon and react? Huzzah! But you will need to know both frameworks. How does babylon’s render loop works, how does react initializes components, how does the pointer system works, and how to make it all work in a way that is scalable. And this is just one framework. there are a lot more.

We are trying our best to make it very simple to work with the framework. simplicity is our starting point when designing new APIs. you can argue that some are not simple, and I will tell you that you are probably right! But I can definitely say that from my experience, babylon is simpler than many other frameworks. But still, it is a 3D framework. And as such, it brings complexities that cannot be masked so well. Heck, I have been developing with and for babylon for… 8 years! And I still don’t know everything. Trust me, it’s a never-ending learning. But we are transparent, and we document almost everything. At least we try. If something is not documented, we will document it. Might take some time, but it will be there. and until then, we are very patient when answering any question. I don’t remember any question where we said “that’s your problem, don’t bother us with this nonsense”. Unless the dev talking to us refuses to accept our answer and keep on saying we are wrong…

S, TL;dr (of my opinion) - we can’t cover everything for the developer. We can offer web-sandard way of working with the framework and expect you to do the heavy lifting in the background when you need something more advanced. This does not mean we won’t help you when you need help. The web is a HUGE place, filled with so many ways of solving a single task. Choose your way, and ask questions if you need guidance.

Now, about the team’s opinion - we are doing our best to document a lot of scenarios in our docs page. As @rdw1 said, it is very hard to cater all needs of all devs, but we are slowly adding new content to our docs page and try to explain how to use babylon in different scenarios. We are also working on a doc-structure overhaul that is, in some way, going to address this need. We continue offering “getting started” projects and “golden paths” to show you how things can be done (mind you - how it can be done, but not always the best practice. You might find a better way, which is always possible).
Our resources our limited, and the web is a big place. We won’t be able to provide demos for every scenario, but we will do our best to provide it as much as we can.
We want to make the framework available for everyone. Starting developer that did nothing in 3D so far? welcome. A 3D artist looking to show his 3D models on the web? of course. A seasoned developer looking to improve his abilities? good for you. Getting started guides are available, advanced topics are there and are being updated and rewritten when needed, and new doc pages and code-docs are written almost every week.
We hope to eventually get to the point where everybody’s happy and are able to get started. It’s a never-ending task, and we are more than up for it

Stay awesome!

[DOEHOONLEE]

as @rdw1 said,

I think one major issue that the team has been struggling with is determining what knowledge they can presume users to have, especially in terms of unrelated web ecosystem tools (npm, webpack, etc.) and maybe even 3D fundamentals.

this may be right.

I do understand the struggle with webpack, es6, treeshaking, and all. I have been struggling with these lately too xD

However, the way the OP asked for help, described, suggested seem a little too much.

Following the steps and the track suggested by @RaananW should be the best way to approach.

I cannot just jump into a new tech and expect to know everything and use everything right away.

Choosing a library in the first place? I think it may be a matter of choice only.

You can always stick to the techs that you are satisfied with or that are easy to use, but I personally think that the point of being a developer is to broaden our views of new tech, try new stuff, keep struggling.

A project that works right away in one try? Sure, that’s also nice, but where’s the fun in that?

[ilyhandrik]

For those who encounter a similar problem:
you can simply copy the assets folder using copy-webpack-plugin.

    plugins: [
        new CopyPlugin({
          patterns: [
            { from: "./assets", to: "assets" },
          ],
        }),
    ],