| Age | Commit message (Collapse) | Author |
|---|
|
|
|
(or folder containing - among others - exactly one texture) and when hovering over notecard embedded textures
|
|
|
|
irradiance maps from being brighter than the environment.
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
|
|
2GB), remove irradiance map feedback loop (one bounce, but but more stable and allows for much brighter first bounce), make sky contribution to irradiance not tint the world blue. Make irradiance that appears in radiance maps match world irradiance.
|
|
|
|
blending. (#63)
* SL-19203 WIP -- Integrate SSR with reflection probes. Decruft LLRenderTarget.
* SL-19203 WIP -- Re-integrate SSR. Incidental decruft.
* SL-19203 WIP -- SSR frame delta correction (still broken for Z)
* SL-19203 WIP -- SSR frame delta Z fix
* SL-19203 WIP -- Make SSR toggleable again and disable SSR in cube snapshots.
* SL-19203 WIP -- Soften sphere probe transitions and fix reflections on void water (make fallback probe a simple terrain+water+sky probe). Remove parallax correction for automatic probes to reduce artifacts.
* SL-19203 Tune probe blending.
* SL-19203 Cleanup.
|
|
This reverts commit 4d429b7ea31f51f653e0e2ad6b5799a515e28334.
|
|
|
|
|
|
|
|
|
|
macOS build forwards
|
|
|
|
working, the flag was introduced to warn (and therefore error out) when a virtual override was not marked with the 'override' keyword. Fixing this up involved a large number of changes and this commit represents just those changes - nothing specially from the DRTVWR-489 viewer
|
|
|
|
SL-19081: Fix assert when uploading texture
|
|
|
|
SL-19012: Fix new material IDs sometimes not applying when set via LSL
|
|
|
|
therefore an error) but only on 32bit Windows builds - 64bit is fine. I don't know why that's the case (should be both surely) but in any case, I think the variable should be declared as a size_t
|
|
with access to TeramCity - with all the ICU4C DLLs removed, the viewer builds fine which does suggest a size/disk space issue. Trying with the (porposed) minimum set to see if this helps. Likely it won't because the main one (icudt48.dll) is much, much bigger than the others combined - but we shall see
|
|
with access to TeramCity - one theory is that the extra size of these DLLs consumes too much disk space and results in the NSIS internal compiler error we observe - removing these tempoorarily to see what difference that makes
|
|
|
|
|
|
|
|
|
|
builds fail because of 'compiler error' in NSIS - wondering if this warning triggers the error (it doesn't locally) - yes, grasphing at straws
|
|
decruft.
|
|
|
|
|
|
|
|
Inspect and copy doesn't work for face or child selection. Disable them in such cases.
|
|
the right place in Windows builds
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
