Attachments can be dropped and then need the proxy again. Melanie
On 27/03/2014 19:29, Dahlia Trimble wrote: > Another strategy may be do something along the lines of deleting it if the > SOP is part of an attachment. Attachments are phantom and do not need > physics proxies. > > > On Thu, Mar 27, 2014 at 11:26 AM, Dahlia Trimble > <dahliatrim...@gmail.com>wrote: > >> That field contains the asset data, which, in the case of a sculptie is >> not a mesh but a texture. For ODE, the resulting mesh will be cached once >> generated and reused, however the asset will need to be reaccessed later if >> a mesh with another scale is required, or one with different optional >> parameters such as invert or mirror being set. If you remove the asset >> data, it will need another asset fetch and multiple attempts to create a >> mesh until the asset becomes available again. I'd suggest *not* removing >> the asset data, but rather exclude it from the serialization when it's >> being stored for attachment purposes so as to reduce as many asset fetches >> as possible and keep sim startup/load time low. >> >> >> On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II < >> james.stalli...@gmail.com> wrote: >> >>> Knock 'em dead Oren xD >>> >>> >>> On Thu, Mar 27, 2014 at 11:29 AM, Melanie <mela...@t-data.com> wrote: >>> >>>> Looks like you found the culprit! All those suggestions sound good. >>>> >>>> Melanie >>>> >>>> On 27 Mar 2014, at 17:03, Oren Hurvitz <or...@kitely.com> wrote: >>>> >>>> When a prim is a Sculptie or Mesh, the prim's shape contains a field >>>> called >>>> SculptData which stores the full mesh or texture (for sculpties). If the >>>> prim is serialized then the field "SculptData" is also serialized, which >>>> is >>>> a problem because it contains the entire contents of the mesh or texture. >>>> This makes actions such as detaching a mesh attachment extremely slow. >>>> >>>> I think that we should remove SculptData from the serialized XML format >>>> of >>>> prims. This means that we'll stop serializing it, and when we get an XML >>>> with SculptData we'll ignore it. >>>> >>>> See also: http://opensimulator.org/mantis/view.php?id=7038 ("Unwearing >>>> mesh >>>> attachments very slow"). >>>> >>>> As far as I can tell, the shape's SculptData field (in memory) should >>>> usually be empty. It only needs to be filled with the asset data in two >>>> cases: >>>> 1. When the mesh is first uploaded >>>> 2. If the Physics system needs to create a physics mesh >>>> >>>> In both cases, after the mesh data has been used it should be cleared >>>> immediately, to save memory. >>>> >>>> Regarding the behavior of the physics system, I see a few things that >>>> could >>>> be a problem with the way it's currently implemented. What currently >>>> happens >>>> is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's >>>> needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data >>>> once >>>> it has finished using it. This raises a couple of questions: >>>> >>>> 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim. >>>> 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes >>>> return >>>> early, without clearing the mesh data. Seems to me that it should always >>>> clear it. >>>> >>>> So besides removing "SculptData" from the XML format of prims, I also >>>> want >>>> to make Meshmerizer clear the data more aggressively. And I don't know >>>> how >>>> BulletSim uses meshes, but perhaps it also needs to be changed. >>>> >>>> Thoughts? >>>> >>>> Oren >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >>> _______________________________________________ >>> 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
