Popular Content

Showing content with the highest reputation on 09/24/2018 in all areas

  1. 3 points
    Hi Babylon.js community, It is my pleasure to announce BabylonCpp, a port of Babylon.js to C++, facilitating the creation of lightweight, cross-platform 3D games and applications with native performance. This port is a manual translation from the thousands and thousands of lines of Babylon.js TypeScript code into C/C++. Some history In 2015, I was looking for an interesting pet project. Due to my interest in 3D and modern C++, I stumbled upon Babylon 3D (C#/native port). I used this project as a starting point for mine and started updating the code with the latest code of Babylon.js. In beginning of 2017 - after a long time of porting, frustration and testing - I decided to publish the code on GitHub. Since then I kept updating the code and adding examples on daily basis. The Good TypeScript makes it really easy to port to C/C++ compared to JavaScript. For most parts, it is basically copying the code, updating to the proper syntax and updating the header. To get a good overview of the current state of the project I refer to the screenshots on the samples page. Not really a surprise, but if you look at the samples code you will see that the API looks very similar to the one of Babylon.js. Not all functionality is supported yet, but this a work in progress. I am really pleased with the performance of Babylon.js and the speedup of BabylonCpp. I am aware that I am comparing apples and oranges but I can give you some numbers. On my Intel NUC NUC7i5BNHX1 (Intel Iris Plus Graphics 640 GPU) I am getting the following numbers for the relatively simple Grid material example for a resolution 1680x1050 on Fedora 28: Babylon.js engine (v3.3.0-rc.3), Firefox 62.0: +/- 15% fluctuating CPU load, 270 MB RAM usage, fluctuating fps between 45-60 fps BabylonCpp (library size is 7.6 MB): constant 2% CPU load, 16 MB RAM usage, constant frame rate of 60 fps Some possible use cases of BabylonCpp include: Native apps development on iOS, Android Using the library as a WebAssembly module Using the library in existing desktop applications or integrating third-party libraries (i.e. Recast & Detour, Bullet Physics engine, etc.) Technical exploration (i.e. testing functionality that is in OpenGL and not yet in WebGL, supporting Vulkan API) The bad Most of the time goes into keeping up with all the Babylon.js code changes. Every month I take a snapshot of the latest code and port the changes into my version. As a result, the code is always very up-to-date but code on which people are still working or that might be thrown away in later versions is also integrated. An alternative I am going to follow for Babylon.js 3.3 is sticking with the stable version and focus mainly on features and stability. Porting will be done in a branches and less frequently. Not all code can be easily ported. For instance, C++ does not have reflection. There are third-party libraries available to support this, but this means introducing a new dependency. ...and the Ugly Linux is my main development platform. The code compiles on Windows (MSVC 2017) and OS X but is not really tested and buggy. On Linux I am also getting different behaviour between the debug and the release version. So the library is for moment only really usable on Linux in debug mode... Looking forward to hear what you think about the project or where you want to use it. If you have some suggestions for improvement or want to contribute or help resolving some of the issues described above feel free to contact me any time or let them know in this forum, it certainly would help a lot! Cheers, Sam
  2. 1 point

    BabylonJS Editor V2

    Hello awsome community! The BabylonJS Editor V2 is now available and online! It comes with a web version and a native desktop application (Electron)! From the V1, this new editor comes with a better user interface and more tools to write less, less, less lines of code Demo This demo video shows a project 100% made inside the editor. It includes custom scripts written using TypeScript, path finding, custom post-process and custom animations Features Create and edit particle systems Create and edit animations Create and edit lens flares systems Create and edit physics states on meshes Create and edit materials (including materials library) Add and edit sounds Add and edit textures (including render target textures & procedural textures) Save projects on OneDrive / local with Electron Deploy project template on OneDrive / local with Electron Scene graph view Create and edit custom post-process Create and edit custom materials Attach custom scripts (JavaScript and TypeScript) to your objects Test your scenes with debug support Video tutorials The documentation is available in the BabylonJS Documentation but now comes with videos to illustrate the written documentation: https://www.youtube.com/channel/UCNogU8tcA5IegFvMwE2Rckw/playlists Some links Full documentation: http://doc.babylonjs.com/resources/ Editor: http://editor.babylonjs.com/ Desktop Application: http://doc.babylonjs.com/resources/getting_started Git Repository: https://github.com/BabylonJS/Editor Conclusion If you encounter a bug, don't hesitate to report in the forum and I'll make my best to resolve it. Thanks for being BabylonJS users. Hope you'll like using this editor
  3. 1 point
    Hi @jdavid and welcome to the forum. Weekends tend to be quiet so you may get more suggestions later on. Have you read about dynamic terrains ? They might help.
  4. 1 point

    Cylinder edit vertices on top

    @Dieterich a belated welcome to the forum from me. I think I am right in saying that you will only ever get a pointed top to the grain using a tube because the cap uses a barycenter. Using a bezier surface you can get a more curved top, however the issue is that you cannot get a true circle with a bezier surface. In the following PG the boundary control points are fixed to form an approximate circle lying on a sloping plane. The central control points, indexes 1, 1, 1, 2, 2, 1, 2, 2 are changed in an animation to show the different types of top you could get. The equation to vary the inner control points is not the only one to use on these points. Hope this is of use https://www.babylonjs-playground.com/#KT9EE7#7
  5. 1 point
    Please remember that the Gamelets are demonstrations of what is possible with Babylon.js and how different idea can be achieved. They are starting points not a finished product. You need a line that extends one of the existing lines onto the roof edge to split the plane with five sides. and then re-label. This PG gives the idea though the actual numbers for the new 'corner' are not totally accurate http://www.babylonjs-playground.com/#4GBWI5#108
  6. 1 point
    @Sebavan here is your identity LUT if you still need one. I am starting a repo for LUTs for us to use/share. Yours is the first. https://github.com/PatrickRyanMS/BabylonJStextures/tree/master/LUT or if you just want the raw link to include in your PG: https://raw.githubusercontent.com/PatrickRyanMS/BabylonJStextures/master/LUT/NoAdjustment.3DL
  7. 1 point

    Moving a group.

    Yes, groups can't be positioned, scaled, etc. You can use containers as an alternative.
  8. 1 point

    VR fixed sight

    Give this a shot https://www.babylonjs-playground.com/#Q1VRX3#10 Also note that using babylon objects ._variables are private which means they should not be used in production code and could be changed in the next release.
  9. 1 point
    Will be fixed in 2 minutes and live in 5!
  10. 1 point
  11. 1 point
    Yup probably related to this, I am on it : https://github.com/BabylonJS/Babylon.js/issues/5220 I ll keep you posted.
  12. 1 point

    Jitter / Tremble of Parent Mesh Camera

    I mean having everything but the camera attached to a parent node and move that parent node instead of moving the camera
  13. 1 point
    If they are embedding your games and you don't feel comfortable with it (since they didn't license it), I suggest having a look where they are hosting your game from, and implementing a secure site-lock that will block the game from running. I found a few of my games on their site too.
  14. 1 point

    Web Assembly

    Hi guys, Here's my first real WASM test : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html Caution before clicking on the link : it's a very big SPS with 40K solid particles, this could freeze your browser. I'll report more precisely about this experiment here : About WASM itself : I generated the WASM bytecode from some code ported from TS to AS, AssemblyScript . If the logic is quite simple to port from TS to AS (because the syntax is almost the same, just add strong types like "f32", "u32" instead of "number"), the shared memory access (shared between the JS main program and the WASM module) is really complex and painful. Indeed, WASM knows only very basic numeric types only : i32, u32, f32, f64, etc and nothing about more complex structures like strings, arrays, objects. It's really low level and we have to deal with pointers and offset to pick/store the data at the byte level directly in the memory. Note also that there's no garbage collector. This means that creating any "object" (array, instance of a class, each time we type the word "new", etc) in our logic will require to manually free the dynamically allocated memory to prevent memory leaks. Moreover WASM doesn't provide any math library, so no trigonometry at all (sine, cosine, tan, everything required for 3D computations actually), so we have to implement by ourselves, say, the function sine. In brief, for a developer coming from a productive high level language, despite the help of the easy syntax of AS, it's a jump back in the past because the way to code it right looks more like some the C or the assembly way. Indeed, the first version of this code, very TS-like, very twice slower than this more low-leveled published version. You can get the AS source here : http://jerome.bousquie.fr/BJS/test/SPSWasm/index.ts [EDITED] That's said, what about the gain ? Here are different versions and the FPS in my Chrome : Legacy SPS - 8 fps : http://jerome.bousquie.fr/BJS/test/spsReference.html Reference Buffer SPS - 7 fps : http://jerome.bousquie.fr/BJS/test/spsBuffer.html fun to see that now the legacy SPS what has been optimized is faster than the lighter buffered one WASM SPS - 31 fps : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html it's the port of the Buffer SPS in AS perfs gain = x 4.42 ... not that bad, finally
  15. 1 point

    Shadows weirdness

    Hello! try to play with generator.bias to fight against that (it is called peter-panning :)) Doc to read: http://doc.babylonjs.com/babylon101/shadows
  16. 1 point

    Pixi.js Showcase

    Find the cat - A web game for toddlers I made this for my daughter, to help her learn how to use the mouse. The player has to find and click a cat, lost in a scene with some other animals. Play it here: https://rap2hpoutre.github.io/find-the-cat/ I took me a few hours to build it. I draw the sprites pixel by pixel with piskelapp (great free tool). Anyway, I'm not an artist, just a coder. The source is available here: https://github.com/rap2hpoutre/find-the-cat. It's a quick and dirty code, my goal was just to quick build something on my free time. Feel free to AMA (still, it's a micro-micro-game so maybe there is nothing to ask!). It's my first post here, I hope I did not break any rule!
  17. 1 point

    Why is BJS now mostly Typescript?

    http://walkercoderanger.com/blog/2014/02/typescript-isnt-the-answer/ https://www.google.com/amp/s/davidwalsh.name/typescript/amp i personally think TS is a flash In a pan and will never become standard... but if others feel different that's on them. If it works for you it works for you, but maybe y'all should consider calling this babylonTS now as to not falsely advertise. I am a huge fan boy of vanillaJS though so my opinion has some bias.
  18. 1 point

    Why is BJS now mostly Typescript?

    I suspect you were talking to me, here, @davrous. I didn't say you were ignoring my point of view. I said you are ignoring the (somewhat huge) number of folks who avoid contributing.... due to TS dev env setup. Hell, you just saw 3-4 of them (typescript shy-aways) in this thread alone. Is the TS reluctance seen in this thread... "not facts based"? "Not convincing"? [or perhaps you are saying that those fears are unwarranted? likely true] What would it take to convince you? If we physically counted all the "Shy-away from PR" comments in the forum, would THAT help? I don't want to blow smoke up your ass, dav. I want to report what I have seen... as accurately as possible... to you. But, in-kind, please own-up to the shy-aways that you have seen... IF you have seen them. If you haven't seen the (many) "rejection comments" to "Can you submit a PR?", then there MUST be some reason you haven't seen them. Or possibly, I'm hallucinating them. Perhaps they are a fragment of my constipation figment of my imagination. I'm not trying to piss you off, dav... I kind of like you, but I don't know you very well. But, you and I are not seeing the same things, apparently. Let's try to determine why the amount/% of .ts shy-aways... is a different number... for you and I and others. Trend checking. @dbawel, don't let this crap grind you down. You need to try to understand HOW MUCH the core team is trying to keep-up-with... with very low man hours available. Moving toward a stream-lined and semi-automated workflow environment... was imperative, likely. And, as you can tell, there are some emotions happening, here. Pride. Try not to react too heavily to emotions, if possible. The "fire" of pride... is a good thing. It's "spirit". Energy. Personally, when folks dump their spirit all over me... I learn important (and good) things about that person. *shrug*
  19. 1 point

    Why is BJS now mostly Typescript?

    I would good keep my opinions to me, I'm walking on eggshells every time. Whatever, I do not see that a wrong to say his opinons. I really like Babylon. Sometimes I want to contribute, but I'm not very comfortable with TS and not necessarily talented to contribute on a major engine. I think that TS has been chosen in part to attract contributors more talented rather than attract contributors beginner. I remember the beginnings of Babylon when he came out. It was about developing a JavaScript engine for JavaScript love, it was a nice language and now I have the impression that it is a bad language, that those who use it have nothing understand even in the future, we're late, we can use it in 2 years or more, that TS is better. But there is no bad language for me. I don't like the languages 'compile', I prefer languages Web, PHP, JS and I use simple IDE as notePad++, faster to open and more direct , so I must have understood nothing and I'll stay late in this case because I don't use TS. Wingnut to reasons: attract other contributors more experiment to lose another category more amateur or comfortable with JS Hence the choice of TS. Yes JS is always present for users of the engine, so no problem since we are just user. But I still miss the days where everything was done in JavaScript because Babylon was built like that for love of the JavaScript, it was a great language and now it's TS which is great and JS a lot of default. So maybe I should stop my view project that JS is not a good choice. I ask myself questions while reading all the posts here, I made the right choice for my big project view HeroonEngine as JavaScript is despise by the developers. I don't take any party, I'm not against or for. I'm just saying that there are no bad language, that's what I want to believe, the choices are made to attract a certain category of people, and not another, not because a language is better than another. We may be comfortable with one and not the other, it is not the language that we do not control, a shit. some are planning to contribute on an engine only, Babylon is a great choice, but everyone does not come to contribute, they're coming to create a project personal, commercial or not, using this engine (am I doing part of its people). And this small category of fans is despise by what it does not contributes. This isn't because it's open source that needs to contribute and it is not because it does not contribute that one must be despise or took high as @dbawel can be to take the decision to go. Sorry if my English is not very understandable. .
  20. 1 point

    Why is BJS now mostly Typescript?

    @davrous and @Deltakosh - My apologies for any opinions about using Typescript - as Babylon.js is a great framework. I will not comment any further on this, and withdraw my opinions in the future as this is far too hostile an environment for me to continue. I will however continue to post my projects on GitHub and others whom I work with and have been extremely fortunate to have connected with on this fantastic forum. I expected to be permitted to provide personal opinions - especially if I stated so in advance, and differ from others - so in light of the opposite, I believe I need to leave now; and am out. We (my company) are launching applications at Weta and Lockheed Martin (finally) in the next 30 days and expanding fast - and I truly apriciate all of the efforts everyone is extending to the rapidly expanding framework. I suppose I simply am looking forward to a different future for babylon and a much more extensive coding process in my own opinion. So unfortunately, you won't be hearing from me much in the future, and @davrous you have been extremely instrumental in my evolution into utilizing this framework. So goodbye for now, as I don't believe the proceeding posts are the way to advance the forum. And @davrous - I only have great respect for you. and @Deltakosh - I'll miss you except perhaps I'll continue personal messaging to keep you up to date. I'll do my best to keep DK abreast of what we're working on, as well as maintain a positive representation within publications for the BJS framework. And soon there will be recognition of the BJS framework on a level not yet known. I've done all I can do... And @Wingnut, @Dad72, @gryff, and so MANY others - you'll be sorrily missed. Let's try and keep in touch other ways. Thank you all, and Goodbye... DB
  21. 1 point

    Why is BJS now mostly Typescript?

    Well, I definitely think you're wrong. And you obviously don't know me when you're suggesting I'm living in my world ignoring your point of view supposed to represent our community. I'm reading your point of view but I think it's wrong. It's not facts based and not convincing at all. I'm very concerned about the usability of Babylon.js since the very beginning and we've spent of lot of energy & creativity to make it attractive to various types of developers thanks to the choices we've made. Today, I can clearly see it's working great. It’s not always perfect, we’re committed to make progressed but globally, we’re really happy of the directions we took. Contributing to the core engine is another story. I'm seeing a lot of people complaining whereas I can't see any major contribution to the engine from them. When I'm looking to this graph: https://github.com/BabylonJS/Babylon.js/graphs/contributors, I can see that the activity is stronger than ever talking about the contributions. And I don't see any of the major contributors complaining about our choices, speed of development or usage of TypeScript. You then have to think about various classes of people among our community: - Major contributors to the engine. We're less than 20 guys - Developers using Babylon.js - Designer/Artist converting their work in Babylon.js I'm often talking with developers using Babylon.js and they're quite happy about it. TypeScript? It's transparent for them, most of them didn't see we're using it for 3 years. Going too fast? We're paying so much attention to backward compatibility that they don't care. We've got so many good features since 2.0, it's often more than enough for them. Optimization is there for a long time and Babylon.js is so stable that big companies are pushing big important sites/app based on that. Going back to contribution, core engine maintenance, we have a duty of keeping a professional grade framework. This means discipline, rules and good development skills. We can’t accept quick PR, low quality code because “you know, people are afraid of doing something better”. We're not there to code for free any idea that might look interesting as a first see. Sorry to remind that to everybody but Babylon.js is a FREE OPEN SOURCE project. We’re not making money out of it. We're passionate about it, we love to see people building things on top of it, making some money, driving their business, or simply sharing their passion of 3D with it. This makes us very proud. In the same way, we’re very happy & proud of our community sharing the bugs they’ve found, helping us on the documentation, suggesting interesting enhancements. But like anybody, our time is precious, we've got kids, family, some of us have very complex situations to manage you can’t even imagine. So, I'm fed up of people complaining it's "too complex" for them where it's obviously not. Most of them are hiding behind that because they want us (and to be honest most of the time @Deltakosh) to code that for them. @Deltakosh has always been very kind on that but I won’t be anymore on those specific topics. David
  22. 1 point

    Why is BJS now mostly Typescript?

    Hi guys! I believe the relationship is in the (likely-) fact that JS... is MANY people's first or only programming language. It is the web programming language of-choice, by far. So TypeScript "contaminated" the easiest and most accepted programming/scripting language ever (JS). In doing that, BJS lost a very large group of hobby-level programmers, and potential future contributors. There's your relationship. You/We took the general public's #1 most popular, easiest, notepad-programmable language that LOTS of people learned SOME-OF (in order to tweak their web pages)... and separated that from BJS. TypeScript made BJS source "alien" to those people, including me. Yes, it is probably an unwarranted fear and feeling of extreme inconvenience, but it is certainly not a joke. The phenomena IS happening, whether you choose to recognize it or not. This is one of the reasons that folks (including me) ASK-for features instead of coding them ourselves. Many types of people don't want to work with shells, NPM, grunt, gulp, and other "compiling" and "generating". There's plenty of them in the BJS forum. Now, nobody is bashing BJS, nobody is bashing core programmer work accomplishments, and nobody is saying that core programmers shouldn't use what works best for them. But I KNOW we lost some contributors when we went to pure TS. We went from "submit a JS function"... to "Get an IDE that does TypeScript, learn TypeScript, learn to compile things". These are things that DIDN'T need to be learned... when working with pure JS. They were already learned when folks learned primitive JS to tweak their websites. JS = widely accepted/used. TS = far less accepted/used. We lost the advantage of JS familiarity that was already established by the web. This all might be irrelevant. The move to TS is likely a good idea and inevitable. But if you think there was no newbie impact with that move, you are mistaken (imho). We gained some ease and popularity in one area, and lost some ease and popularity in another area. But, when Deltakosh said "just submit in JS and I will convert it to TS for you"... that took some of the "scared" away. That helped. He should say it more often. Newbies rarely know if a mod is a "good idea" or not, because they can't see the far-reaching impact on the entire framework. Between this situation, and TypeScript's dev environment from hell (when looked-at from noob perspective), new feature requests will continue to outnumber new feature git submits. People who dream-up features... are often not pro-coders. They are scene assemblers. If we keep telling users to setup a TypeScript dev environment, code their feature request, and submit a PR... for every time they ask about the plausibility-of, or otherwise request a feature, you are going to lose a whole lot of good ideas. You're also going to lose a whole lot of "warm fuzzies" that COULD have been given to that idea-thinking-up user... for submitting that "feature query". We could have said "Hey, there's an interesting idea." and then discuss, talk about far-reaching impacts, talk about what errors could happen with this new feature, talk about alternatives, talk about the BJS big picture. Instead, we say "Can you submit a PR?" Sheeeeit. Why not just blast the idea and user inclusion/participation excitement... with ice water from a firetruck hose. Freeze that idea-spirit dead in its tracks. Yay us! SO much love for the puppies, eh? Are you/we trying to make BJS popular among coders only, or are you after EVERYONE, like me? Sometimes I think there should be a USERS forum and a CODERS forum. Artists and storytellers and scene assemblers hang out in user forum. Core-change ideas that come from the user-forum... would be nurtured, with on-going discussion, and a GENTLE introduction to "If you would like to add the feature to core YOURSELF, here's the first few steps of the hundred steps needed to build and learn your TypeScript dev environment"). When people say "Could you submit a PR?"... and that PR requires learning git and setting up a TS dev environment, you might as well have blasted them in the face with a shotgun. (Not every situation is like that, but SOME situations are so. Do we care?) Currently, in our coder's forum... discussion is discouraged, because big dogs dislike long English comments. Not much nurturing is allowed, or else big dogs won't help later, because the thread got too long. So instead... "Can you submit a PR?". ("Hey kid, here's a bucket of TypeScript ice water... that should cool you down for a few months!") What is "our job"? sigh. It's not quite that bad, of course. Big dogs DO weigh plausibility of the idea. Generally speaking, an idea-proposer doesn't get the "can you submit a pr" line until after the idea has been deemed possible/plausible. We idea-proposers DO appreciate that feasibility quick-weighing, and alternatives-to-modding advice. At least I do. I like talking. Others... not so much. heh. I REALLY like listening to big dogs talk. That's how we learn the big picture... but it's not an easy story to tell. Possibly later, .ts dev environments will be load'n'go. For now... they present a road bump. That road bump is BIG to some people, and no problem for others. But if you think the road bump is not there, or not big, you're fooling yourself. The road bump IS big... to some. Do we care about them?
  23. 1 point

    Why is BJS now mostly Typescript?

    Hi @dbawel TypeScript is not linked to Visual Studio or any Microsoft specific. I know a lot of people using it on Mac or Linux. It's just a language that provide convenient ways to code. Except that, you know we're really like you and we've been working together for a long time But I'm sorry I don't get your point. What is the relationship between TypeScript and people. complaining we're moving too fast (which is to me a huge joke)? How could TS make Babylon.js more absolete than JavaScript itself given that TS is just, again, some JavaScript + types! Talking about Open Source contributions, it's truly better for us to have quality checked contributions thanks to the constraints of the language. And to be honest, users complaining are almost always people using it our engine and not people writing code for it. I'm now going to be more direct. @Deltakosh and I, as well as the core team, start to be really affected by all negative feedback during the last weeks about the fact we're moving too fast, we're using TypeScript, we're not updating (for free!!!) old samples for people's own projects. Honestly, those discussions are not constructive at all and lack from convincing arguments. We always have been listening to our community, I've seen @Deltakosh spending so many of his nights and weekends implementing some users' features requests that weren't needed in our roadmap that I've tended to find all these bad feedback unfair. David
  24. 1 point

    Why is BJS now mostly Typescript?

    I'm going to answer that as I'm the one who forced @Deltakosh to switch to TypeScript. First, TypeScript is "just" a superset of JavaScript, adding types and supporting future features of ECMAScript by transpiling down to ES5 or ES6. This means that we don't break anything with regular users that will just use the compiled JS version in ES5 or ES6 and will never see it comes from TypeScript. Thanks to the switch we've made 3 years ago, we've managed to find bugs that were just under our eyes and difficult to find in plain JavaScript and we've also managed to boost our productivity on the engine, which is good for us and our community/customers. @Deltakosh has done a great article on that: https://www.eternalcoding.com/?p=103 On my side, 3 years ago, I was also concerned on the fact we were spending a lot of time answering basic questions of our users, trying to understand if there was a bug in their code or in our code. All this time was our spare time and wasn't used to improve the engine. I've then started to discuss with @Deltakosh on ways to solve that and again TypeScript was a good candidate. Why? Again, thanks to the types exposed, I’ve discovered great possibilities such as the TypeScript playground: http://www.typescriptlang.org/play/index.html I’ve then told to @Deltakosh we could do something similar, having autocompletion in the browser, building some basic sample codes to help our users, learning by live discovering the API. Deltakosh ended up building a much better playground with great features such as saving your code to share it with your colleagues or on the forum for review, downloading the ZIP, etc. Something which would have been much more difficult without TypeScript. TypeScript also offers us to use future features of ES now to add clarity to our code: module, class, arrow functions, generators, async/await, etc. Those are not TypeScript specifics. You will have to learn them to be able to write ES2016/ES2017 code anyway. Regarding the fact it comes from Microsoft, this is really not what influenced us (everybody knows deltakosh and I are MSFTees). Deltakosh was even against at the beginning but quickly changed his mind when he discovered the potential behind without affecting our users. Even if it comes from Microsoft, the web community enjoys TypeScript and other big companies such as Google is using it for Angular 2. TypeScript also offers another great benefit for us: we managed to attract talented developers such as @Nockawa writing the awesome Canvas2D extension who was mainly a C# developer. C#, C++ and Java developers tends to have difficulties understanding some paradigms of JS at the beginning such as the prototype oriented programming, the classical issue with capturing this for closure, writing module/class like with self-executed anonymous functions, etc. TypeScript is hiding that by still generating perfectly written JavaScript under the hood. I tend to find TypeScript also better to work as a team. At last, as said before, we managed to attract some customers using Babylon.js because it is written in TypeScript and you can them fully develop with the .ts version of our engine instead of the .js to have a full typed experience during your development process. Another great benefit: I can compile an ES6 (ES2015) or ES7 (ES2016) version today without changing a single line of code of Babylon. If we would be in plain JavaScript, we would have been forced to rewrite everything to switch from ES3/ES5 to ES6 for instance. The only caveat is that it’s a bit more complex for contributors to the code to do PR to fix bugs or add features. But to be honest, as said, it’s just the JavaScript we will all use in 1 to 2 years. Except this small part, TS doesn’t affect our users because it’s transparent for them, we’re improving the quality of the code, we’re going faster, we’re attracting more diverse talented developers, we’re ready for the future. I really don’t see where the problem is then.
  25. 1 point

    Why is BJS now mostly Typescript?

    Well David - given the background and connections of the BJS originators and developers, a quick look at this wikipedia entry for Typescript might explain why. Also note the line that says: What the BJS developers use every day - or perhaps later versions? Given that javascript is hard enough for me, I'm not sure that I am happy with the direction either. cheers, gryff: