In that case, i concur, just exclude it from serialization. Melanie
On 27/03/2014 19:26, Dahlia Trimble 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
