Hacker News Reader

Comment by frik | Hacker News Reader

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.

View on HN

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.

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.

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...) 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)

Just to be clear, I wasn't suggesting anything was wrong with your post (especially since it's about collision detection), just that there was valid point made in general.

I agree that if the thing you're trying to show is "Here's bounding volumes and intersections in 3D", then the Three usage just cleans up a secondary implementation detail. However, it seems to be rare that people will write "Oh, and the drawing part is just for visualization, ignore this code because it's convenient".

The problem with the wide spread of Three is that it is some crazy sprawly combination of utility library, engine, and framework, and that it encourages a particular worldview on new graphics programmers that don't have any understanding on how the underlying hardware or math works.

It's useful in the hands of somebody that already knows that stuff, but harmful from a pedagogical point of view.

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.

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.

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.

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.

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...

Reply on news.ycombinator.com