<div dir="ltr">Yes, it probably should stay there and just be excluded from the serialization. The memory impact probably wouldn't be too bad unless it's a unique (per SOP) reference and there are a lot of non-phantom mesh and sculptie objects in the region. Hopefully it's not a unique reference, but I didn't write the part that fetches that data and I haven't looked at it in a long time. I'd suggest just excluding it from serialization and see if that fixes the problem at hand.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 11:42 AM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Attachments can be dropped and then need the proxy again.<br>
<span class="HOEnZb"><font color="#888888"><br>
Melanie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 27/03/2014 19:29, Dahlia Trimble wrote:<br>
> Another strategy may be do something along the lines of deleting it if the<br>
> SOP is part of an attachment. Attachments are phantom and do not need<br>
> physics proxies.<br>
><br>
><br>
> On Thu, Mar 27, 2014 at 11:26 AM, Dahlia Trimble <<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>>wrote:<br>
><br>
>> That field contains the asset data, which, in the case of a sculptie is<br>
>> not a mesh but a texture. For ODE, the resulting mesh will be cached once<br>
>> generated and reused, however the asset will need to be reaccessed later if<br>
>> a mesh with another scale is required, or one with different optional<br>
>> parameters such as invert or mirror being set. If you remove the asset<br>
>> data, it will need another asset fetch and multiple attempts to create a<br>
>> mesh until the asset becomes available again. I'd suggest *not* removing<br>
>> the asset data, but rather exclude it from the serialization when it's<br>
>> being stored for attachment purposes so as to reduce as many asset fetches<br>
>> as possible and keep sim startup/load time low.<br>
>><br>
>><br>
>> On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II <<br>
>> <a href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>> wrote:<br>
>><br>
>>> Knock 'em dead Oren xD<br>
>>><br>
>>><br>
>>> On Thu, Mar 27, 2014 at 11:29 AM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>>><br>
>>>> Looks like you found the culprit! All those suggestions sound good.<br>
>>>><br>
>>>> Melanie<br>
>>>><br>
>>>> On 27 Mar 2014, at 17:03, Oren Hurvitz <<a href="mailto:orenh@kitely.com">orenh@kitely.com</a>> wrote:<br>
>>>><br>
>>>> When a prim is a Sculptie or Mesh, the prim's shape contains a field<br>
>>>> called<br>
>>>> SculptData which stores the full mesh or texture (for sculpties). If the<br>
>>>> prim is serialized then the field "SculptData" is also serialized, which<br>
>>>> is<br>
>>>> a problem because it contains the entire contents of the mesh or texture.<br>
>>>> This makes actions such as detaching a mesh attachment extremely slow.<br>
>>>><br>
>>>> I think that we should remove SculptData from the serialized XML format<br>
>>>> of<br>
>>>> prims. This means that we'll stop serializing it, and when we get an XML<br>
>>>> with SculptData we'll ignore it.<br>
>>>><br>
>>>> See also: <a href="http://opensimulator.org/mantis/view.php?id=7038" target="_blank">http://opensimulator.org/mantis/view.php?id=7038</a> ("Unwearing<br>
>>>> mesh<br>
>>>> attachments very slow").<br>
>>>><br>
>>>> As far as I can tell, the shape's SculptData field (in memory) should<br>
>>>> usually be empty. It only needs to be filled with the asset data in two<br>
>>>> cases:<br>
>>>> 1. When the mesh is first uploaded<br>
>>>> 2. If the Physics system needs to create a physics mesh<br>
>>>><br>
>>>> In both cases, after the mesh data has been used it should be cleared<br>
>>>> immediately, to save memory.<br>
>>>><br>
>>>> Regarding the behavior of the physics system, I see a few things that<br>
>>>> could<br>
>>>> be a problem with the way it's currently implemented. What currently<br>
>>>> happens<br>
>>>> is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's<br>
>>>> needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data<br>
>>>> once<br>
>>>> it has finished using it. This raises a couple of questions:<br>
>>>><br>
>>>> 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim.<br>
>>>> 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes<br>
>>>> return<br>
>>>> early, without clearing the mesh data. Seems to me that it should always<br>
>>>> clear it.<br>
>>>><br>
>>>> So besides removing "SculptData" from the XML format of prims, I also<br>
>>>> want<br>
>>>> to make Meshmerizer clear the data more aggressively. And I don't know<br>
>>>> how<br>
>>>> BulletSim uses meshes, but perhaps it also needs to be changed.<br>
>>>><br>
>>>> Thoughts?<br>
>>>><br>
>>>> Oren<br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> View this message in context:<br>
>>>> <a href="http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html" target="_blank">http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html</a><br>

>>>> Sent from the opensim-dev mailing list archive at Nabble.com.<br>
>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> ===================================<br>
>>> <a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br>
>>> <a href="http://simhost.com" target="_blank">http://simhost.com</a><br>
>>> <a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>><br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>