Re: [vos-d] Physics Braindump
Peter Amstutz wrote: > Since VOS was originally conceived as a peer-to-peer system, we had this > idea that we could do client-based physics, but that idea quickly breaks > down when you have more than one client applying force to a single > object. So it will probably end up being something like server-based > simulation + client side prediction. Yeah, any time there's two or more interacting forces not "owned" by the same node, something has to be the referee. I was thinking a good model for this in VOS (and what I proposed on the wiki) was to have the "sector" control the physics of whatever objects or avatars move about within it, and whichever node owns the "sector" is effectively the server. (But of course, I could run a sector object off of my own PC and invite other people into it, assuming my firewall/NAT is ok with it.) Of course, peer-to-peer "shared" sectors may be an interesting feature to have as well... and could have some use for impromptu meetings between small groups of people without needing a server ... but you won't be having any physics simulation going on within them. > Prediction may be as simple as > sending linear/rotational velocity and extrapolating from that, perhaps > with collision detection so people don't appear to run through things... I think it's interesting to look at a game like Half-Life 2 as a model. Here's an environment that hosts a competitive, fast-moving multiplayer game with full dynamic physics over the internet. Yes, if you have too much lag, you see lots of "snapping," but for the most part it's not too bad. One interesting decision they made is that they don't do any "extrapolation" of the movement of other players and objects (player motion in an FPS are notoriously hard to predict, and objects are often affected by the players as well). They simply display them at the last location they heard from the server (well, they interpolate between the last two positions, which effectively adds a bit more lag). But the client itself is predicted, and so all other objects and players are seen quite a bit "behind" where they actually are according to the server -- how much depends on lag. (They then try to compensate for this on the server so that if you "shoot" at where you see another player to be, it will still register as a hit, even though the player is actually past that spot but I don't think this behavior is really applicable to VOS). Interesting history: DOOM networking was purely peer-to-peer. Quake was client-server, but without prediction, so you saw things happen a round-trip-time after you pressed a button. Quakeworld (and pretty much all multiplayer 3d games afterward) implement client-side prediction. I'm not sure if HL2 is the first game to implement lag-compensation or not, or to implement dynamic physics in multiplayer > > One thing I've come to realize is over the Internet lag is often so bad > that close synchronization is impossible and the best you can do is make > it look good on each client and just hope it's close enough. I'd imagine that most physics is for fun/immersion purposes, anyway. Any serious need for multiple people to interact with the same object should implement a more robust locking mechanism. > > On Thu, Feb 22, 2007 at 08:41:09PM -0800, Ken Taylor wrote: > > For some reason I got physics on the brain this week, so I kinda went > crazy > > and added a bunch of thoughts to > > http://interreality.org/cgi-bin/moinwiki/moin.cgi/PhysicsInVos ... mostly > > about client-side prediction, intended-movement representation, and using > > access control permissions to enforce a sector physics simulation. I'm no > > physics simulation expert by any means, and I still have a lot to learn > > about VOS, but I got a good picture in my head of how VOS physics could > work > > themselves out. I was inspired by http://www.gaffer.org/game-physics/ > > (especially the article on network physics) and > > http://developer.valvesoftware.com/wiki/Lag_Compensation ... feel free to > > comment/criticize/refactor/ignore :) > > > > -Ken > ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Physics Braindump
Do you have UDP implemented? I imagine the physics would require fast client-server UDP link, chris On 2/26/07, Peter Amstutz <[EMAIL PROTECTED]> wrote: Since VOS was originally conceived as a peer-to-peer system, we had this idea that we could do client-based physics, but that idea quickly breaks down when you have more than one client applying force to a single object. So it will probably end up being something like server-based simulation + client side prediction. Prediction may be as simple as sending linear/rotational velocity and extrapolating from that, perhaps with collision detection so people don't appear to run through things... One thing I've come to realize is over the Internet lag is often so bad that close synchronization is impossible and the best you can do is make it look good on each client and just hope it's close enough. On Thu, Feb 22, 2007 at 08:41:09PM -0800, Ken Taylor wrote: > For some reason I got physics on the brain this week, so I kinda went crazy > and added a bunch of thoughts to > http://interreality.org/cgi-bin/moinwiki/moin.cgi/PhysicsInVos ... mostly > about client-side prediction, intended-movement representation, and using > access control permissions to enforce a sector physics simulation. I'm no > physics simulation expert by any means, and I still have a lot to learn > about VOS, but I got a good picture in my head of how VOS physics could work > themselves out. I was inspired by http://www.gaffer.org/game-physics/ > (especially the article on network physics) and > http://developer.valvesoftware.com/wiki/Lag_Compensation ... feel free to > comment/criticize/refactor/ignore :) > > -Ken > > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFF4mUGaeHUyhjCHfcRAm9HAJ9MNHkyTqzUytHDzXuv0Wp15CY7RgCeKcK+ HcChaRQoyhCZE+LlXkY5j2I= =YMgX -END PGP SIGNATURE- ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] bridging to COM, .NET, DBUS (was: second draft requirements)
Quick thing to point out, COM and D-BUS are fundamentially different in that COM objects are usually loaded in-process, whereas D-BUS is used to communicate between running processes. Interoperability has a number of different dimensions, and concurrency/flow-of-control issues are a critical but often overlooked aspect of that. On Sun, Feb 25, 2007 at 11:40:27AM -0500, Reed Hedges wrote: > Lalo Martins wrote: > > > Conversely, on Linux, I have long wanted to have d-bus bindings, which > > would achieve more or less the same effect. That is something that > > probably will be in s5 out of the box -- you add a site extension > > (assuming site extensions exist in s5; or whatever is the equivalent if > > they don't), and you get d-bus, similar to how you get VIP. > > Part of dbus support will have to be semantic bridging too. Either in > the VOS site extension or in a seperate native_dbus-vos_dbus daemon; > doing it in the site extension probably makes the most sense I think. > So adding and removing services looks like adding/removing vobjects; > changing the prenesce status of your avatar sends a dbus event to > synchronize with other IM systems, etc. > > Reed > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Physics Braindump
Since VOS was originally conceived as a peer-to-peer system, we had this idea that we could do client-based physics, but that idea quickly breaks down when you have more than one client applying force to a single object. So it will probably end up being something like server-based simulation + client side prediction. Prediction may be as simple as sending linear/rotational velocity and extrapolating from that, perhaps with collision detection so people don't appear to run through things... One thing I've come to realize is over the Internet lag is often so bad that close synchronization is impossible and the best you can do is make it look good on each client and just hope it's close enough. On Thu, Feb 22, 2007 at 08:41:09PM -0800, Ken Taylor wrote: > For some reason I got physics on the brain this week, so I kinda went crazy > and added a bunch of thoughts to > http://interreality.org/cgi-bin/moinwiki/moin.cgi/PhysicsInVos ... mostly > about client-side prediction, intended-movement representation, and using > access control permissions to enforce a sector physics simulation. I'm no > physics simulation expert by any means, and I still have a lot to learn > about VOS, but I got a good picture in my head of how VOS physics could work > themselves out. I was inspired by http://www.gaffer.org/game-physics/ > (especially the article on network physics) and > http://developer.valvesoftware.com/wiki/Lag_Compensation ... feel free to > comment/criticize/refactor/ignore :) > > -Ken > > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] OpenID
Well, the gist of it is we will want to support some kind of single sign-on scheme so that users don't need to set up a separate login or identity for every virtual world that they visit. OpenID may be one direction to go with that -- but there are a number of other centralized authentication schemes as well, such as (I believe) LDAP and Kerberos. This is going to be important when we start thinking about the s5 security model... On Sat, Feb 24, 2007 at 11:52:26AM -0500, Reed Hedges wrote: > > > I've been trying to learn more about OpenID. So far I don't really see > the point beyond just making it easier to log in to various web sites-- > that is I haven't yet seen any utility to using it as an authentication > option in VOS. > > What do you think? > > Reed > > > > ___ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] signature.asc Description: Digital signature ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Sending unrecognized messages to S4
Yea, that's reasonable. It should be a core:error method though, and
you'll want to come up with an error code and maybe raise an exception
on the caller.
On Sat, Feb 24, 2007 at 08:24:36PM -0500, Reed Hedges wrote:
>
> I encountered a problem in S4 just now: if you send a message to an
> object for which there is no handler registered, it basically ignores
> it. If the sender happens to be waiting for a reply,
> then it has to wait for the full timeout.
>
> However, we have a fairly well defined way of replying to messages in
> VOS, so it could reply with an "unhandled message" error.
>
> E.g. the receiving Vobject can do this, I think? --
>
>
> if(...Message msg not handled...) {
> Message err;
> err.setNonce(msg->getNonce());
> err.setMethod(msg->getMethod() + "-reply"); // Or maybe "core:error"
> instead?
> err.insertField("error", "Unrecognized message method: " +
> msg->getMethod());
> err.setType("reply"); // ?? or "update"?
> from->sendMessage(err);
> }
>
>
> Does this make sense? Can I add it? (It would be in
> VobjectBase::msgSendImpl() I think)
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] second draft requirements
>Glad you've stuck with us.
>
>I remember VRSpace (well, visiting the web page anyhow). What became of
>that? It looks like there's still some mailing list activity.
Oh yeah, VRSpace is still kicking as I understand. I stopped working on it
somewhere in 2004 so haven't really played much with it since then. Its
main guy Josip Almasi I believe has been making modifications to it.
In the intervening years I spent a lot of time programming in c# and I
decided java didn't have what I needed to build the system I was looking for
in VRSpace. My take on things is that the VRML world basically had the
right idea about how to build one of these virtual space system, but things
got out of wack. Ever read the "Living Worlds" document?, very cool, ahead
of its time stuff. However, they got too caught up in VRML itself. First
they build a nice standards 1.0 that let you set up a scene graph. Then
they add animation, events, prototypes, for nodes and an external api for
interacting with the scene. All very good, but they also added internal
scripting languages, which is where they started to go off the deep end. As
far I understand it now, they have cut off support for the external api, and
expect you to fully program all your nodes in javascript. Say what?
Basically they think VRML is everything, graphics, animation, all the
underlying logic, networking, programming... way too much for someone
building a VRML browser to be responsible for supporting.
But still the abstract concept of an object living in a space with events,
properties, perhaps geometry is the right one. Objects that can be
discovered, reflected upon... So I want to turn the VRML concept inside
out. Spaces (whether client side or server) are collections of special
objects (VRObjects if you will) that are shared when the two spaces
encounter each other (Client logs in for example). These objects may or may
not have geometry associated to them, but they do have attributes that can
be queried, and events that can be registered for. As an example, the most
basic example of a VR chat system is:
Server - Chat object with method Say.
Client 2 - Merges with Server space, register a listener to Say method on
chat object.
Client 1 - Merges with Server space, sees Chat object, calls Say with
parameter ( "Hello World" )
Client 2 - Receives the Say call, and maybe displays it.
So why c#? basically they've got Serialization, Remoting, Attributes, and
most importantly this notion of a ContextBoundObject, which together
basically gives you a VRObject. A CBO lets you intercept any calls to it
from another CBO (whether residing in another virtual machine or the same)
and handle them as you wish. So in the above, "register a listener with
Chat" and "receive the Say call" are handled transparently by intercepting
the Say call and calling all the listeners. The remoting handles all the
object serialization and communications, but most importantly whether you
are calling methods on a server object from the client
(chatObject.Say("Hello World") or from server to server object, you program
it the same way. The fact that this method can be listened to at all,
security etc. occurs by marking it up with attributes.
In terms of seeing objects though in a virtual space, its all handled as
above. You have classes called Transforms with associated objects
VrmlFiles. You detect a transform and vrmlfile when encountering the space,
you read off the Transform's location, the VrmlFile's resource "blah.wrl"
and tell your browser to create the associated nodes. If you want to
"script" a vrml node, you do it all by listening to the vrml nodes, and
handling the events in the c# itself. So the vrml file is slave to the c#
class, not the other way around which would be more the VRML evolved.
So I know I am preaching to the choir here, which is why I think your
project rocks. My take on your stuff is that you have built the entire
protocol, the serialization, the CBOs, reflection, the attributes/security
yourself. Very impressive.
>To be honest, I hate COM and our primary development platform has always
>been Linux, so it's not particularly high on the list of priorities.
>However, interoperability is going to be a strong focus of the next
>version, so some kind of COM binding may be down the road. I'm actually
>more interested in being able to interoperate with .NET directly than
>trying to do .NET via COM. The tricky part on Windows is that I also
>want to support compiling with cygwin/mingw, so we can't rely on tools
>that are only available with Visual Studio.
I hear you. Yeah the only real reason for suggesting COM was for the
interop with .Net. I suppose then you could make yourself a managed c++
assembly which wraps your api, but watch out for combining .Net memory
management with your code, yikes! How about mono?
>Yes, we've been meaning to do that for a long time. It's just a matter
>of devel
Re: [vos-d] bridging to COM, .NET, DBUS (was: second draft requirements)
Lalo Martins wrote: > Conversely, on Linux, I have long wanted to have d-bus bindings, which > would achieve more or less the same effect. That is something that > probably will be in s5 out of the box -- you add a site extension > (assuming site extensions exist in s5; or whatever is the equivalent if > they don't), and you get d-bus, similar to how you get VIP. Part of dbus support will have to be semantic bridging too. Either in the VOS site extension or in a seperate native_dbus-vos_dbus daemon; doing it in the site extension probably makes the most sense I think. So adding and removing services looks like adding/removing vobjects; changing the prenesce status of your avatar sends a dbus event to synchronize with other IM systems, etc. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] The best part about bzr...
On Sat, 24 Feb 2007 16:50:08 -0500, Reed Hedges wrote: > On Sat, 24 Feb 2007 13:30:52 -0800, Ken Taylor wrote: >> I see Reed uses a dvorak keyboard! ;) > > Haha, I picked Dvorak up from Pete actually. Damn, Ken found us out! Yes, VOS is part of the International Dvorak Conspiracy. Aoeui! Aoeui! best, Lalo Martins -- It doesn't bother me that people say things like "you'll never get anywhere with this attitude". In a few decades, it will make a good paragraph in my biography. You know, for a laugh. best, Lalo Martins -- It doesn't bother me that people say things like "you'll never get anywhere with this attitude". In a few decades, it will make a good paragraph in my biography. You know, for a laugh. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] second draft requirements
On Fri, 23 Feb 2007 14:49:43 -0500, Peter Amstutz wrote: > On Thu, Feb 22, 2007 at 11:16:24PM -0500, Rob Meyers wrote: >> In terms of your scripts section, it would be great to have a COM binding >> to your api. Although this is pretty winders specific, it opens up all >> your code to .Net. I've done some work with editing worlds while you are > > To be honest, I hate COM and our primary development platform has always > been Linux, so it's not particularly high on the list of priorities. > However, interoperability is going to be a strong focus of the next > version, so some kind of COM binding may be down the road. Conversely, on Linux, I have long wanted to have d-bus bindings, which would achieve more or less the same effect. That is something that probably will be in s5 out of the box -- you add a site extension (assuming site extensions exist in s5; or whatever is the equivalent if they don't), and you get d-bus, similar to how you get VIP. best, Lalo Martins -- It doesn't bother me that people say things like "you'll never get anywhere with this attitude". In a few decades, it will make a good paragraph in my biography. You know, for a laugh. best, Lalo Martins -- It doesn't bother me that people say things like "you'll never get anywhere with this attitude". In a few decades, it will make a good paragraph in my biography. You know, for a laugh. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
