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.ch...@alternatemetaverse.com
<mailto: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 <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
<jjusti...@googlemail.com <mailto: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
<mailto: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
<mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Robert L Martin
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de <mailto: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
