4 ms·

As one of the linked articles is based on Three.js . It's like a plague that simple 3D examples and tutorials almost always features that Three.js library inste

by frik 11y ago

As one of the linked articles is based on Three.js . It's like a plague that simple 3D examples and tutorials almost always features that Three.js library instead of "vanilla" Javascript with WebGL. People should learn WebGL and JS first and later decide if such a library is even suitable for their usecase (known to be slow). It reminds me of 2-3 years ago, where almost every Javascript tutorial was littered with JQuery library function calls. Most Stackoverflow questions were answered with JQuery answers. In the meantime things have obviously changed for the better. With Three.js it's still extreme, there are even several books with "WebGL" in the title that cover only or 90% of the content Three.js. In the meantime organisations like Mozilla could start and ditch Three.js in favour WebGL. It would be in common interest of everone.

k__ 11y ago
JQuery was the way to go, because of API differences, so it was easier to write one example in JQuery than 5 in Vanilla JavaScript. WebGL is probably very hard to do in Vanilla JavaScript, so people are using Three.js...
xixixao 11y ago
Great analogy, wrong resolution. The situation is like jQuery, because WebGL is a TERRIBLE API for any but the most low level drawing code (remember, it's not even a 3D API, just a drawing API to interact with the graphics hardware). What will hopefully happen, as did with jQuery, that people will lean down the original and come up with better ways of doing the same (React3D(tm)). Where this analogy doesn't work is that jQuery mainly united the broken implementations across browsers, which is not a big problem with WebGL. So unless there is a committee for a higher level 3D graphics API we can't expect much from the browsers themselves.
- __jack__ 11y ago
  Just because webgl has a more complex api compared to others in the browser world it doesnt mean that it is a terrible api. Its flexible, because you know its not a 3d api, its a 2d one flexible enough to be use for everything from 2d to 3d.
phoboslab 11y ago
I'm not a fan of using libraries for simple examples either, but WebGL just requires tons of boilerplate even for the simplest stuff. If you just want to show a pixel shader, you probably don't need any library. Still, creating textures, setting up the buffer for your single quad, compiling pixel and vertex shaders and the shaders themselves will easily pile up to a good 100 lines of code. Now, if you want to do anything with real 3d objects, such as in this example, you need code to: - generate or load the models - set up your camera - trace clicks on the canvas to the objects (not a simple feat in 3d space) - implement this mover widget/drag+drop of objects - implement some sort of lighting - implement some sort of shadow rendering, so it's easier to estimate the position of the objects - (for all of the above) implement a library for vector and matrix math You'll easily end up with a thousand lines of code there, and you haven't done anything yet to solve the actual problem this article discusses.
greggman 11y ago
I respectfully disagree. I write raw WebGL but I also have written 6 game engines. I'll never do that again. I just want to get shit done. That means for a game I'll start with Unity or Unreal. Similarly for 3D most people just want to get shit done. In that case Three.js is a great way to to just get stuff done. There's man years of work to do to a full 3d engine. You can easily spend a couple of man years just writing exporter/importers and trying to get every little piece of data out and into some meaningful way into your engine. People spend years making rendering systems and shader combiners and post processing system. I'm not saying three.js is perfect but at least at some level much of that is already in there. Why should anyone skip all of that? Just to make years of extra work for themselves? If you want to do raw WebGL then go for, but don't push that on others. To me that's like someone saying "you should write in assembly language". No, I'll choose something that provides existing solutions so I can move on to my actual content instead of re-inventing the wheel.
- wtetzner 11y ago
  That's fine, but he makes a valid point about tutorials whose title makes it sound like it's a WebGL tutorial but mostly cover Three.js. It's like finding a tutorial about assembly, and having it be about C.
  - ladybenko 11y ago
    Hi, I'm the author the post. I agree that it is important to know how things work without 3rd party helpers, regardless of whether you'd use a game engine / library later or not. However, the post on the Hacks blog presents some articles and demos we created for the MDN and IMHO the title is appropriate, since one of the two articles introduced (https://developer.mozilla.org/en-US/docs/Games/Techniques/3D_collision_detection https://developer.mozilla.org/en-US/docs/Games/Techniques/3D...) is generic and it's about algorithms in raw JavaScript. I just thought there would be value too in showing how to do collision detection using one of the most popular 3D graphics library and a physics engine as well, since that would be the most common case when people are developing games (versus making an engine)
    - 11y ago
criticalthnk42 11y ago
They are showing off collision detection, not teaching you how to write OpenGL ES applications for the web. Take a low level graphics course, or write your own tutorial about this, and get back to us about how much time you actually want to spend setting up buffers for textures and vertices and normals and indices etc. and dealing with a low level state machine. They even have "hack" in the title of their site, like they are hacking it together.

by frik 11y ago

k__ 11y ago

JQuery was the way to go, because of API differences, so it was easier to write one example in JQuery than 5 in Vanilla JavaScript. WebGL is probably very hard to do in Vanilla JavaScript, so people are using Three.js...

xixixao 11y ago

Great analogy, wrong resolution. The situation is like jQuery, because WebGL is a TERRIBLE API for any but the most low level drawing code (remember, it's not even a 3D API, just a drawing API to interact with the graphics hardware). What will hopefully happen, as did with jQuery, that people will lean down the original and come up with better ways of doing the same (React3D(tm)). Where this analogy doesn't work is that jQuery mainly united the broken implementations across browsers, which is not a big problem with WebGL. So unless there is a committee for a higher level 3D graphics API we can't expect much from the browsers themselves.

__jack__ 11y ago
Just because webgl has a more complex api compared to others in the browser world it doesnt mean that it is a terrible api. Its flexible, because you know its not a 3d api, its a 2d one flexible enough to be use for everything from 2d to 3d.

phoboslab 11y ago

I'm not a fan of using libraries for simple examples either, but WebGL just requires tons of boilerplate even for the simplest stuff. If you just want to show a pixel shader, you probably don't need any library. Still, creating textures, setting up the buffer for your single quad, compiling pixel and vertex shaders and the shaders themselves will easily pile up to a good 100 lines of code. Now, if you want to do anything with real 3d objects, such as in this example, you need code to: - generate or load the models - set up your camera - trace clicks on the canvas to the objects (not a simple feat in 3d space) - implement this mover widget/drag+drop of objects - implement some sort of lighting - implement some sort of shadow rendering, so it's easier to estimate the position of the objects - (for all of the above) implement a library for vector and matrix math You'll easily end up with a thousand lines of code there, and you haven't done anything yet to solve the actual problem this article discusses.

greggman 11y ago

I respectfully disagree. I write raw WebGL but I also have written 6 game engines. I'll never do that again. I just want to get shit done. That means for a game I'll start with Unity or Unreal. Similarly for 3D most people just want to get shit done. In that case Three.js is a great way to to just get stuff done. There's man years of work to do to a full 3d engine. You can easily spend a couple of man years just writing exporter/importers and trying to get every little piece of data out and into some meaningful way into your engine. People spend years making rendering systems and shader combiners and post processing system. I'm not saying three.js is perfect but at least at some level much of that is already in there. Why should anyone skip all of that? Just to make years of extra work for themselves? If you want to do raw WebGL then go for, but don't push that on others. To me that's like someone saying "you should write in assembly language". No, I'll choose something that provides existing solutions so I can move on to my actual content instead of re-inventing the wheel.

wtetzner 11y ago
That's fine, but he makes a valid point about tutorials whose title makes it sound like it's a WebGL tutorial but mostly cover Three.js. It's like finding a tutorial about assembly, and having it be about C.
- ladybenko 11y ago
  Hi, I'm the author the post. I agree that it is important to know how things work without 3rd party helpers, regardless of whether you'd use a game engine / library later or not. However, the post on the Hacks blog presents some articles and demos we created for the MDN and IMHO the title is appropriate, since one of the two articles introduced (https://developer.mozilla.org/en-US/docs/Games/Techniques/3D_collision_detection https://developer.mozilla.org/en-US/docs/Games/Techniques/3D...) is generic and it's about algorithms in raw JavaScript. I just thought there would be value too in showing how to do collision detection using one of the most popular 3D graphics library and a physics engine as well, since that would be the most common case when people are developing games (versus making an engine)
  - 11y ago

criticalthnk42 11y ago

They are showing off collision detection, not teaching you how to write OpenGL ES applications for the web. Take a low level graphics course, or write your own tutorial about this, and get back to us about how much time you actually want to spend setting up buffers for textures and vertices and normals and indices etc. and dealing with a low level state machine. They even have "hack" in the title of their site, like they are hacking it together.