3D web page lessons

[Charles Pegge]

WebGL: Including some of the well known Nehe OpenGL tutorials

http://learningwebgl.com/blog/?page_id=1217

[zak]

thanks, this is a great demos, i have used Chrome v12.0.742.122

[Petr Schreiber]

Thanks Charles,

very practical tutorials!

I am quite curious about the future of WebGL, when I watch 3D content online, it is still mostly based on Java or Unity plugin, WebGL being seen mostly in tutorials and proof of concept demos.


Petr

[Charles Pegge]

Hi Petr,

This article makes the case for WebGL.

http://www.irrlicht3d.org/pivot/entry.php?id=1255

and this is the case against

http://www.extremetech.com/computing/87696-webgl-is-fundamentally-flawed

[kryton9]

Thanks Charles for the links.

[Petr Schreiber]

Charles,

both articles are very interesting. Regarding the security - I think it poses similar risk as downloading "normal" software from web. The internet itself has never been safe place at any moment in time I am afraid. That is not the reason to make it even more vulnerable :), but my point is that the risk with WebGL is not any higher than with already existing Flash/Unity based applications. Where I see real danger is general purpose computing on GPUs. While OpenGL or Direct3D app didn't managed to crash or freeze my PC for long time, little mistake in OpenCL kernel can still do that very easily :D

As of being locked to JavaScript = low performance, this is something very subjective. I have running apps on the robot with Atom processor, written in ThinBASIC and using OpenGL based TBGL library there.
One would say low power CPU + interpreted language = recipe for horrible performance, but it is not the case, it does not even block the robot in low level messages processing.

So it is more question of application design and choices of what to offload to GPU and what to let on the CPU side where the interpreter runs.

While I looked at WebGL many times, I still do not see much need for 3D graphics on the web for applications with user controlling the interface mostly with mouse, and I consider myself a 3D freak :)

Where I see big undiscovered space is case of touch screens - maybe with the rising appearances of tablets, the GUI design might finally experience some kind of step further.
When I have some spare time, I play with this idea at work on robot's 19" touch screen. Nothing special discovered yet, but I somehow feel that if this would be examined for some time, some interesting ideas and new concepts of usage could appear.


Petr

[zak]

Petr
Where I see real danger is general purpose computing on GPUs. While OpenGL or Direct3D app didn't managed to crash or freeze my PC for long time, little mistake in OpenCL kernel can still do that very easily
do you mean that in OpenCL a certain code can damage the card hardware ??. i suspect from long time that some sites on the web can force the cpu to whirl like a tornado then damaging it physically. a site do that for me years ago, i don't remember its address.

[Petr Schreiber]

Hi Zak,

not to damage hardware, but to put computer into state you need to plug it out of electricity = loose any other open work. It happened on daily basis when working on my thesis in 2009, the situation seems to get better, but I still use OpenCL for offline data processing.

The problem is caused mostly by human factor -> programmer supplies code with error, the OpenCL compiler gets puzzled and the result is dangerous. This will disappear with better OpenCL implementations in future of course.

This issue is not present on Windows 7, where only the GPU is restarted in such a case, but on XPs it is a problem.


Petr

[Charles Pegge]

It sounds like a video card vulnerability, where the GPU itself has gone loopy and has to be reset. Even if everything else in the PC is unaffected you would still have to perform a restart or even disconnect the power to regain control.

Petr, what would be involved in generating webGL scripts from TBGL scripts ? :)

Charles

[matthew]

For anyone having problems enabling WebGL in Google Chrome using Windows XP - I suggest visiting this (http://t.co/niBsZO4p) page on the Google Help Site & reading the Top Solution. (It worked for me)


Petr, what would be involved in generating webGL scripts from TBGL scripts ? :)

Charles
It would be very interesting to see what could be achieved if it's possible. :)

[Petr Schreiber]

Petr, what would be involved in generating webGL scripts from TBGL scripts ? :)


Few times a year I run into this idea and then leave it, because as I said earlier, I don't see much use for GL on the web yet...

But from technological point of view:

The most comfortable would be to take script as is and convert it to JavaScript + WebGL. That means create JavaScript emitter from ThinBASIC script.
The second step would be to re-create the basic matrix handling functionality. As WebGL is strongly connected with OpenGL ES, it does not have for example direct equivalents of useful stuff like TBGL_Translate/TBGL_Rotate/TBGL_Scale
The third step would be to do smart re-interpretation of TBGL_BeginPoly/TBGL_EndPoly blocks to vertex arrays, as WebGL again does not have the intuitive immediate mode
The fourth step would be to recreate the state handling mechanisms, some are supported in WebGL, some not
The fourth step would be to re-create the entity system


The most straightforward is to port the most highlevel part, which is the entity system. But once diving deeper, it get's a bit ugly :)

To explain more in detail why I don't wish to spend much time on this porting, it's the right time to introduce...

Petr's slightly depressing theory of real time accelerated graphics APIs evolution
During the years, I developed simple theory about the evolution of APIs for fast rendering, speaking both about the two main players, which are Direct?D and OpenGL.
In my opinion, the evolution so far follows the SIN() function on the interval [0, PI].

The X equals to time.
The Y equals to programmers comfort.

The point 0
During the first appearance of implementations of graphics APIs for mainstream developement, it was almost as big pain to write software rasterizer as use hardware accelerated graphic API. The advantage of the second approach consisted only in slight speed increase. The limitation was only few people actually had the hardware, and fraction of them the really usable one :)

The point PI/4 - going up
At this point, the hw accelerated APIs started to provide well structured interface for programming, so the coder starting new project had choice to:

build software rasterizer from scratch

+ maximum freedom regarding the output
- quite a big performance penalization for more complex graphic effects, in the end making possible to supply game with just few features


pickup the existing hw accelerated API with the most essential functionality pre-defined, so he could concentrate on the coding

+ rapid initial setup, no need to fight with the basic matrix calculus or geometry definition
- when you want more advanced features, you are mostly in trouble, the API is still limited



The point PI/2 - top form
Here the hw accelerated APIs discovered the power of data-parallel processing and concept of shaders. So the ballance of power looked like:


building software rasterizer stops making much sense, we are in situation even the integrated videocards support some graphic API and shaders at least in basic level
pickup graphic API is straightforward, one can code the basic application the old way, and/or go for the shaders for custom great unique effects


The point of going from PI/2 to 3/4*PI - the madness begins
Here we start to see the APIs become more and more trying to match the actual hardware features (and everyone is happy, because we get speeeeeed) in close detail. The geometry definition splits from one way to 4 (immediate mode, vertex arrays, vertex buffer objects, geometry emitting shaders). But it is still possible to combine the comfortable approach with flexibility of shaders.

The point of going to PI
The programmer comfort is completely ignored, the predefined libraries for matrix or state handling are purged, only helper remaining is vector calculus in shaders. Programmer is required to handle almost everything on his own, so here we are getting to the beginning, where we have to do all the work ourselves.

What a sad end for our fairy tale, isn't it?

The realistic way
In my point of view, the usable API would be something like TBGL (with some purification, for example tbgl_beginPoly/tbgl_endPoly internally retargeted to vertex array/vertex buffer object/... automagically) with custom general purpose shader syntax not bound to GLSL specs, emitting directly assembly shaders, which run good even on Intels.

The "ideal" way
The other approach would be to go completely crazy, design new API not bound by OpenGL or Direct3D, which would have general purpose syntax, with single way to do everything and very smart compiler/preprocessor, which would internally retarget the result not to OpenGL/Direct3D like API, but to general parallelism aware "something", which would nicely scale to run both on mutliprocessor stations or powerful GPUs.

I think the OpenGL started in really nice hardware independent fashion, then Direct3D appeared doing the opposite, then OpenGL started to chase the Direct3D and that was the start of the wrong direction.

From what I wrote, it seems we are in desperate situation now. That is not true, from certain point of view we have more possibilities than ever with OpenGL 4.x, Direct3D 11.x. Just the way to get the results is like going back to assembler.


Petr

[Charles Pegge]

Hi Petr,
I did not realise how different OpenGL ES2 is from the original Opengl desktop. So much has disappeared! It is hard to concieve of any scheme that would bridge the gap.

[kryton9]

Petr, your analysis was very enlightening and entertaining to read. I had similar feelings but no way to express them. You did a great job. It sure seems that way. Perhaps that new graphics system being developed in Australia of infinite detail will bring back a user friendlier system.

[Charles Pegge]

Collada is very comprehensive - covering all declarative aspects of 3D.

The forum is very small though, considering it has been in operation since 2004

http://www.khronos.org/collada/