[vos-d] status and scheming

[Peter Amstutz]

Here's a rundown of the status of development with VOS these days, and 
some design ideas I'm currently working on.

-) Sebastian Malcolm is testing the 0.24-dev branch in bzr.  If things 
work out for him, this will turn into an 0.24 release.

-) 0.24 will be the last release using the current codebase.  
Development has started on a new kernel implementation, codenamed "s5".

-) Lalo Martins is going to be working on Python and Javascript bindings 
between the s5 development branch.

-) I am focusing my efforts on bringing the s5 branch up to speed.  
Because it is largely a ground up rewrite of VOS, there is a lot of work 
still to be done.

-) I need to sit down and write out a detailed design, but the ultimate 
goal of this new version is to provide a language-neutral runtime object 
system that will make it easy to stitch together code in different 
languages running different processes and on different computers.

-) What does this have to do with 3D?  Well, one conclusion I drew from 
s4 development was that it isn't sufficient to just move data around.  
To do anything interesting in 3D requires interactivity, and 
interactivity requires enabling users to easily write their own programs 
and scripts that work over the VOS system.

-) I am currently still bootstrapping the s5 "kernel".  I am working on 
implementing the core API and reflecting the reflection system.  Vobject 
type method interfaces are written in XML.  This interface description 
is loaded at runtime and is effectively a class description.  It is used 
for various purposes, the most important being to generate stub/skeleton 
code that implement marshaling and unmarshaling method calls, and 
binding symbolic methods to actual implementations (where the 
implementation just need to be callable as a C function, and could 
eventually be Python, C++, C#, whatever).  I'm working on writing the 
reflection system in itself, meaning the XML interface file, which is 
loaded into the reflection classes, describes the reflection classes, 
and when run through the code generator generates the reflection 
classes.  This obviously require some bootstrapping :-) Also, the core 
Vobject API is implemented, so you can add/replace/remove child links on 
a vobject.  I have a constantly-growing suite of currently about 100 
unit tests to make sure development stays on track.

-) Once that is done I will have a choice.  Either a) continue working 
on backend stuff, such as implementing networking, persistance and 
caching components, or b) take the capabilities of the basic kernel and 
(hopefully) scripting bindings and work towards piecing together the 
next generation of the browser application (it might be time to retire 
the name Ter'Angreal, as well ... it confuses people).  Now, this is a 
difficult decision.  On the one hand, VOS without the networking means 
we don't have multiuser, which is a very basic part of the "VOS vision".  
On the other hand, 3D graphics are pretty, and will tend to attract 
users.  A scriptable 3D environment, while not unique, is still a very 
cool piece of technology, and I think there will be interesting aspects 
to the VOS runtime environment that go beyond what you would get from, 
say, PyOgre.  Also, it will give the runtime kernel a real user quicker, 
so API and performance issues can be caught and addressed earlier.  
(Although conversely, designing the 3D app without a network could also 
be dangerous).

I'm not talking about writing the whole 3D browser, just a demo browser 
app that show basic geometry and support scripted interactions.

-) As part of the design, I came up some ideas that I wanted to mention.  
I was thinking about how to implement animation, and a couple of things 
occurred to me.  Animation loops specify a some set of actions 
parameterized by time; when you trigger a loop as part of the larger 
simulation, the "world" time is plugged into the animation data as the 
time parameter to generate the actual frames.  What struck me as 
interesting, though, is that the relationship between the time on 
the animation track, and world time, is kind of like the distinction 
between world space and object space -- that the time parameter that 
gets plugged into the animation loop has a linear transform relationship 
with the "world" time.

Thinking more about time parameters, it occurred to me that other types 
of data might be similarly "keyframed" or "snapshotted", and that this 
suddenly has interesting parallels with version control.  A keyframe 
gives the particular position of a point at some time; a version gives a 
particular contents of a document at some time.  I wonder if the two 
concepts could be merged somehow?  Wouldn't it be neat if you you could 
dial back to the state of any data the same way as you move an animation 
slider?

I'm pretty far from deciding at all how this would work, but it is 
certain that we need a time parameter for animation, so it is worth 
exploring fully the potential benefit of introducing a deep concept of 
(relative!) time into VOS.

(** lalo mentioned that if you had an animation that was also in version 
control, that data would have *multiple* time dimensions.  We could then 
advertise VOS as a 5-dimensional virtual world.  This makes my head 
hurt.)

Comments?

[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20061201/0c25aff1/attachment.pgp