[opensource-dev] client-side physics and general relativity

[Tigro Spottystripes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

currently attachments don't bump on anything, and animations do not
affect what the avatar collides with, avatars got a static bounding box
and that is it

On 16/4/2010 10:45, Dzonatas Sol wrote:
> That's true for the case of non-static objects. We could, however, 
> predict how fast an object changes and negotiate that limit, and that's 
> basically what there is to agree upon for what is relative.
> 
> For example, let's  say an avatar moves around a sim of mostly static 
> objects. It can do most of the work for client-side physics, so those 
> updates are lowered traffic. When the avatar touches a non-static 
> object, it could just send a signal to the sim that it touched the 
> object. The sim then decides if it needs to send an update back to the 
> client. If the object acts like a static object even if it is set 
> non-static, then no update is needed from sim to client.
> 
> Another example, lets say the avatar has lots of animated attachments. 
> The avatar also moves around a sim of mostly static object, but the 
> attachments are obvious non-static since they animate. Since the 
> attachments are all within the avatar's relative space, the client-side 
> physics can handle all the motion of the attachments. The sim may not 
> need to know anything about the attachments unless they bump into 
> something non-static.
> 
> Soft body physics in mind...
> 
> 
> Tateru Nino wrote:
>> Hmm. However, with virtual objects the physical properties aren't fixed.
>> Unlike regular matter, the physical properties of an SL object can
>> change at any time. In fact - and I grant I only have anecdotal
>> information to support this - I think it is less likely for an object's
>> physical properties to remain constant than it is for them to change.
>>
>> On 16/04/2010 2:57 PM, Dzonatas Sol wrote:
>>   
>>> I want to share a use-case/concept for physic simulation where the 
>>> client and sever wouldn't have to send object updates, or at least there 
>>> wouldn't be as many updates needed to send from the sim to the client.
>>>
>>> Given we can use general relativity more as a mutual agreement rather 
>>> than assume it is the only way reality changes; we could further expend 
>>> such mutual agreement between a server and client as they simulate 
>>> physics. Now don't expect FTL changes for this, yet we can use the same 
>>> analogy and define a limit. Let's use one that LL has already defined as 
>>> max velocity an object moves through a sim.
>>>
>>> Now, let's say we have two objects. Object (A) is within 10m to an 
>>> avatar. Another object (B) is 50m away for that avatar. Now, since 
>>> object (A) is within a distance an object can move within a second of 
>>> max velocity, the client can be given rights to simulate object (A), and 
>>> the simulator wouldn't send any updates to the client if the client does 
>>> such. Since object (B) is outside the distance of an object can move 
>>> within a second at max velocity, the simulator would continue to send 
>>> updates to the client about object (b) only if in view (as it does now).
>>>
>>> If object (A) and object (B) are static, as in they never move, then the 
>>> client would fully control its position within that relative second of 
>>> space and all physics. If the avatar bounces off the static object, the 
>>> client doesn't need to send updates to the sim unless the object needs 
>>> to know if it was touched.
>>>
>>> If the objects aren't static or if there are more avatars, then there 
>>> are several negotiation and scenarios that could happen, yet let's not 
>>> digress immediately away from the basic use-case/concept stated above.
>>>
>>> Bottomline, this should be negotiable. The sim may not allow it at all 
>>> if if the sim needs full physics control. The avatar may want to only be 
>>> in sims that don't take full control of physics. If the client simulates 
>>> some objects then the sim is expect to simulate the same objects. The 
>>> two simulations should be basically in sync, yet accuracy of being in 
>>> sync should be negotiable also.
>>>
>>> Relative second of space can be quickly calculated, for example, ( max 
>>> diameter of avatar + 1 second distance of max velocity ) * 3.333...  
>>> (basically like pi r squared)
>>>
>>> =)
>>>
>>>
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting privileges
>>>
>>>   
>>>     
>>
>>   
> 
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvIzFQACgkQ8ZFfSrFHsmUmAQCfXphZ/Dp7U0x6rQGMT3IQrq/U
hngAn1zDWr/DlqH/v94I/2UIPjbTBbzU
=prc1
-----END PGP SIGNATURE-----