I don't think the mesh is decompressed during the upload but it is decompressed when first rezzed in the scene, in order to generate a physics collision proxy.
Mike, I'm surprised you got it to work with the .Net decompression libraries. When I first did the mesh physics collider code, the compression the viewer used was not compatable with the .Net gzip decompressor. Are you using something other than that library? Also, with regards to the viewer hanging during upload, has anyone determined whether the problem is in the viewer, or in the simulator? The simulator really shouldn't care about size until the mesh is actually rezzed in a region, otherwise it's just a large blob that will be stored in the asset system. Perhaps trying to upload that same mesh to one of the Linden grids might provide some insight. On Fri, Aug 30, 2013 at 6:56 AM, Mike Chase < mike.ch...@alternatemetaverse.com> wrote: > On 08/30/2013 08:58 AM, Robert Martin wrote: > > one thing that might help things here is have some way of having the > simulator "bounce"/return zero when it is doing the calculate cost stage of > a mesh upload. > > > That's not really going to help I don't think. I don't believe the > OpenSim implementation does anything or even looks for the mesh data when > the cost stage is executed. > > Mesh upload happens in 2 stages. When you push the calculate button the > client crunches data and sends a snapshot of it along with the > NewAgentInventory request to the server. The server returns the upload > cap along with any optional cost calculations it has done. The client then > re-contacts the server at the new cap and transmits the data (again) for > the actual upload. > > There are two likely places for bottlenecks and depending on what core > opensim does an additional place where a failure is possible. > > 1) The initial calculations done by the client. If this is the case its > going to be seen prior to the upload button enabling. > 2) The actual data transmission. Probably not a problem because it's > using HTTP for the transfer in both cases. Also if you are seeing the > upload button enable then that transmission has already happened once. > Which would indicate its probably not the issue. > > There is an additional scenarios I hit when I did the implementation for > InWorldz. The zlib.net decompression code occasionally throws > indicating an invalid code stream. IDK if the upstream code actually > cracks open the mesh in any way but if so its entirely possible thats what > is failing and the exception is being eaten. In the InWorldz case I > replaced the zlib calls with the compression/decompression code in .NET and > resolved the issue that way. Its something additional to check. > > So more than likely from the description the issue is with asset creation > or something that's done after the transmission takes place. > > Hope this helps a bit. > > Mike > > > > On Thu, Aug 29, 2013 at 6:48 PM, Justin Clark-Casey < > jjusti...@googlemail.com> wrote: > >> I'm not sure this will be possible as I believe mesh is uploaded via a >> single HTTP post, which isn't easy to monitor server-side. It's also >> possible that the mesh you're trying to upload is unfortunately simply too >> large and that we should have (optional) server-side enforced limits. But >> this is speculation on my part. >> >> Is this a purely local upload or one to a server not on the same system? >> If the server is on a different system, possibly you could install a >> monitoring tool to check your rate of data upload. Naturally, one would >> expect a server on a local LAN to be very quick, but a remote one might be >> different and even on the local scenario, things like slow wifi might come >> into play. >> >> Perhaps you could install a monitoring tool on your system >> >> On 24/08/13 17:22, Ai Austin wrote: >> >>> I wonder if its possible to get any debugging related to mesh uploads >>> and their progress (or otherwise). >>> >>> I think I am timing out even when I set the AckTimeout = 600 as >>> suggested by Justin and want to try to figure out >>> the stage at which the problems occur. >>> >>> I am uploading some Collada meshes that are 20MB up to 100MB in size.. >>> and got them in once.. but cannot reliably repeat >>> that especially f I try to vary the upload options to scale the incoming >>> mesh, or if I add any physics details. >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Robert L Martin > > > _______________________________________________ > Opensim-dev mailing > listOpensim-dev@lists.berlios.dehttps://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
