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