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
