[Opensim-dev] OpenSim.exe console - progress messages with mesh uploads
Mike Chase
mike.chase at alternatemetaverse.com
Fri Aug 30 18:51:17 UTC 2013
On 08/30/2013 01:54 PM, Dahlia Trimble wrote:
> 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?
You need to skip the first 2 bytes of the stream..
From the code:
using(MemoryStream inMs =new MemoryStream(data, offset, size))
{
/*
*Skippingpastthefirsttwobytes,whicharepartofthezlibspecification
*(RFC1950),notthedeflatespecification(RFC1951).Thosebytescontain
*informationaboutthecompressionmethodandflags.
*/
int streamType = inMs.ReadByte();
int streamFlags = inMs.ReadByte();
using(MemoryStream outMs =new MemoryStream())
{
using(DeflateStream zOut
=new DeflateStream(inMs, CompressionMode.Decompress))
{
zOut.CopyTo(outMs);
byte[] decompressedBuf = outMs.ToArray();
return OSDParser.DeserializeLLSDBinary(decompressedBuf)as OSDArray;
}
}
>
> 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.
Yeah being able to characterize exactly when the hang happens (what
phase of the upload) would help. There is a specific set of steps taken
from calculate to the upload that actually have some intermediate server
interactions. Knowing where the failure occurs from a UI perspective
would help track it down.
Mike
>
>
> On Fri, Aug 30, 2013 at 6:56 AM, Mike Chase
> <mike.chase at alternatemetaverse.com
> <mailto:mike.chase at 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 <http://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
>> <jjustincc at googlemail.com <mailto:jjustincc at 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 at lists.berlios.de
>> <mailto:Opensim-dev at 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 at lists.berlios.de
>> <mailto:Opensim-dev at lists.berlios.de>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> --
>> Robert L Martin
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20130830/1454e04b/attachment-0001.html>
More information about the Opensim-dev
mailing list