Suggestions for teaching with Babylon

[eee-c]

Howdy!

This might be a bit too much brain dump for a forum, but here goes...

By way of background, I'm the author of 3D Game Programming for Kids. I've been evaluating Babylon (and others) as I prep for an updated edition. The book first came out at the end of 2013 when Three.js was pretty much the only game in town. It's fun seeing what's available in 2017. And Babylon is among my happy discoveries.

That said, I've got some questions / feedback -- and am especially curious if others use Babylon to teach. I totally get that Babylon isn't a teaching library. So feel free to ignore some / all of this..

First up, I really appreciate the beauty of the resulting animations that I get with Babylon. Even with simple shapes (e.g. those in an intro chapter), things are pretty and don't require much fiddling with lights and cameras. The various support handlers (resizing) are unobtrusive and work solidly. And the integrated physics is a joy. I seriously love working with that stuff. That said...

The API kinda bugs me (and I say that with due love!)...

One of the things that I try to do in the book is keep the typing to a minimum. It's aimed at kids -- motivated kids -- but kids nonetheless. The more typing, the higher the likelihood of errors. The more that code requires switching between all caps, and camelcase, the more likelihood of coding errors. The more namespace depth, the higher the likelihood of errors. The same goes for the number of arguments in constructors and methods. As well as the different kinds of arguments (strings, numbers, objects, and attribute objects -- curly braces can be daunting!). 

In addition to a lot of typing, needing to label every mesh and supply every mesh with a scene object is burdensome without providing much conceptual relevancy. That is, I have to teach kids / adults to include them all the time even though names aren't used much -- at least not when introducing concepts. Mostly, I wonder why createSphere can't auto-assign the name "sphereN" when the first argument isn't a string. My understanding is that the scene argument helps with memory management, which is cool -- it seems to work. That said, I wouldn't mind the option of being able to tell the scene to add a mesh instead of creating a mesh for the scene. And really, I'd like fewer arguments for my own sanity in addition to teaching.

So I'm curious if anyone deals with teaching or has suggestions for how to deal with these things. I've thought about writing a simple wrapper that flattens some of the namespace, auto-assigns a label, and simplifies the MeshBuilder create methods. Maybe something that creates a sphere even when no arguments are supplied, creates a sphere with diameter when the first argument is a number, or creates a sphere with named attributes when the last argument is an object literal. But of course, that's work for me (shudder). Plus the older kids / adults that want to start "real" Babylon coding will be at a disadvantage.

Along those lines, I understand why MeshBuilder creates the shape and material at the same time. Still, I appreciate Threejs' separation when teaching -- create a geometry, create a material, create a mesh by combining the two. I understand that Babylon is meant for professionals to be productive, but it'd be super nice to have access to low-level concepts for teaching (and maybe coding at times).

It'd also be nice to have a set() method on Vector3 to be able to update all three at the same time instead of using the "inPlace" methods.

One last thing is the left-handed coordinate system. Kids just aren't exposed to that in my experience. I'm grateful for the useRightHandedSystem property even if it'd be preferable not to expose it at all. I would only suggest that it's not explicit and easy to overlook for folks first coming to Babylon.

Anyhow, thanks for the great framework. Really! Despite the above, I definitely anticipate using it -- even if not in the book. And thanks for providing this forum as a place to brain dump like this!

-Chris

[GameMonetize]

Hello and thank you so much for this APPRECIATED feedback. Here are my thoughts:

- API with long name: I'm a big fan of clarity and that's why I chose to use meaningful naming. For learning purpose I would HIGHLY recommend to use Typescript with an editor like VS Code where intelisense will help you by documenting the API while typing. Thanks to this, you won't have to type more than 3 letters most of the time

- The scene argument is here because then you won't have to attach your mesh to the scene. This is mandatory for scene rendering, memory management and all the internal work done for you by the engine. The option to avoid the scene in the parameter will FORCE you to think about calling scene.addMesh or something and I'm not convince this is better

- Reading your message, I think I have an idea. I will update the MeshBuilder functions to automatically use the last created scene as host if the scene parameter is not set

- MeshBuilder does NOT create a material (mesh.material is set to null) BUT by default Babylon.js will affect a default material if none is provided. For geometry, you are right, it is build for you for convenience reason

- Can you elaborate more on the set() method for Vector3? You can already affect them with mesh.position = new BABYLON.Vector3(x, y, z) or mesh.position.fromFloats(x, y, z)

- The right handed system is clearly an option for advanced users. I mean, once you decided which one you want to use, you don't have to think about it

 

[inteja]

I have taught interactive 3D at the tertiary level years ago, but pre-WebGL era. I don't have any direct experience teaching Babylon.js but I can understand your challenges in doing so.

After looking at various options I jumped 100% into BJS because for me it has a lot more polished, well-engineered features that were immediately useful to me out of the box, plus a great community. Although I'd never dealt with Typescript I knew of it and could see the benefits in using it instead of an older JS version, especially for larger, more sophisticated applications. I agree with @Deltakosh that Typescript-aware IDEs like VS Code or Webstorm are your friends. Webstorm (PhpStorm in my case) helps me to learn BJS with Typescript, identify and correct my errors immediately. As a student, I'd be floundering a lot more I think if I were using just plain old JS. Typescript is gold.

So, if I were to be teaching BJS to an intermediate level audience (i.e. some previous coding experience) I think I'd focus on BJS + Typescript + free VS Code + Blender & Gimp for asset creation. But given I'm still very much a student I'm probably not qualified (yet) to make such pronouncements :-)

[GameMonetize]

Ok your post motivated me

here is the new version where engine and scene are no more mandatory parameter:

https://www.babylonjs-playground.com/#IEGEV#0

[inteja]

That was quick 

[eee-c]

Wow. Thanks so much for the quick responses! I stepped away to eat and watch my daughter. When I return, not only do I have answers / suggestions, but also a new implementation to try? Amazing.

I agree in principle about TypeScript -- except Dart over of TypeScript every day of the week! 

Ahem 

But seriously, I think a TypeScript / Visual Studio approach is better suited for an in-person course than a book or even online content. I actually started the first edition of the book like that, but found it prohibitively hard to QA across all platforms. Also, as soon as the editor gets a significant update, the content is outdated, requiring updates, fresh QA, and reprintings. I've found a browser-based editor that I control to be a decent (but by no means perfect) longer-term solution. I also favor typing everything out when you're first learning it. Partly because that's how I did it as a kid. But mostly I think it gives kids more a sense of personal ownership of code when they -- not their tools -- write it out. All that said, I'll dig into Visual Studio as a possible companion / intermediate course (as @inteja suggests)  -- I definitely see the benefit there.

The scene thing isn't a huge deal. Mostly, I think a scene "has-a" bunch of meshes, not the other way around. And it makes sense to be able to describe a mesh independent of the scene in which it ultimately resides. Those are slight professional preferences -- slightly stronger teaching preferences. Not show-stoppers in either case.

The material stuff isn't a big deal -- I just have kids code up explicit ones anyway. And for my own coding, I am more than happy to use the default one 

The Vector3 thing that I'd like is, given a time, to write: object.position.set(t, 2*t, 3*t) or object.rotation.set(2*t, t, 0). I hadn't seen fromFloats() -- I think I'd like set() to be an alias for fromFloats so I can defer the whats-a-float discussion for down the line. 

The right-handed thing isn't a big deal for me now. I give kids templates in the online code editor and I'll just set that in the template. I mostly bring it up because the left-handed default caught me by surprise and it took me a while to find the property to switch it. Maybe most folks don't think about it -- but it tripped me up when I was getting started.

Huge thanks for the scene-less / engine-less test code. I'm going to go play with that right now!

Last, a major thanks for the responses. I know that was a lot of brain dumpage on my part -- I really appreciate the thoughtful replies 

Cheers!

-Chris

 

[dbawel]

@eee-c -

I personally wouldn't start with a WebGL framework and especialy not typescript. Just my own opinion, so please nobody hate on me. I would start with a language such as visual basic, as openGL and webGl can be daunting. I would begin with the comprehension of XY coordinates and simple routines that count or generate random #s. Once they've mastered these, then progress them into a world of understanding the requirements to create models and animation for gaming - mesh UVs and normals for example. Although, a bit of linear algebra and Euler math would set them on a path to a long career. I used to teach, so I'm not blowing smoke here...

DB

[eee-c]

@dbawel Thanks for the feedback!

I totally agree that WebGL, linear algebra, normals, etc. are right out for teaching kids. Kids should start with the simple stuff and work their way up. 

I do think that there are simple concepts that kids can learn in 3D programming -- and pick up a little JavaScript along the way. Again, I didn't have kids translate local to world coordinate systems, but they did learns the basics of what a mesh is, using shadows, animation, simple physics, even frame of reference. I kinda bet heavily that this approach worked in the first edition of the book (https://pragprog.com/book/csjava/3d-game-programming-for-kids). It's not going to suit everybody, but it seemed to appeal to a lot of kids. Hence the second edition

If you're interested, an excerpt from the first chapter is available here: https://media.pragprog.com/titles/csjava/shapes.pdf. That should give you an idea of the overall approach that I took (and that I'd like to extend in the second edition).

Bottom line: I think we're violently agreed . But if you have any thoughts as a former teacher, I'm very much interested in your perspective!

-Chris

[GameMonetize]

I would be personally honored if you use babylon.js in your book. Teaching to kids is a noble task

[chicagobob123]

This is great news. 

[JohnK]

On 24/02/2017 at 11:25 PM, Deltakosh said:

Ok your post motivated me

here is the new version where engine and scene are no more mandatory parameter:

https://www.babylonjs-playground.com/#IEGEV#0

Seems to be an issue if no scene parameter for ground, but OK to drop it for the sphere???????

Maybe OK provided eee-c does not use ground in the book!

 

 

[GameMonetize]

Not sure to understand: Ground has no scene parameter either:

var ground = BABYLON.Mesh.CreateGround("ground1", 6, 6, 2);

 

[JohnK]

Just now, Deltakosh said:

Not sure to understand: Ground has no scene parameter either:

var ground = BABYLON.Mesh.CreateGround("ground1", 6, 6, 2);

 

 

Sorry I meant to say for ground.material and forgot PG

https://www.babylonjs-playground.com/#IEGEV#1

should not try to submit when rushing to go out

[GameMonetize]

My bad..should be good now

[JohnK]

@eee-c Just to add some of my thoughts to the others. As a retired teacher I am still interested in how you get concepts over to people. In trying to help BabylonJS noobs I have expanded on some of the official documentation through a guide. When I go back and read some pages of the guide I still see the need for improvement. So I know how difficult it can be to write explanations. But enough of my credentials and back to my thoughts.

When I first came to BabylonJS I misunderstood quite a bit as my brain was thinking my way and misinterpreted what was in the tutorials rather than reading them thoroughly. Over time and with lots of help from people on the forum my understanding developed. What I am trying to say is that when you first came across Three either it straight away fitted your thinking or in using it you have developed a way of thinking about how to code in 3D. When you re-write the book using BabylonJS then your 'how to code 3D' and 'applying the underlying concepts' will need to change, albeit slightly

For example parts of the first chapter could become

Creating Spheres
Balls are always called spheres in geometry and in 3D programming. There are two ways to control the shape of a sphere in JavaScript.

Size: Diameter  is 10
The first way that we can control a sphere is to describe how big it is. We
created a ball whose diameter was 10  when we said new BABYLON.MeshBuilder.CreateSphere("ball" {diameter:100).

What happens when you change the diameter to 25?
var ball = new BABYLON.MeshBuilder.CreateSphere("ball" {diameter:25});
var cover = new BABYLON.StandardMaterial();
ball.material = cover;

What happens if you change the diameter from 25 to 1? As you probably guessed, it gets much smaller. So that’s one way we can control a sphere’s shape. What is the other way?

More Chunky: Segments are 8
var ball = new BABYLON.MeshBuilder.CreateSphere("ball" {diameter:25, segments:8});
var cover = new BABYLON.StandardMaterial();
ball.material = cover;

Play around with the numbers a bit more. You’re already learning quite a bit here, and playing with the numbers is a great way to keep learning!

PG to show code above works.

[By the way you will have noticed I am a great fan of MeshBuilder but you could do it just using Mesh]

Some issues that arise

The need for a scene

Obviously a scene is necessary for meshes to belong to. In your first book using Three meshes are explicitly added to a scene using scene.add. In BabylonJS using the scene-less code at some point in the book the following paragraph

Quote

Once we have a mesh, we add it to the scene. The scene is where the magic happens in 3D programming. It is the world in which everything takes place. In this case, it ’s where our ball is hanging out, waiting for some friends. Let’s add some other shapes to the scene so that the ball isn’t lonely.

would need to be replaced with something like

Shapes or meshes do not just hang around nowhere, when they are created they are added to the scene. This line is where the scene was created var scene = new BABYLON.Scene() and every time you create a mesh it is added to the scene for you. The scene is where the magic happens in 3D programming. It is the world in which everything takes place. In this case, it ’s where our ball is hanging out, waiting for some friends. Let’s add some other shapes to the scene so that the ball isn’t lonely.

OR you put scene back in the code

var ball = new BABYLON.MeshBuilder.CreateSphere("ball" {diameter:25}, scene);
var cover = new BABYLON.StandardMaterial("cover", scene);
ball.material = cover;

and say

 The scene is where the magic happens in 3D programming. It is the world in which everything takes place. Whatever things we create have to be added to this world by telling them which world to join. In this case, it ’s where our ball is hanging out, waiting for some friends. Let’s add some other shapes to the scene so that the ball isn’t lonely.

Next issue

On 25/02/2017 at 4:15 AM, eee-c said:

The Vector3 thing that I'd like is, given a time, to write: object.position.set(t, 2*t, 3*t) or object.rotation.set(2*t, t, 0).

  The main point being I presume is to avoid explaining about vectors. You could get over this by using position.x = , position.y = , position.z =  but I can see the advantages of .set()

You will see that in this PG I have added a prototype function to Vector3 that allows you to use .set() on Vector3 objects, you would possibly need to do this for other objects such as Vector2 and Color3 depending on the scope of the book. As it seems you will be loading BabylonJS into gamingJS.com then you could add the prototypes into your version of BabylonJS. Of course then you would need a section to explain how if they were going to use BJS elsewhere how they would actually use position and rotation. Unless of course you could persuade Deltakosh that it was worth adding into BJS26. 

If I was able to understand typescript I would submit a PR and see if DK would accept it but I am more likely to do damage to the code than add something useful.

Sorry to go on a bit just ignore if not useful or you have already though of all this.

 

[GameMonetize]

I'm always looking for ways to simplify the usage of Babylon.js. @JohnK I'll be more than happy to do the TS part of your code.

For instance, I've just added set to all basic types: https://www.babylonjs-playground.com/#IEGEV#5

Please keep sending ideas to reduce any friction with the API  (Without breaking changes of course)

 

[eee-c]

@JohnK If I'm able to use Babylon, I think I'd skip any mention of scene in the first chapter. I didn't mind using it with Three.js because it was a low-overhead concept for kids to grasp. But all things being equal, I'd be more than happy to leave it until a later chapter. 

The book uses a simplified code editor that comes with several starter templates. Those templates do a little setup -- scene, camera, lighting -- then place a big comment that says "START CODING ON THE NEXT LINE." The setup is lightly commented in case kids are curious, but the main focus of the early chapters are core concepts of shapes, animation, grouping/frame of reference, etc.. There's a later chapter that describes all the stuff above the "START CODING" line. 

Anything that helps me avoid concept overload -- like default scenes -- is awesome by me.

The rest of what you describe is very similar to what I have in the Babylon branch of the book right now. It could certainly work

And huge thanks for +1 to `set()` and to @Deltakosh for making that happen. That's exactly how I'd like to use it!

-Chris