On May 13, 2009, at 4:35 PM, Paul Fishwick wrote:
>> do procedural animation, and not play back a pre-made vertex 
>> animation?
> I am looking now at both: what is possible procedurally or w/ 
> playback. Are
> either, or both, possible given the current python API in rex ?

afaik there is no support for it in the protocol nor in the viewer 
natively, i guess you would have seen it if there was.

>> both are in principle possible - playing back pre-made pretty
>> straightforward and i guess in the roadmap if it's not implemented 
>> yet.
> Would we need to dive into the realxtend C++ code or is the python API,
> as it currently stands, appropriate? I suppose that is the essence of 
> my

it (obviously) needs client side support, and to my knowledge there is 
not (much of) a client side api in 0.4 at all. i think Tuomo did embed 
py there, or did you? the client side scripting commands that i've seen 
i've assumed to be just custom packets that you can send using the 
server side rexscript (.net/ironpython) api, for which the 
implementation on the client side is hard coded (in c++? or is embedded 
py used there?) certainly adding new network packets etc. to 0.4 viewer 
requires c++ work, touching the networking there etc.

so my guess is that if it's not implemented already, it needs c++ work 
(in 0.4).

> If we can use the existing realxtend python API to do this, we'll
> probably try that. However, if we have to go into the C++ code,
> maybe NG would be a more logical step over the long term.

like said my guess is that (at least) NG will have this support at some 
point anyway, but as it's not in anyones concrete plans yet AFAIK, it 
would be great if you could have a go with it.

it would probably be possible to make the py API in NG so that you 
could do that in py there. i'm planning to expose ogre things in the 
api there anyway, perhaps even reusing the python-ogre work, but 
haven't looked into that much yet (so far have just exposed the entity 
position, which is ogre data in the internals). the possibily of doing 
this kind of things with py modules came up also in the talks about 
direct bone control (even though both this and that may well be such 
core feats that can make sense in the c++ components with other basic 
things). anyhow handling own custom data in plugins is a requirement 
for the NG arch.


> We'd be OK with just using pre-defined animations for now, along the
> lines of what was done in the OGRE facial animation demo

ok. as far as i can see there are 3 areas where you could work:

1. if you have some specific need for vertex anims that should work 
together with some other functionality, you could just do that 
functionality first in some standalone (py)ogre app. obviously if you 
specifically want to have them in the rex distributed env, normal 
playback as they are and that's it, this option doesn't take you 
anywhere.

2. add it in c++ to 0.4 (add a new network package for it , make the 
handler for it using the ogre api within the viewer, and add the 
support to the server too). should be relatively easy, as on one hand 
playing back skeletal anims is similar ogre-api wise (even though for 
networking that might reuse the sl char anim playback command packet), 
and on the other hand e.g. the command to start a flash anim would be 
an example of adding a new command (AFAIK those are made using some 
kind of 'generic message' that's in the protocol). so for both parts 
there would be example code to look.

3. add it to NG. should be easier here, in either c++, or later when 
the API dev has made it there (and concrete usage needs are an 
important prioritizer in my dev there) in py too. whether this makes 
sense for you of course depends on your schedule and functionality 
needs, whether NG will meet them otherwise. right now it AFAIK doesn't 
even have avatar nor any animation data yet, the guys have recently 
implemented textures and meshes etc (and basic object (/& prim) data 
earlier). when someone gets to add skel anims, you'll again have an 
example how to do it, but don't know whether that'll be in the plans 
for the next sprint or 0.1 even.

> -p

~Toni


--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/realxtend
http://www.realxtend.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to