It is feasible. It would just require a standard way of referencing objects in all modules(URI?). unsigned integers are fast, small and well supported. Potentially the binary data in a UUID could be fit in the memory space and be just as fast.
Regards Teravus On Fri, Jul 10, 2009 at 12:13 PM, Melanie<mela...@t-data.com> wrote: > Well, the problem is that there are two ids for each prim, that need > to be translated between. I don't now physics, because looking at > that math makes my head hurt, so I don't. > > Is it at all feasible then, to not have a local ID? > > Melanie > > Teravus Ovares wrote: >> One connected functionality here, is script engine events. These are >> all done via localID. Additionally, physics collision events are >> generated with 'localid' because most physics engines either have a >> sequential numeric id for objects or have a means to store them. It >> may not have a bearing on the derez event, however, I wanted to >> mention them since 'moving localID out of core' was brought up. >> It's not really a Linden concept really.. it's a Havok concept >> that they adopted. >> >> Regards >> >> Teravus >> >> On Fri, Jul 10, 2009 at 11:58 AM, Melanie<mela...@t-data.com> wrote: >>> Definitely +1. However, here's a thought: >>> >>> Could we not try to take this as a starting point for moving the >>> localID to UUID conversion into the client view, e.g. make it a >>> List<UUID> and translate LocalID to UUID before the call. I believe >>> we should work on getting LocalID out of core, it's a Linden concept >>> other viewers probably won't have. Having just ONE type of ID (the >>> UUID) would make implementing other client stacks easier. >>> >>> Melanie >>> >>> >>> MW wrote: >>>> In the current OnDeRezObject event, only a single localID of a prim is >>>> passed at a time. >>>> >>>> So if multiple objects are DeRezzed in one action, even though all the ids >>>> are sent in a single packet. We have code in the ClientView that loops >>>> through that list and for each id triggers the OnDeRezObject event. >>>> >>>> I propose moving that loop into the Scene handling of the action >>>> (Scene.DeRezObject(...)) so that the event is only triggered once per >>>> packet and if there are multiple prims to derezz in a packet, the scene >>>> code can loop through them and deal with them as required. >>>> >>>> So current the delegate of the OnDeRezObject event is : >>>> >>>> public delegate void DeRezObject( >>>> IClientAPI remoteClient, uint localID, UUID groupID, DeRezAction >>>> action, UUID destinationID); >>>> >>>> I propose changing it to: >>>> >>>> public delegate void DeRezObject( >>>> IClientAPI remoteClient, List<uint> localIDs, UUID groupID, >>>> DeRezAction action, UUID destinationID); >>>> >>>> It has to be better to have only one event triggering rather than possibly >>>> hundreds for the same user action. >>>> >>>> My next step (which I'm currently in the middle of in my local version) is >>>> to handle the taking of those multiple prims into inventory and only >>>> making a single inventory item, rather than the current method of a >>>> separate inventory item for each prim. But that will be detailed in a >>>> different proposal.. >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
