Hi, I am creating a model editor, and moved to babylon.js from three.js as it had some nice things in it - most notably the material node editor. However I have had a few problems doing what I want - things I was able to do easily in three.js seem harder or more complicated in babylon.js, and I’m starting to think I made a mistake here.
Right now I am trying to export my created models to gltf. It seems I need to do the whole scene, not just a single mesh. Then I need to exclude anything I don’t want to export from the scene, and the gltf seems to have lights and a camera in it as well. So I thought I would create an empty scene and just add the meshes I want to export…that sort of worked, but no materials.
So I guess I am looking for a simple solution to just export a created mesh to gltf, and maybe some general comments as to whether babylon is good for a 3d model editor.
Thanks - yes I know I can exclude things. Three.js allows you to feed in a scene or a model to export just that - its a bit weird to have to exclude what you don’t want, but anyway.
Not just about export gltf, I just keep finding things missing or done in some way that doesn’t make sense to me - I converted my previous prototype from three.js to babylon, and it look a lot longer then I’d hoped because I just kept finding little things that were a lot harder. Lack of a ‘group’ concept was annoying, vertex data differences for created geometry, out of date or missing docs, lack of model export formats …anyway I am slowly getting used to it, but am now wondering if I made the right choice. Was wondering if anyone here is using babylon for 3d editor/model creation and what experiences they have had.
For this part the TransformNode class works well in place of Group I think. Here’s a simple example to parent 4 box meshes to a TransformNode called boxGroup and then position and rotate the boxGroup for example.
For things like missing or outdated docs, they tend to get updated fairly quickly I think once a particular issue is raised on the forum.
For choosing which nodes to export, maybe supporting something like nodesToInclude and nodesToExclude in the options parameter would be helpful, so that the options object could then have either the shouldExportNode function or one of these arrays specified.
EDIT: I took too long LOL. It looks like @carolhmj already covered most of this but will leave it all up.
Yeah I already got transformnode working - the problem was what I did a lot of is have meshes in groups and turn those groups visibility on and off - transformnode doesn’t seem to have this option. It took a bit of research to figure this out. Lots of little things like this I keep needing to do differently.
On the docs issue I have a list a mile long, not least of which is the 2 versions on everything on NPM which confused me quite a bit at the start. Figuring out I needed to use the @babylon.js and not the babylon.js…maybe I am still confused about this.
I deal with vertexdata a lot, and on this page; VertexData | Babylon.js Documentation - it says “Please use CreateCapsuleVertexData from the capsuleBuilder file instead” - but I can’t find any reference to this anywhere else. So I am using the deprecated method right now.
Just a simple note; I use the glb format instead of gltf to pack everything, as in the mesh and its textures and materials, in one package. For me it is a lot simpler
Ok, look I figured all this stuff out already, I was just making a general observation - coming to babylon.js has been a lot harder then I thought because of all these problems. It has seemed like at every turn something is out of date and I have to figure out what should be simple things.
This is the feedback from a brand new babylon.js user (maybe 3 months) after using three.js for years.
There is some great stuff in there, but this doc stuff, along with some of the decisions about how things work, has been a major headache and has lead me to waste a lot of time just trying to find out/figure out how things work.
We are always happy for PRs to fix such things. We trust ourselves and the community to fix it. Read the code also implies that everyone have the ability to fix the code.
Thank you very much, any feedback is valuable for us. We are constantly changing (hopefully for the best).
Look, we are not perfect. That’s true. But we have a lot of new users coming, asking questions, making observations, and using the framework as they see fit. There might be a learning curve which we are trying to “flatten” as much as we can, but that’s the case with every new framework. We sometimes do things differently, that’s true. I hope you will slowly realize that’s those decisions are made for the sake of the user and not just because we find it fun to do that. Yes, we have 2 package styles, yes, it might be confusing, but it is fully documented. If you say - “well, it is hard to find!” I would probably agree with you! We can learn from that. If you “wasted a lot of time trying to figure things out”, and if you have a little more time to help others, make the changes, suggest what you think can be done. We are always listening.
Thanks for all the replies and help, I was probably just a little frustrated at that point, as it seemed to be 5 things in a row I was trying to do were more difficult, for what seemed like no good reason.
I would say someone needs to look at the doc references in the NPM package pages for the extensions on NPM as they refer to pages that don’t exist and that was a big one for me.
Also I am willing to help - I just don’t know enough about babylon yet - I’m pretty committed to it now though, and am just about to put up the early version of my project on http://mc.mindlessbrain.com/ - that will replace the current version on there now which was written in Three.js
@joelutting - I just want say thanks. Thanks for being willing to share your frustrations in ramping up on Babylon.
Honestly it’s SUPER valuable feedback to have. We want this platform to be the very best that it can be and we want to ensure that people can pick it up quickly. ANYTHING that gets in the way of that is something we are eager to hear about and address.
So don’t be shy with specific requests of things that have made you stumble and things that you think can be better. As @RaananW we are definitely listening and eager to help.
I want to sincerely welcome you to the Babylon Family.
I’m happy to dig into any doc fixes that you think might be helpful if you can link a few pages with suggested fixes.
Just adding to this: I, too, found certain parts of the documentation troublesome - though it’s usually nondescript “information” that basically regurgitates what the names/code already say, which isn’t helpful if you don’t know what it means in the first place.
That said, I switched from Three.js to BJS years ago and it has been nothing but amazing - the community support and tooling has been great at every step, and even the documentation I found to be much better (although it has changed its structure drastically a few times and that may have caused some pages to go AWOL…). Of course that doesn’t mean everything’s perfect, but I don’t doubt that the team is doing the best they can
Perhaps it would be possible to check for dead links automatically (as part of the CI)? I know documentation generators like docusaurus do this, and it’s always been very helpful in my own projects.
As for overall better docs, I’d love to help with writing guides etc., but I don’t really know what people would find useful (and I don’t know too much about the internals when I haven’t worked with a particular system extensively). It seems to me that the current docs are mostly a brief overview to cover the most common tasks, but they often leave a lot of the more advanced/obscure use cases out and frequently fail to link to related topics (especially background info or prerequisites that are silently assumed, but not always present).
Additionally, there’s probably some UX improvements I can think of, such as allowing people to open the playground examples by clicking on the “bar” instead of just the tiny “open in new tab” icon that I always miss (:D) or the playground search that similarly doesn’t open the example when clicking on the main body. These might simply be a matter of taste, though, and I’m sure you have thought about the UI and UX extensively before building it this way.
We are checking for dead linked in the documentation page. Not checking for dead external links from the code doc though. We can try adding this in a future modification of our CI.
It looks like 
