On 11/30/06, Peter Amstutz <[EMAIL PROTECTED]> wrote:
-) 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.
Oh, I can help test on XP, when new win32 binaries are released. I live in Colorado, and am willing to sign a 'no-compete' agreement. ;) -) Lalo Martins is going to be working on Python and Javascript bindings
between the s5 development branch.
Sounds interesting! I'm good with Javascript too, so... (Also, PHP, MySQL, and Blender) -) 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.
Now that's complex! -) 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.
Right. But don't make the mistake to assume that it needs to be a common scripting language everyone is familiar with either. Javascript might be easy to learn and program in, but if it's not implemented properly, it could lead to a synchronization disaster. I'm helping with an MMO, so I should know. If you don't use a server-side implementation of Javascript, things can go bad fast. Keep in mind that Texture mapping, Lighting, Animation, and Particle effects can be saved inside the models themselves. Therefore, these are not requirements of your scripting language although they would be nice to see. -) 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).
I'd say A) work on the server-side first, and give the scripting time to evolve. In my vision, it was possible to embed scripts and models on webpages. When you load the webpage, you might be presented with the owner's 'virtual space', that you could then activate to 'take the role of the main character'. After a short amount of model, texture, and media pre-cacheing time, you could suddenly find yourself playing an offline fan-made version of "Legend of Zelda 64". Though while it would be nice if certain servers did that, networked play is even better. I'd like to see links to other 3d servers resolved inside the 3d environment. I'd be willing to set one up on the linux machine if it's not too complicated. Would I have to recompile it for Mandriva? I'm not too linux-inclined, but my roommate dabbles in C++ code all the time. 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.
Just don't stop the world for the animation of a single object. All the users in a world should have the model, and should also know what animation the model is doing, but they don't necessarily need to know what frame of animation it is on. Updating each user, frame by frame, would slow the server to a crawl, imo. 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?
You're talkin' Wiki-Media, man. ;) http://twiki.org 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.
A synchronization issue; What is it necessary for the server to know, What is it necessary for the server to tell everyone else (in addition to transferring models on request) , and What can the client do on it's own? I say the client can do particles, textures, and lighting effects on it's own. Picking what models to send to clients, and choosing where to place them, and what animation is happening for each model... That's what the server has to do. (** 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.)
Well, if you want to get technical, the Penguin Model is already 5-dimensional. It has one 4d animation for 'standing still', and another 4d animation for 'running'. Technically, that's 5 dimensions. -- Steven Mattison "If you chase two rabbits, you will lose them both."
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
