Hi Tommi, I'm sorry for the delay with replying. I'll have to do a bit more reading on that and I'll have to go over this topic with our Augmented Reality team at Otago University. I will get back to you on this once I clear up with the rest of the team. We are using C/C++ internally for most of the current implementation of the virtual meeting place environment, and for some of the augmented reality projects. I have to investigate the potential overlaps between those and some of our VWs initiatives. So far these two have been going parallel to each other, but there is a mutual will to enhance the collaboration and use each other technologies.
cheers Mariusz On Sat, Nov 29, 2008 at 7:42 AM, Tommi <[EMAIL PROTECTED]>wrote: > > Hello Mariusz, > > We feel that C implementation is very important as C/C++ programs > dominate both the client and server palette. Currently we do not have > a volunteer for taking main responsibility of C implementation. I can > support with testing and bug fixing but I am afraid my skills are too > rusty for actual C coding. People with interest for reference > implementation coding are very welcome to join us and as said C > implementation is completely unclaimed at the moment. Good starting > point is to see the extent of work needed from the MXP library C# > source codes: > > > http://code.google.com/p/setp/source/browse/#svn/trunk/csharp/ReferenceImplementation/MXP > > As Ryan mentioned MXP is a low level binary protocol offering > structure for distributed 3d simulation functionality and carries > higher level protocol as payload. This so far unnamed higher level > protocol will contain application/genre specific functionality. One > good example of higher level functionality is emoting with character > animations. Once we have solid release of MXP we will start to draft > out higher level protocol specifically for social 3d worlds. By this > time we hope to have found partners from existing 3d simulation > projects with knowledge of requirements and use cases for the higher > level protocol. The higher level protocol will consists of XML > messages which will be relatively straightforward to specify and > implement once the use cases and data model are well defined. > > regards, > Tommi > > On 27 marras, 23:12, "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- Piilota siteerattu teksti - > > > > - Näytä siteerattu teksti - > > > --~--~---------~--~----~------------~-------~--~----~ this list: http://groups.google.com/group/realxtend realXtend home page: http://www.realxtend.org/ -~----------~----~----~----~------~----~------~--~---
