GTC: Progress report & latest API problem (help!)

[Sebastien Loisel <Sebastien.Loisel@Eng.Sun.COM>]

Ok, here's what I've been up to. I will check that code into the CVS repository 
in a few minutes.

Status
======

* Scene Graph: Everything seems to work fine now.

* Networking: now I have a browser-type client, ie, it is independant of the 
game server. We could distribute a binary separately from the library 
(especially if we statically link like we do now). Further work is needed to 
lighten the bandwidth requirements. First we should try to make more compact 
encodings of the existing scene graph node types that already exist, later we 
can try to exploit frame-to-frame coherence.

* Resource management: there's a piece of code for loading a configuration file 
that lists a bunch of resources to load (meshes, texture, etc...) They are 
loaded into an array and the array is primed to be used in the scene graph. 
These resources are assumed to be available on both the server side and the 
client side thus they are not transmitted in the networking layer. The resource 
management layer lets you make loaders for various resource types, as of yet I 
only have 3ds .asc files and .ppm files for textures. I will add .ale tonight 
(the 3dsmax human readable file format, replaces .asc).

* 3ds file loading: Will Newton just told me he's making good progress.

* Flyingducks: now I want to make this a real game.

* Meshes: we need someone to provide us with meshes. I contacted Jussi 
Saarivirta <jusas@jusas.dhs.org> and he will be helping us with this; he's 
already given me a .ale file for a low polycount starfighter.

* Modeller: Extreme Wave may relocate to seul.org. I've been keeping in touch 
with James Dean Palmer. From what he tells me, the next version of ewave will be 
good for us, and he is expecting to release it soon.

* Documentation: the current state of the doc subdirectory is very bad; all the 
documentation dates back to the beginning of the summer and so doesn't have much 
to do with the current library. I will re-write it soon.

API Woes
========

I need help on this one. Please tell me what you guys think. As you know, I've 
had some collision detection in the library for a while now. When I first 
implemented it, the scene graph was flat (I did not expect anyone would want a 
non flat scene graph). Recently, I moved to a more generic scene graph API, the 
main reason was that it facilitated networking. However, this complicates the 
collision detection picture.

Collision is divided into two steps.

1- The first is an all-pairs pruning test. You have N objects flying around in 
space (eg, 20 flying ducks) and you don't want to test all N(N-1)/2 pairs (there 
are 190 pairs of flying ducks to check). I made bounding boxes and use a twisted 
algorithm to prune down the number of pairs of ducks I need to check (using some 
sort of separating plane thing).

2- Once we've pruned the pairs, a more precise test needs to be applied to each 
remaining pair. This would be a mesh-to-mesh collision detection algorithm. I 
use an AABB tree based approach.

Now that I have a scene graph, I am no longer certain what is meant by "number 
of objects". Usually a scene graph has at the root a grouping node (in GTC, a 
Scene node, VRML would be Group). Each child of the grouping node will typically 
be a change of coordinate node (in GTC, an Xform node, VRML would be Transform), 
each of which has a single child which holds some geometry (in GTC, a Mesh node, 
in VRML, an IndexedFaceSet or something). In a non-flat scene graph, there may 
be Scene (viz. Group) sub-nodes.

As it is now, I take the root Scene node and for each child, I put a bounding 
box around it and perform pruning on that level. The alternative would be to get 
all the leaf (geometry) nodes and perform an all-pair pruning on that instead.

The other problem is naming. If the scene graph were a tree then I could 
indicate which objects collide by passing a pointer to each. However, the scene 
graph is not a tree. In the flyingducks demo, there is only one gtcSGMesh object 
for the ducks. So the scene graph looks like this:

                     -> gtcSGXform -
                    /               \
gtcSGScene (root) -+--> gtcSGXform --+-> gtcSGMesh (duck)
                    \               /
                     -> gtcSGXform -

This scene has three ducks flying in space. So to identify each duck uniquely, I 
would have to list the order of traversal of the scene graph. I do not think 
that there is any other way to do this, tell me if I'm wrong.

So the main question is, should I flatten the scene graph for collision 
detection? (I would tend to say yes, though I cringe at the thought.) If the 
answer is no, then I don't understand how to do step two of the collision 
detection algorithm.

If you don't understand what I just said but think you can help, e-mail me.

Scripting
=========

Scripting will be the Next Big Thing on the ToDo list. I want to make 
flyingducks into a real game and I intend to put as much stuff as reasonable in 
the library in the process. Most definetly, scripting is super important for 
this. I intend to use CORBA to export the library's facilities.

Sound
=====

Now we need to decide what we'll do for sound. I've been promising that I'll 
keep sound out of the library but I think I may have lied, at least partially. 
The browser needs to be able to make noise. Since the browser is independant of 
the game, that means the networking layer needs to be able to tell the browser 
about sounds to play. Therefore, I will include some conditional compilation 
options into the browser to link into MikMod if available. The server side 
doesn't need to know how to access sound hardware so in that sense, the library 
still won't be about sound.

Sebastien Loisel -- McGill University -- Sun Microsystems
http://www.math.mcgill.ca/~loisel/

*************************************************************
To unsubscribe, send an e-mail to majordomo@gtc.seul.org with
unsubscribe gtc-dev       in the body. http://gtc.seul.org/