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

[Dzonatas Sol]

This thread isn't about a mere box as you suggest. There thread is about 
how to take physics beyond that and allow the client to do part of the 
simulation, given a single use-case.

Tigro Spottystripes wrote:
> -----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-----
> _______________________________________________
> 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
>
>