Simplifying the Interface
Andor Salga | 23 January, 2010 | 17:37
Something we need to do is simplify the C3DL library interface. When approaching such tasks, one method I found extremely useful was to analyze the code in terms of the interface, or that is from the user’s perspective. To do this I first created a basic demo of a spinning cube by writing the necessary HTML and JavaScript files. As for the HTML, it will need to be something like this:
(I emphasized the code which potentially could be changed)
Now, very few changes were made here and it will probably require a significant amount of effort to make it work. But this work is justified by the fact that the user’s experience and first impression will be more positive. If the user has to spend more than a few minutes trying to get a simple example to render, they’ll probably look for alternatives.
Let’s see how the JavaScript could be changed. Right now, you need to write something like this:
(Again, I emphasized the code which potentially could be changed)
For example, if we change OpenGLES20 class to Renderer, the user will no longer need to be concerned what underlying rendering method is used. If a visitor loads the user’s demo, but visitor’s browser doesn’t support WebGL (i.e. it’s I.E.), the demo still loads. This of course only works if we accommodate for this case. So if the browser is IE, we use DirectX. If the browser supports WebGL, we use that. The end result is the user’s page will create the appropriate renderer without them needing to worry about the user’s browser. So let’s look at what lines changed:
(I emphasized the code which potentially could be changed)
<html>
<head>
<title>Cavas3D Demo</title>
<script>var SCRIPT_PATH = '../../canvas3dapi/'</script>
<script src="../../canvas3dapi/c3dapi.js"></script>
<script src="basic_demo.js"></script>
</head>
<body>
<canvas id="demo" width="500" height="500"></canvas>
</body>
</html>
It would be great if this could be simplified to something like this:
<html>
<head>
<title>Cavas3D Demo</title>
<script src="../../canvas3dapi/c3dapi.js"></script>
</head>
<body>
<canvas datasrc="basic_demo.js" id="demo" width="500" height="500">
</canvas>
</body>
</html>
I removed the somewhat unintuitive SCRIPT_PATH variable and moved the basic_demo.js resource into the canvas tag making it more obvious which .js file is associated to which canvas. These changes haven’t actually been made, I’m just playing with possible changes, brainstorming which parts might be able to be modified.Now, very few changes were made here and it will probably require a significant amount of effort to make it work. But this work is justified by the fact that the user’s experience and first impression will be more positive. If the user has to spend more than a few minutes trying to get a simple example to render, they’ll probably look for alternatives.
Let’s see how the JavaScript could be changed. Right now, you need to write something like this:
(Again, I emphasized the code which potentially could be changed)
c3dl.addModel('cube.dae');
c3dl.addMainCallBack(mainDemo, 'demo');
function mainDemo(canvasName)
{
var scn = new c3dl.Scene();
scn.setCanvasTag(canvasName);
var renderer = new c3dl.OpenGLES20();
scn.setRenderer(renderer);
scn.init();
var cam = new c3dl.FreeCamera();
cam.setPosition([0,0,50]);
cam.setLookAtPoint([0,0,-1]);
var cube = new c3dl.Collada();
cube.init('cube.dae');
cube.setAngularVel([0.001,0.001,0.0]);
scn.addObjectToScene(cube);
scn.setCamera(cam);
scn.startScene();
}
Some changes I had in mind involved getting rid of the global c3dl.addModel() and c3dl.addMainCallback() calls and changing OpenGLES20 to just Renderer. The Renderer is an interesting problem. When WebGL started out as Canvas3D, we called the renderer OpenGLES11, then later it became OpenGLES20 and now it could probably be WebGL. Considering how much it has changed and will change, we’ll have to invest some time to make this stop. One simple solution is to abstract the renderer.For example, if we change OpenGLES20 class to Renderer, the user will no longer need to be concerned what underlying rendering method is used. If a visitor loads the user’s demo, but visitor’s browser doesn’t support WebGL (i.e. it’s I.E.), the demo still loads. This of course only works if we accommodate for this case. So if the browser is IE, we use DirectX. If the browser supports WebGL, we use that. The end result is the user’s page will create the appropriate renderer without them needing to worry about the user’s browser. So let’s look at what lines changed:
function mainDemo(canvasName)
{
var scn = new c3dl.Scene();
var renderer = new c3dl.Renderer();
scn.init(renderer);
var cam = new c3dl.FreeCamera();
cam.setPosition([0,0,50]);
cam.setLookAtPoint([0,0,-1]);
var cube = new c3dl.Collada();
cube.init('cube.dae');
cube.setAngularVel([0.001,0.001,0.001]);
scn.addObjectToScene(cube);
scn.setCamera(cam);
scn.startScene();
}
In terms of the lines trimmed, I’m not certain how much of it is viable. The reason some of the seemingly redundant code is required was because I couldn’t devise any alternative at the time. Looking at it from a different perspective, I should be able to come up with something. In the end we’ll have an interface which is more flexible, easier to understand and of course simple. 
Hi, something you need to do is - RELEASE! personally, i
fishbone | 23 January, 2010 | 20:32Hi,
something you need to do is – RELEASE!
personally, i have switched to GLGE, because my system does not support Canvas3D. Consider, that i have not switched to GLGE because of the complex interface, but due to the dependency on WebGL.
Your library is really great stuff! I really hope, that WebGL
Sascha Hendel | 29 January, 2010 | 6:24Your library is really great stuff!
I really hope, that WebGL finds his way to all of the common browsers soon.
My additional tip for a better user experience of C3DL:
(together with a Canvas3D plugin for the current FF 3.6)
Right now every demo has it’s own copy of the c3dl library (and most of them are slightly different). This is quite confusing. Please try to link all the demos to one (regulary updated) version.
Indeed a version with automatic Canvas3D Plugin/WebGL switch would be perfect
Sascha
I agree with both comments above. When we were
Cathy Leung | 29 January, 2010 | 8:54I agree with both comments above. When we were working with Canvas 3D testing was a lot simpler because it really was only one browser. Switching to multiple browser system has been more diffcult than anticipated and its really where most of the holdup is for us. However, having said all that, we are going to very soon releasing an actual webGL release. At that point we will be swapping all our webGL demos to that version and basically moving over to that.
As for Canvas 3D plugin for FF3.6 I don’t think there is going to be one as Vlad’s been actively working on making sure all of it is compatible with webGL for FF3.7. However, I think it may be possible to modify the old 0.4.3 addon for Canvas 3D so that you can use it for FF3.6. Let me ask around about that.