Preliminary WebGL RTS Game

Andor Salga | 15 February, 2010 | 17:08
Cathy asked me to make a cool demo using our library. After thinking about, I started getting many ideas, but creating a preliminary real-time strategy game made the most sense. It not only demonstrates a lot of C3DL features such as model loading, transformations, lighting, shaders, picking, cameras, textures, etc, but since animation is kept to a minimum, the frame rate on slower machines shouldn’t be a big deal.

You’ll need a WebGL-compatible browser to run it. You can either download Minefield, WebKit or Chromium. Please let us know if it fails to load. Keep in mind I hacked this thing together in a day so the code isn’t pretty, but here it is anyway!
Comments
1 Comment »
Categories
c3dl development
Comments rss Comments rss
Trackback Trackback

Asteroids in 3D… and a bit of 2D

Cathy Leung | 1 February, 2010 | 6:12
So I’ve been working on this little demo in preparation for the upcoming (very very soon…docs left only) release of C3DL’s webGL release. I adapted it from Peter Callaghan’s Asteroids game and the models were from an old demo made as part of our user testing last year. This demo is kind of cool because it demonstrates many of the features of C3DL and puts it all together in one. Namely it uses:
  • collada model loading – you can export to collada from a good number of modeling programs including blender, 3ds max and google sketchup
  • particle systems – watch the rocks when they explode!
  • lighting – ok… this is not featured well… I’ll try to see if I can do better with it
  • picking – click on rock to identify which one
I will probably add something to that uses the effects system as that is one key component not highlighted. Its not quite done yet but I figured I’d link it anyways since I won’t have time to finish it till probably Wednesday…. I still have to add scoring and end game functionalities, the keys should be changed to a and d instead of using arrows, and I think my health bar is messed up when it drops below 25 but… its a start. I also have not tested well on webkit (there was a bug of constantly rotating ship at one point but have not been able to reproduce it) and I can’t seem to run chrome on my desktop atm so no testing there. This demo uses webGL in the main display and I painted the hud with 2D canvas. Click on the asteroids to shoot them. Use arrow keys to rotate the ship. https://cs.senecac.on.ca/~catherine.leung/c3dl/Asteroids3/asteroids.html NOTE: To see this demo you need a web browser that supports webGL and it must be enabled.
Comments
2 Comments »
Categories
c3dl development
Comments rss Comments rss
Trackback Trackback

Another demo updated

peter | 28 January, 2010 | 16:25

I’ve just finished updating the particle systems demo. There wasn’t anything wrong with the demo itself, but there was an array in the particle system class that wasn’t being initialized properly that suddenly started causing Minefield to crash. The strange thing is that until recently Minefield wasn’t complaining about it. But as of the nightly build on the 23rd it didn’t just complain, it outright crashed. By populating the array with 0s when it is initialized, I’ve got particles working again. The misleading problem was that this happened at the same time I was fixing an issue with colours for Chromium was preventing it from displaying. It started crashing one browser at the same time I fixed a problem for another. It turns out that was caused because colour values were being read out of a file and split into an array, but they were never explicitly made into floating point values. Minefield and Webkit understood them as such anyway, but Chromium didn’t like that. A temporary solution was to multiply the values by 1 before using them, but that isn’t a very good solution. Once I actually traced the problem to its source, a quick parseFloat took care of it. Slightly slower, but more correct.

Comments
1 Comment »
Categories
c3dl development
Comments rss Comments rss
Trackback Trackback

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) 
<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.
Comments
3 Comments »
Categories
c3dl development
Comments rss Comments rss
Trackback Trackback

Updating Demos

peter | 19 January, 2010 | 10:40

I’m continuing to update the demos with the copy of the library that works cross-browser (and will continue to do so). There was a slight delay in the motion capture demo due to the difference in how the browsers read xml files. We had been using:

xmlDoc = document.implementation.createDocument("","",null);
xmlDoc.async = false;
xmlDoc.load(xmlFile);

but Safari and Chrome don’t accept that. After a quick search (ignoring the pages that make it sound more complicated than it is and want to sell you code to take care of it) I found the answer to be quite simple.

xmlDoc = document.implementation.createDocument("","",null);
xmlDoc.async = false;
var xmlReq = new XMLHttpRequest();
xmlReq.open("GET", xmlFile, false);
xmlReq.send(null);
xmlDoc=xmlReq.responseXML;

It ends up as a few extra lines, but it works for all three. This was a problem with the code for that individual page, but it seems to be the kind of thing we can expect when trying to write complex code for multiple browsers.

I’ll be working on the particle systems demo next, as it also has a bit of code that is firefox only.

Comments
4 Comments »
Categories
c3dl development
Comments rss Comments rss
Trackback Trackback

« Previous Entries Next Entries »