Re: [vwrap] Consensus? What exactly should be in the protocol

[<[e-mail]>]

I currently have psychics running on the client.  But why do I even need to
have physics?  That is a VWRAP requirement?

Simulation takes place on the client.

For or nursing virtual space, the virtual world is a standalone space that
everyone gets their unique copy from.  It does allow for observers and we
can sync object and UI events to them.

I feel we are making so many assumptions about the virtual world and how it
is implemented.  I don't really understand why you are asking the question

K.


-----Original Message-----
From: Meadhbh Hamrick [mailto:[e-mail]] 
Sent: Wednesday, September 22, 2010 4:25 PM
To: [e-mail]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

where does physics simulation take place?

in the client or on a server somewhere?
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Wed, Sep 22, 2010 at 1:19 PM,  <[e-mail]> wrote:
> Why is virtual world not a web app?  My virtual world runs in a browser
and
> can talk to my webserver.
>
> K.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Meadhbh Hamrick
> Sent: Wednesday, September 22, 2010 3:37 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
>
> On Wed, Sep 22, 2010 at 11:59 AM, Cristina Videira Lopes
> <[e-mail]> wrote:
>> Cristina Videira Lopes wrote:
>>>
>>> You can dictate that. But then this will be completely irrelevant in a
>>> couple of years when WebGL is actually usable or when Google finishes
> their
>>> virtual machine for running safe native code on browsers.
>>
>> ...or when server-side streaming goes mainstream, and being in a virtual
>> world is as simple as running a video player plus a few JavaScript/native
>> back channels to the server.
>>
>> First point is: according to the Web principles, each web application
>> controls 100% what and how the client gets via this really powerful
> concept
>> of hypermedia. It is unlikely that the world is going to adopt a standard
>> that forces implementers to take several steps back on this kind of
>> autonomy. The diversity is what gives service providers an edge.
>
> hold on there! you just gave two completely opposing examples. if i
> have a video player that's receiving raster lines from a distant game
> server, that's TOTALLY the opposite of a client having complete
> control over it's hypermedia input. if i simply started streaming an
> OnLive session of someone doing SecondLife in a flash based video
> player, there's absolutely no way to guarantee that the data used to
> create the scene would be available to the client.
>
>> The second point is: when we have all that variety of viewer
> implementations
>> that are all equally accepted by the web browser, we are still to cope
> with
>> portability of user agent simulation state between those worlds -- and
>> that's the bottom line for interoperability of virtual worlds on the Web.
>> I'm interested in this, because it's much more foundational than the
> variety
>> of virtual world implementation options.
>
> also... the virtual world is not a web application.
>
> if you look at typical web apps, the mashing up is usually done at the
> server side, turned into HTML and then sent to the browser.
>
> we're starting to see a lot more apps where JavaScript is used to do
> mashups in the client, but...
>
> VWRAP was chartered to work on server-authoritative worlds (like
> Second Life and OpenSim.) that means there's a lot of state in the
> simulator. it sounds like you want to open this state up and push its
> simulation to the edge of the network (and thus support
> co-simulation.)
>
> did i read that right? did you really just say that virtual worlds are
> client web apps?
>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>