Hi, this is a potentially very serious bug.
For prims, OpenSim will indeed save the prims back into an asset when they are unworn if they have changed or contain scripts. This is because script states are saved as part of the object. Mesh of course needs to be detected and treated differently. Resaving mesh is incredibly wasteful and should just not happen. Melanie On 25/03/2014 22:16, Aine wrote: > At today's dev meeting, Justin asked me to post to the mailing list to ask > whether anyone can confirm my observation that when you wear a mesh object > and then un-wear it, the full mesh data is being sent from the region server > to the asset server and waits for an update response before it processes any > further actions. > > > > Steps to most easily reproduce: > > > > 1. Create a mesh object that is far more detailed than you would normally > create (something in the 40k vert range). Rigged, weighted, UV mapped and > normal-mapped, this will result in a dae that's about 10MB in size which > will then be easy to spot when testing. Obviously a 10MB mesh is far too > large to wear normally but this is the best means to demonstrate the issue. > I can supply a test file if someone wants to try this but isn't able to > create the dae. > > > > 2. Stand in a region where you are able to monitor the outbound and inbound > data traffic between the region server and the asset server (for super-easy > test, be in a home-hosted region with an ISP connection under 5Mbps that is > connected to OSG) > > > > 3. Upload the mesh (brew coffee while waiting for it to finish). You'll > notice outbound traffic during the upload as the geometry, etc is being sent > to the asset server. The total traffic will be a little larger than your > original file because LOD and physics also has to be stored. If you're very > patient, upload it with silly LOD settings to have it display at nearly > maximum mesh resolution at all distances and to use the highest possible > quality physics mesh just so the asset is truly enormous (but never do this > for a real asset!) > > > > 4. Select an attachment point that you normally have something else attached > to (the skull, for instance, where most people wear prim hair). Detach > whatever is currently there. > > > > 5. Attach the mesh to that point. Don't do anything else -- don't texture it > or change it in any way. Just attach. > > > > 6. Now from inventory, wear whatever normally mounts to that attachment > point (assuming your viewer is set to replace objects on attachment points > by default) which will cause the mesh to be detached and the other object to > be attached. > > > > 7. Monitor the outbound data traffic for the region and also see how long it > takes your other object to appear. > > > > 8. Repeat this over and over again, swapping back and forth between the hair > (or whatever) and the mesh while watching the traffic. Depending on your > debug settings, also watch the console for messages. > > > > Once you hit step 8, both objects are being worn from the viewer cache at > this point so there is almost no traffic at all between the viewer and the > region other than very small blips of data. Every time you unwear the mesh, > there's a lengthy delay and the outbound traffic will show that a huge > amount of data is being sent -- at least the entire geometry and possibly > this also includes the UVs, normals, LOD and physics data (I have no idea > since I'm only looking at total MB of data sent, not the actual contents of > the packets) -- and it isn't until that data is fully sent that your other > object (hair) will attach itself and rez. When you detach the hair, it > disappears and is rapidly replaced with the mesh (since it's coming from > your viewer cache) and there is minimal outbound traffic (barely a blip) > between the region server and the asset server. > > > > When unwearing the mesh object if you're in a region with a slower outbound > connection speed you will also see a console warning message complaining > about how long it took to received a response from the asset server to > confirm that the asset had been updated. Example: > > > > 17:33:09 - [SynchronousRestObjectRequester]: Slow request 9912 POST > http://assets.osgrid.org/assets/ took 7098ms, 94ms writing, ?<?xml > version="1.0" encoding="utf-8"?><AssetBase > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns > > > > Obviously this shouldn't be happening. Mesh attributes such as geometry, > physics, etc can't change after upload so the only data that *should* be > sent is the normal block sent when you unwear a prim or sculptie; and both > Justin and Dahlia were skeptical at the dev meeting when I reported the > issue so it would be helpful to know if anyone else is experiencing this, or > to have someone else independently test and confirm that it's happening. > Obviously nobody should be wearing mesh attachments of this extreme size; > however a full mesh avatar wearing mesh clothing, mesh footwear, mesh > jewelry, etc can begin to approach these sorts of total vertex counts if > they do an outfit change; and even if not, it's still something that > shouldn't be happening regardless of the mesh sizes. It may also be a > contributing factor in the frequent issue where teleports fail for anyone > wearing more than one or two very low poly-count mesh attachments. > > > > Link to Mantis for this issue: > http://opensimulator.org/mantis/view.php?id=7038 > > > > > > _______________________________________________ > 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
