Week 1 Project Summary
Ryan McDougall
Overall Architecture
- Assist with research of IM, voice, video, streaming technologies and
creating a suitable build environment for windows.
- Assist with the development of internal API, data model, interfaces
and abstractions.
- Run around like chicken with head cut off.
===== Lasse
Shared context (Ogre) with arbitrary simple OGL app
Estimated time to completion: 4 days
Create a demo program which displays a scene using Ogre engine, and on
top of that, some simple arbitrary OpenGL scene using raw OpenGL
commands, to test the feasibility of integrating an OpenGL 3D UI on
top of Ogre.
The demo uses a shared OpenGL context and saves the necessary state so
that both Ogre & the other OpenGL scene can function correctly. For
determining the necessary state to save/restore, examining the code of
Ogre OpenGL rendersystem may be necessary.
- Create basic demo program on Windows (1 day)
- Additional research, use more advanced OpenGL, determine necessary
state (2 days)
- Linux testing (1 day)
Deliverables:
* source code
* demo program
* documentation and research results
===== Heikki
Modules, subsystems / abstractions and interfaces + framework.
Enumerate all potential modules. (1 day)
Prioritize modules. (1 day)
Figure out potential interactions between modules and module interfaces.
(3 days)
Result:
Interface and interaction diagrams of at least the most important systems.
===== Tuomo
What are the abstractions levels, API in the new Viewer?
Trying to get answers to the question of how to design the new viewer
framework so that:
- it doesn't have huge blob classes implementing everything (prim and avatar)
- can be extended easily
- isn't hardcoded into the current rexworld object model & functionality
Time estimate: 5 days
Deliverable:
- documentation
===== AnttiK
Research possible replacements for Realxtend or OpenSim's native
peripheral services (UGAIM, RexAuth Server, etc)
Estimated time to completion: 4 days
- Research Intel's AssetServer design and compare to reX's (1 day)
- Research Opensim's current AssetServer and compare to Intel's (1 day)
- Review the Source code for all 3 code bases making note of pros and
cons (1 day)
- Install Intel's AssetServer and document how easy it is to build and
deploy (0.5 day)
- Review any other proposals from Intel (0.5 day)
Deliverable:
* short documentary about asset server comparison
* analysis and opinion of the suitability of using Intel's new
services over reX or OpenSim alternatives in reX-NG
===== MikkoP
Research Gstreamer
??
===== MattiK
Research Telepathy
??
===== MattiR
Research Telepathy
??
===== Jukka
Research and Categorize existing OpenSim and reX communication and
present a proposal on which communications to remain compatible with,
and which to diverge from.
??
===== AliK
Investigate a method for packet decoding of SL UDP packets. Of
interest is libomv, funmv, and a custom solution using
message_template.msg.
??
Ryan McDougall
===== MattiK & MattiR
Task: What is our IM/Communication Library?
Estimated time to completion: 12 days
Task description:
Test telepathy framework and form an opinion about should we use or
not to use telepathy for IM.
Sub tasks:
- build dbus-glib on windows platform with cmake (3 days)
- build telepathy-glib on windows platform with cmake (2 days)
- build telepathy-haze/telepathy-gabble on windows platform with cmake (2 days)
- Make example telepathy applications (python or c++) to run with
telepathy dbus environment (2 day)
- write a sample app that uses telepathy for text chat (3 days)
Deliverable 20.1.2008:
* build environment (make files etc.) for dbus-glib
Deliverable 27.1.2008:
* build environment (make files etc.) for telepathy-glib and
telepathy-haze/telepathy-gapple
Deliverable 3.2.2008:
* demo text chat app
* text chat app (source, binary)
* Recementation to IM/Communication library
daniel miller
Mike Mazur
On Wed, 14 Jan 2009 17:12:46 +0200
Ryan McDougall <ryan.mc...@realxtend.org> wrote:
> ===== AnttiK
> Research possible replacements for Realxtend or OpenSim's native
> peripheral services (UGAIM, RexAuth Server, etc)
>
> Estimated time to completion: 4 days
>
> - Research Intel's AssetServer design and compare to reX's (1 day)
> - Research Opensim's current AssetServer and compare to Intel's (1
> day)
> - Review the Source code for all 3 code bases making note of pros and
> cons (1 day)
Perhaps this can help:
https://lists.berlios.de/pipermail/opensim-dev/2009-January/004414.html
Mike
Ryan McDougall
Cheers,
Ryan McDougall
GStreamer in OGRE context
-Research how GStreamers OpenGL sink can be used. (1d)
-Research how to get GStreamer video sink in to OGRE. (3d)
-Research what can be used from Togra. (1d)
-Cross platform testing (1d)
Deliverable:
* source code
* small demo program
* small documentation of the research
On Wed, Jan 14, 2009 at 6:15 PM, Ryan McDougall
Ryan McDougall
On Thu, Jan 15, 2009 at 10:10 AM, Ryan McDougall <semp...@gmail.com> wrote:
> hehe :)
Toni Alatalo
also what Dan has already brought up about physics, animation controls
etc. has been interesting.
perhaps we could even draw concrete issues for the design from there.
like what i had been thinking of the different networking configurations
/ client-servers / peers ideas etc., and whether they possibly reflect
to the viewer arch in some way.
we are not changing protocols to begin with, but concrete points about
what changes there might impose might help in figuring out how to
structure the core / systems so that experimenting with those things
would be nicely possible.
i've been also thinking about what we should do next, was now coming to
somehow looking at the integration of the parts, and OTOH planning
testing (drafting first unit tests / test cases perhaps, even).
another angle could be something specific about client side controls /
avatar animation / controller device things, but again as this is not
about new features first but reimplementation of the existing thing to
facilitate making all those features later (soon enough..), that's
perhps not so relevant.
however, there are known requirements there, stuff like bone control
which people have already wanted with the existing viewer but don't
really have yet (AFAIK - is pretty straightforward though, but
substantial work still so i guess wasn't prioritized *that* high last
year when so many things were already done (like IK and cloth)).
well bone control is much simpler than those though, it would be
basically just about exposing the existing bone control code in Ogre to
the Rex client side scripting I guess .. hm and as the embedded py there
can access the system, it might be even able to read an external
controller device? does the protocol already have means for sending
arbitary poses from the client? i suppose not, so would need to extend
the protocol with that? so straightforward but would need to touch
viewer, protocol and be supported on the server side too.
perhaps that could be an interesting direction for a test case?
a component that does what Dan wants?-)
a yet different direction to look from would be editing tools, perhaps
with the help of the Blender 2.5 refactor that i've mentioned earlier,
how they are making a 'tools api' that'd allow making new scene, object
etc. manipulation tools as plugins nicely possible (utilizing the new
notifier system etc).
>>> wow, project management! What a concept!
>>>
~Toni
daniel miller
> Want to sign yourself up for an R&D task?
If we can set out the scope and the timeline, I'm game to try something.
Here's a list of what I believe myself to be competent at, in
decreasing order of experience:
General:
ODE (physics engine -- client-side physics?)
Python (including internals, such as mem usage/garbage collection,
concurrency, non-Python bindings)
Ogre (mostly python-ogre, but I'm C++ competent as well)
real time programming
concurrent/parallel programming
performance profiling/optimization
Opensim/Openviewer specific:
Physics (prims, terrain, characters)
Character animation (including skeleton/mesh design)
Prim meshing and rendering
there's other stuff of course, but these are the areas where I can
leverage my experience quickly.
-dan
Ryan McDougall
>
> On Thu, Jan 15, 2009 at 3:25 AM, Ryan McDougall <semp...@gmail.com> wrote:
>> Want to sign yourself up for an R&D task?
>
> If we can set out the scope and the timeline, I'm game to try something.
>
> Here's a list of what I believe myself to be competent at, in
> decreasing order of experience:
> General:
> ODE (physics engine -- client-side physics?)
If you want to take a template from the OP of this thread and lay out
a brief proposal to investigate how one might create a client-side
physics module, I would be fairly ecstatic.
For the sake of the research, one may assume OpenViewer, or any other
arbitrary viewer/game architecture. Just how one might interplay with
OpenSim is, I think, enough of an open question itself.
Cheers,
Tommi Laukkanen
daniel miller
>
> If you want to take a template from the OP of this thread and lay out
> a brief proposal to investigate how one might create a client-side
> physics module, I would be fairly ecstatic.
>
> For the sake of the research, one may assume OpenViewer, or any other
> arbitrary viewer/game architecture. Just how one might interplay with
> OpenSim is, I think, enough of an open question itself.
Ok, I'm willing to try. So I should add this to the wiki page?
Ryan McDougall
This is just R&D, so really anything informative is really helpful to
us. You have a lot of leeway at this stage to investigate as you see
fit.
Make a wiki user, let me know what it is, and I'll give him access rights.
Cheers,
daniel miller
<tommi.s.e...@gmail.com> wrote:
...
> would send objects hurling off their trajectory. Its good to note that the
> trajectory calculated by server(s) has acceleration limit which can
> be reasoned from network lag.
with the authoritative source, which in our case (for the foreseeable
future) will always be the server. I believe it is possible to extend
this concept to p2p physics, but that would be too large a change for
us to contemplate anytime soon.
The main thing to remember is that nothing you do locally is of any
consequence beyond your machine, as you say. But I disagree that the
only point of client-side physics is for visual effects. A good
example is walls. Since they rarely move, your local idea of when you
hit a wall is likely to be very close to what the server thinks, even
if the network is having problems. Therefore it's not just an effect
to calculate that locally; you are in fact making a better guess about
what the server's state is, and representing that to the user.