Unable to get to the bottom of why resizing a mesh fails to properly reset the physics proxy, when toggling phantom does
After a mesh is generated, the existing sculptdata is set to zero in PrimitiveBaseShape to save memory
When phantom is toggled, the sculptdata is regenerated before remeshing.
But on resize, the sculptdata is not regenerated.
So clearly, resetting sculptdata is possible, but haven't quite been able to pin down how this is being done when phantom is toggled.
We compare existing and loaded asset by doing an SHA1 on both, so that a changed library asset will still update the store.
This cuts asset library load time from 10 seconds to <1 sec.
Note, a fix on the previous commit revealed a bug where a library script cannot be copied except on the first login after a cache clear.
This is unrelated to this commit and needs to be fixed at some subsequent time.
As per http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format, some submesh blocks may just have the flag "NoGeometry" to signal that they provide no mesh data.
If a block contains this, ignore it for meshing purposes rather than suffer a ClassCastException
This fixes physics proxy meshing, so you can now walk through mesh doorways, properly stand on the trailer of mesh trucks, etc.
To get mesh physics proxy, the UseMeshiesPhysicsMesh must be true in a [Mesh] config section in OpenSim.ini (example in OpenSimDefaults.ini).
Convex hull physics not currently supported.
This reverts commit b8e7258051.
Letting this go in would prevent land owners from banning someone who would
have incidental editing rights through a group. The land owner should be the
only unbannable person.
This matches the ability to disable the memory part
This is controlled through the FileCacheEnabled parameter in FlotsamCache.ini
Default is true, so existing installations are not affected.
Improved fcache command feedback when various caches are disabled.
Re-enabled test for flotsam cache with file caching disabled.
If a user with a very large inventory right-clicks on their "My Inventory" folder, viewer 1 code will send a massive number of Fetchinventory requests.
Even though each is handled asynchronously via a pool thread, the sheer frequency of requests overwhelms the pool and freezes inbound packet handling.
This change makes the first Fetchinventory thread also handle subsequent requests, freeing up the other threads.
Further efficiencies could be made by handling all the items in a particular FetchInventory request together, rather than separately.
This is to avoid problems with corrupt inventories where an inventory link target points back at the source's folder
No viewer has been observed to set these up as of yet. If this ever happens, we will need a more sophisticated solution to track sent folders within the recursion
Melanie