| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
fall below current viewer discard level 2 thresholds.
Viewer LL 3.3.4 and before sometimes fail to properly redisplay dynamic textures that have a small data length compared to pixel size when pulled from cache.
This appears to happen when the data length is smaller than the estimate discard level 2 size the viewer uses when making this GetTexture request.
This commit works around this by always regenerating dynamic textures that fall below this threshold rather than reusing them if ReuseDynamicTextures = true
This can be controlled by the [Textures] ReuseDynamicLowDataTextures config setting which defaults to false.
|
|
|
|
| |
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
|
|
|
| |
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
that of an otherwise valid asset, return HTTP PartialContent rather than RequestedRangeNotSatisfiable.
This is because recent viewers (3.2.1, 3.3.4) and probably earlier ones using the http GetTexture capability will sometimes make such invalid range requests.
This appears to happen if the viewer's estimate of texture sizes at discard levels > 0 (chiefly 2) exceeds the total texture size.
I believe this does not normally happen but can occur for dynamic textures with are large but mainly blank.
If this happens, returning a RequestedRangeNotSatisfiable will cause the viewer to not render the texture at the final resolution.
However, returning a PartialContent (or OK) even with 0 data will allow the viewer to render the final texture.
|
| |/
|/|
| |
| | |
Thanks Hiro Lecker for a patch to reduce memory useage with Warp3D map module
|
|/
|
|
| |
Thanks SignpostMarv!
|
| |
|
| |
|
|
|
|
| |
UUID argument
|
| |
|
| |
|
|
|
|
| |
attachment point
|
|
|
|
|
|
|
|
|
| |
Second Life seems to have introduced a bug, as we have confirmation that SL
behavior changed recently and changed in contradiction to their stated intention
This appears to be another of the bugs SL is notorious for. Signpost and I have
decided to back this out until SL's intention becomes clear.
This reverts commit f7b88d1c40ba06c62491d8d32809fe6c1c4d360d.
|
|
|
|
| |
This reverts commit a3d140b57c5e2ae0f3334d59b82e116d40199b49.
|
|
|
|
| |
This reverts commit fb211c64fd9d335f4879549023870b1e28416f74.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Major rework of terrain management which finally makes mega-regions work.
Update heightmap of terrain by rebuilding the terrain's body and shape.
There is a problem with just replacing the shape so this workaround
will do for the moment but it will need to be resolved for
mesh and hull switching.
|
|
|
|
|
|
|
| |
Update DLL API for new terrain and shape/body pattern methods.
Terrain creation and modification uses new shape/body pattern.
Move debug logging callback set to initialization call so logging
is per physics engine.
|
| |
|
|
|
|
|
|
|
|
|
| |
Moved all terrain code out of BSScene and into new BSTerrainManager.
Added logic to manage multiple terrains for mega-regions.
Added new functions to BulletSimAPI to match the library.
Moved all of the terrain creation and setup logic from C++ code to C# code.
The unused code has not yet been removed from either place. Soon.
Moved checks for avatar above ground and in bounds into BSCharacter.
|
|
|
|
| |
BSLinkset only know of BSPhysObject's and there is only one list to search in BSScene.
|
|
|
|
| |
move nearly all of the logic into the C# code.
|
| |
|
|\ |
|
| |
| |
| |
| | |
GetLinkParts than mantis 6236
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
even test compiled.
|
|
|
|
|
|
|
|
|
|
| |
Default is false, as before.
If true, this setting reuses dynamically generated textures (i.e. created through osSetDynamicTextureData() and similar OSSL functions) where possible rather than always regenerating them.
This results in much quicker updates viewer-side but may bloat the asset cache (though this is fixable).
Also, sometimes issue have been seen where dynamic textures do not transfer to the viewer properly (permanently blurry).
If this happens and that flag is set then they are not regenerated, the viewer has to clear cache or wait for 24 hours before all cached uuids are invalidated.
CUrrently experimental. Default is false, as before.
|
|
|
|
| |
metadata still exists for any reused asset in case some other process has removed it from the cache.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
type for an HTTP request. Since the "official" LSL function limits
the use of the response type, it is implemented as osSetContentType
with a string for the content mime type and a threat level of high.
With this function you should be able to implement rather functional
media-on-a-prim application with much less difficulty.
|
| |
|
|
|
|
| |
rule number tracking in next commit.
|
|
|
|
|
|
|
|
|
|
|
| |
folders with asset type of 'Folder' and 'Unknown' were accidentally treated as system folders.
This prevented more than one additional ordinary folder from being created in the base "My Inventory" user folder.
Added regression test for this case.
Switched tests to use XInventoryService with mostly implemented TestXInventoryDataPlugin rather than InventoryService
Disabled TestLoadIarV0_1SameNameCreator() since this has not been working for a very long time (ever since XInventoryService) started being used
since it doesnt' preserve creator data in the same way as InventoryService did and so effectively lost the OSPAs.
However, nobody noticed/complained about this issue and OSPAs have been superseded by HG like creator information via the --home save oar/iar switch.
|