• Content Count

  • Joined

  • Last visited

About eee-c

  • Rank

Contact Methods

  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @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
  2. @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 ( 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: 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
  3. 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
  4. 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