Re: GTC: Some Online Docs

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

> I've been thinking a lot about higher grounds
> aspects of GTC. I'm putting two documents online
> so you can share some of my thoughts.

I just looked them through.

> As you will notice in both docs, my biggest
> concern is API design and easy of use. I don't
> know if other collaborators share this concern
> with me, but I really hope so.

Yes, I want to make a useful and simple API. I also want the library 
to be efficient and cutting edge. You don't think we can do all at 
the same time but I believe it can be done.

There are certain specialized area which are hard to implement in a 
generic way. For instance, it's a little hard to see how a PVS maze 
fits with a scene graph API. How do you check for visibility of 
nodes in the graph? What if there are more than one PVS objects in 
the graph?

I've also noticed that genericity also fights against usability, the 
more general I try to be, the harder the library seems to be to use. 
I've managed to keep usability good (I think) so far, however a rift 
is bound to occur in the future.

I have a plan to keep GTC usable. When it becomes harder to use the 
library, I plan to introduce an easy-GTC layer which will present a 
simplified API where most of the stuff still works (a bit like 
GLUT). In addition, I want to have language bindings for higher 
level and scripting languages. I assume that higher level language 
bindings will also help make GTC more usable.

So that's my solution for usability.

The remaining duel is between genericity and efficiency and this one 
will not so easily be fixed. I think I aim to get a very good 
compromise, a way to do things without closing too many doors. My 
first goal is to get space shooters and racers working. Once that 
works, I want to move to FPS and CRPG so we will need PVS, fractal 
terrains and so on. If we can integrate this into the generic 
engine, we will have a very powerful, flexible and efficient beast.

> The first doc is a draft (in its very childhood)
> of the scene graph module, one of the most important

Yes, what you write is very similar to what I just implemented over 
the weekend. There's a small tweak for networking purposes. Each 
node in the scene graph gets assigned a res_id, which are meant to 
identify the type of the node. For instance, a grouping node has a 
res_id of 1, a mesh node has a res_id of 3 and a xform node has a 
res_id of 5. There is also a repository of static scene graph 
pieces. If you have a mesh that will not be changing (the duck mesh 
I use in flyingducks, for instance) then you can give it its own 
res_id and put it in an array of static mesh nodes. Then you can 
insert such a mesh node anywhere in the tree. Such nodes will always 
have an even res_id number. The purpose of this is for optimizing 
networking code, and also possibly for saving/loading scene graphs. 
The networking code works by traversing the scene graph and 
generating a binary encoding of it. If an even res_id is reached, 
that subnode is not encoded, only its res_id is transmitted. I put 
this in when I was migrating some networking code from the demos to 
the library, I needed a way to tell the networking code to stop 
recursing (otherwise the packets are huge). In the future, I plan to 
have the lower several bits of the res_id serve for flagging 
purposes.

The networking code always encodes scene graphs as trees. If the 
scene graph is not a tree (ie, node A is the descendant of more than 
one node in the graph) then the networking code will not notice 
this. Being able to handle this will be a future improvement. One of 
the lower bits of res_id could be reserved to say that this node 
should be a reference to a previously given node. I do not plan to 
ever have an explicit identifier for the objects in the scene graph, 
an implicit id number is assigned by preorder traversing the scene 
graph (which is the order in which nodes are sent anyhow).

The res_id is encoded using a variable length coding. I do not 
believe we will need to go to a bit encoding scheme like mpeg4 to 
get acceptable bandwidth use. However, if this is needed, the 
framework is there to do so.

Regarding your scene building questions, there's no substitute for a 
good modeller and I've been yearning for this myself. Right now 
we'll have to bank on E-Wave. Will Newton has agreed to be the 
E-Wave guy (thanks Will) and James Dean Palmer appears to be 
friendly. He's told me he's putting out a new version of E-Wave soon 
and it will have more polygon manipulation facilities as well as 
simple texturing support. With that we should be able to get quite a 
bit of work done. For space shooters, the scene graph is mostly flat 
so we won't be needing a more sophisticated scene graph editor for 
some time.

If we really want to make scene graph in ASCII, we could write a 
VRML loader. I don't have time to work on that though.

Sebastien Loisel

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