3 ms·

three.js is a 3D engine. WebGL is a library that let's you interface with 3D graphic accelerators(rasterizers on steroids). That is it's main purpose. Rasteriza

by Klinky 12y ago

three.js is a 3D engine. WebGL is a library that let's you interface with 3D graphic accelerators(rasterizers on steroids). That is it's main purpose. Rasterization is a fundamental of real-time 3D graphics. I am not sure why people are feeling deceived by finding this out?

fit2rule 12y ago
Its a distinction, not a deception. If I'm going to write a game and I hear about WebGL, I have to make the distinction between where my art gets turned into an asset, and where that asset gets rendered. There is a lot of ground between those two points, and understanding the difference between a library that you can just throw artwork at, and a device-driver layer that expects data in a certain format (or it won't work at all), is where the application/engine/library lines must be drawn in the sand. The author is (imho) correct in pointing this out from the perspective of having produced a tutorial for newcomers to this scene - so far my observation is that those who wish to argue with him about this point seem to want to generalize it into a ball of mystery, as they are more expert and know the territory better. That may well be the case, but use the rear-vision mirror and look at this from a total newbie perspective. You can't just load up Wavefront .obj's into a WebGL instance and expect to get a bouncing ball. You'll need a 3D engine - or library - to do that. There's room in this discussion to fill that void - for the newbie - by using terminology that allows a better understanding than, perhaps, those who understand it all, already, permit/allow/agree to. The distinction seems to have a locus around the data formats - either of the files being loaded, or at the parameter/buffer-object layer. There is quite some territory between an .OBJ vector (for example) and some other vector format that needs to be loaded into buffers and passed over to the hardware device through a driver layer. Where does the physics go? What is a shader for and why bother with it in this context? These questions get answered by having firm terminology: WebGL is not a 3D library, because a 3D library would have some sort of blackbox'ed object loader, maybe a bit of physics/collision-detection too, and so on .. and it may well be an engine which uses WebGL simply as one of a series of front-ends, through a driver layer, successfully too - they're out there.
- overgard 12y ago
  > so far my observation is that those who wish to argue with him about this point seem to want to generalize it into a ball of mystery, as they are more expert and know the territory better. It's the opposite, this stuff is already hard, there's no need to make it more complicated by introducing a distinction that's misleading. > WebGL is not a 3D library, because a 3D library would have some sort of blackbox'ed object loader, maybe a bit of physics/collision-detection too, and so on .. That's a pretty arbitrary cutoff, but all the same: you're describing a 3d engine, not a library. Besides why would you want all that in one library? I'd rather have my mesh loading and my physics be separate libraries so I can have more choices and keep my includes small.

by Klinky 12y ago

fit2rule 12y ago

Its a distinction, not a deception. If I'm going to write a game and I hear about WebGL, I have to make the distinction between where my art gets turned into an asset, and where that asset gets rendered. There is a lot of ground between those two points, and understanding the difference between a library that you can just throw artwork at, and a device-driver layer that expects data in a certain format (or it won't work at all), is where the application/engine/library lines must be drawn in the sand. The author is (imho) correct in pointing this out from the perspective of having produced a tutorial for newcomers to this scene - so far my observation is that those who wish to argue with him about this point seem to want to generalize it into a ball of mystery, as they are more expert and know the territory better. That may well be the case, but use the rear-vision mirror and look at this from a total newbie perspective. You can't just load up Wavefront .obj's into a WebGL instance and expect to get a bouncing ball. You'll need a 3D engine - or library - to do that. There's room in this discussion to fill that void - for the newbie - by using terminology that allows a better understanding than, perhaps, those who understand it all, already, permit/allow/agree to. The distinction seems to have a locus around the data formats - either of the files being loaded, or at the parameter/buffer-object layer. There is quite some territory between an .OBJ vector (for example) and some other vector format that needs to be loaded into buffers and passed over to the hardware device through a driver layer. Where does the physics go? What is a shader for and why bother with it in this context? These questions get answered by having firm terminology: WebGL is not a 3D library, because a 3D library would have some sort of blackbox'ed object loader, maybe a bit of physics/collision-detection too, and so on .. and it may well be an engine which uses WebGL simply as one of a series of front-ends, through a driver layer, successfully too - they're out there.

overgard 12y ago
> so far my observation is that those who wish to argue with him about this point seem to want to generalize it into a ball of mystery, as they are more expert and know the territory better. It's the opposite, this stuff is already hard, there's no need to make it more complicated by introducing a distinction that's misleading. > WebGL is not a 3D library, because a 3D library would have some sort of blackbox'ed object loader, maybe a bit of physics/collision-detection too, and so on .. That's a pretty arbitrary cutoff, but all the same: you're describing a 3d engine, not a library. Besides why would you want all that in one library? I'd rather have my mesh loading and my physics be separate libraries so I can have more choices and keep my includes small.