-----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
