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
