RealXtend is very supportive of MXP, and wish to see its continued
development so that it might one day be an option for a future
protocol for reX.

However, while I haven't studied it closely enough, the current
implementation appears too low level to be of practical use in reX at
the moment, and reX does not have resources to contribute money or
engineering on it at the moment.

I have spoken informally with a core OpenSim developer, and he was
considering implementing MXP on top of OpenSim. However I do not know
the current status of that discussion.

When reX might be able to implement something based on it does depend
on how much work gets done. If there is a large community push, which
we are hoping for, it would allow us to reconsider our time-line.

Hope this clarifies the current situation from my perspective.

What does this list think?

Cheers,

On Thu, Nov 27, 2008 at 11:12 PM, Mariusz Nowostawski
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Awesome. I'd be interested in people who would like to work on reference
> implementation in C. Is it planned or no takers?
>
> Can you let me know what is the relationship of the MXP efforts in the
> context of RealXtend developments? Is there a commitment to follow up with
> this new protocol by the mainstream Rex?
>
> cheers
> Mariusz
>
>
> On Sat, Nov 15, 2008 at 4:08 AM, Tommi <[EMAIL PROTECTED]>
> wrote:
>>
>> Hello
>>
>> We have released today 0.3 draft of MXP with arkowitz. We are looking
>> for people who can review the draft and even join the effort. Our next
>> step is to work on proof of concept implementations on both Java and
>> C#. Here is a short description about the protocol quoted from MXP
>> wiki:
>>
>> http://wiki.setp.info/wiki
>>
>> ---
>>
>> The goal of this wiki is to define minimal and easy to implement open
>> protocol for distributed 3D environments (virtual environments):
>> social 3d environments, online games and first person shooters.
>> Distributed 3d environments are in this context systems with multiple
>> thin clients and servers simulating single seemless virtual
>> environment. This protocol concentrates entirely on messages required
>> for the defined distributed 3d simulation model. This protocol does
>> not contain application specific concepts but acts as a transport
>> layer for custom interaction and state data which can be defined in a
>> higher level specification. The same virtual space may be simulated by
>> one or more servers. Distributed simulation (cloud, grid, cluster)
>> consists of simulations nodes (bubbles, sims). Simulation node is
>> appreviated to bubble and simulation cluster to cloud. One bubble has
>> cubic or spherical volume but bubbles in a simulation cloud do not
>> necessarily form a cubic lattice. Nodes may be sized and placed using
>> entirely different strategy. Locations in messages are always
>> presented in local simulation coordinates relative to the center of
>> the source bubble. Each bubble is linked to coexisting and adjacent
>> bubbles to enable injections, interactions and handovers. Client is
>> connected to a single bubble at a time. Object is simulated by one
>> bubble at a time. Handover is a process where object is handed over
>> from one bubble to another.
>>
>> All though it is possible to support other ways of space partitioning
>> or entirely free form distribution of bubbles, cubic lattice is still
>> the most viable model from both implementation and network load
>> perspectives. Cubic lattice can be applied as dual lattice to achieve
>> local redundancy and load balancing (See: Advanced Grid
>> Configurations). Purely peer to peer simulation model is not included
>> to the current work due to trust issues. It is possible to allow
>> clients to include temporary client side simulated objects to the
>> simulation space in similar manner to avatars. In this scenario client
>> is only responsible for internal state simulation of the object and
>> these objects should be clearly marked as client side objects. Peer to
>> peer protocols are considered viable for speech, video and gesture
>> signals but not included to this protocol.
>>
>> ---
>>
>> best regards,
>> Tommi Laukkanen
>>
>>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
this list: http://groups.google.com/group/realxtend
realXtend home page: http://www.realxtend.org/
-~----------~----~----~----~------~----~------~--~---

Reply via email to