| Age | Commit message (Collapse) | Author |
|---|
|
secondlife/viewer#76: Change wording of terrain blending documentation when using materials
|
|
|
|
fallback fonts.
With the emojis support, a new font was added, which not only provides emojis
but also fancy colorful replacements for UTF-8 characters that used to be
supported by our fallback (monochrome) fonts: this causes discrepancies and
unwanted/undesired changes in scripted objects menus (e.g. an empty circle or
square may render as a black, full one, a heart may render red instead of white),
not to mention the larger font size used by the emoji characters...
This patch restores the aspect of such menus/dialogs/UI elements with UTF-8
characters that *are* supported by the usual fallback fonts (fonts which may
also vary from one viewer to another, and from one OS to another), so that
everything keeps working/rendering as it always did so far, while not impairing
the use of new colorful emojis.
This second proposal ensures that:
- "genuine" emojis (in the 0x1f000-0x1ffff range), will *always* be rendered
using the new emojis font (this solves, for example, the monochrome "yellow
faces" issue seen with some characters in my first proposal).
- Special UTF-8 characters (in the 0x2000-0x32FF range) which have been used by
scripters so far, will render as they used to, using the monochrome fallback
fonts (this repairs scripted dialogs menus).
- Remaining special characters, that do not have a corresponding glyph in the
monochrome font, but do have one in the emojis font, will use the latter font
to render.
It also got the nice side-effect of removing the dependency on the ICU4C library.
Note however that the recent commit:
https://github.com/secondlife/viewer/commit/326055ba82c22fedde186c6a56bafd4fe87e613a
will need to be reverted to allow this patch to actually fix scripted dialogs.
Also, some cleanup might be needed in skins/default/xui/*/emoji_characters.xml to
remove from it the special UTF-8 characters that will no longer be rendered with
fanciful colors, but instead with the monochrome font glyphs.
|
|
labels should match the current context
|
|
using materials
|
|
secondlife/viewer#926 chage openexr lib to use static link on mac
|
|
|
|
This reverts commit ce6170802de1833a8d0d55e9dfc774c4c9dd7eca.
|
|
* #975 Add RenderHDRISplitScreen debug setting
* Create hdri_local_preview.md
|
|
* Create RenderMaxTextureResolution.md
* #983 Add RenderMaxTextureResolution setting. Incidental crash fix.
|
|
secondlife/viewer#906: Add test plan for PBR terrain tiling
|
|
test plan
|
|
|
|
secondlife/viewer#906: Bump PBR terrain scale, decreasing texel density by 1/2
|
|
|
|
|
|
static libs
|
|
switching mac lib to be statically linked
autobuild installables edit openexr platform=darwin64 url=https://github.com/secondlife/3p-openexr/releases/download/v1.10/openexr-3.2.2-darwin64-df7544d.tar.zst hash_algorithm=sha1 hash=17cd63922214b588d9a36137fadf927237ec0f25
autobuild installables edit openexr platform=linux64 url=https://github.com/secondlife/3p-openexr/releases/download/v1.10/openexr-3.2.2-linux64-df7544d.tar.zst hash_algorithm=sha1 hash=b092658ab5ec009a5875e8b6e5b7109730ad6846
autobuild installables edit openexr platform=windows64 url=https://github.com/secondlife/3p-openexr/releases/download/v1.10/openexr-3.2.2-windows64-df7544d.tar.zst hash_algorithm=sha1 hash=c511ae9a3e401375af2199b498a75f32cebc010f
|
|
Scaling was added to thumbnail images as a measure of memory preservation and said scaling doesn't work well when larger images are needed so had to remake profile images to no longer use thumbnails.
|
|
secondlife/965-eep-skies-too-bright-after-hdri-local-preview-merge
965 eep skies too bright after hdri local preview merge
|
|
|
|
https://github.com/secondlife/viewer into 965-eep-skies-too-bright-after-hdri-local-preview-merge
|
|
PBR Terrain UI second pass: review follow-up
|
|
llDialog buttons
|
|
|
|
|
|
|
|
|
|
material_detail_* controls
|
|
* #926 WIP - HDRI import prototype v0
* #926 WIP -- add OpenEXR to autobuild.xml
* #926 WIP -- Add OpenEXR cmake
* #926 WIP -- Attempt at using OpenEXR autobuild package and don't hard code .exr file to load
* #926 Unmangle autobuild.xml and get dll's in the right place (thanks, Caladbolg!)
* implement mac shared libs plumbing for OpenEXR for secondlife/viewer#926
* Fix Xcode/clang compile error regarding new[]/delete[] mismatch
* #926 HDRI Preview finishing touches.
- Full ACES when HDRI is enabled
- Fix for probes getting stuck paused
- Add exposure and rotation controls
---------
Co-authored-by: Brad Linden <brad@lindenlab.com>
|
|
#681 Mirrors quality pass 1.
|
|
Make signing and symbol posting jobs conditional on secrets.
|
|
|
|
Shift-dropping textures can fail if one of 'early' faces has nomod
material
|
|
|
|
|
|
|
|
|
|
PBR Terrain UI second pass
|
|
|
|
Was caused by package substituting '&' with 'and' instead of '&'
|
|
The build step no longer needs these variables at all: they're used in a
subsequent workflow job.
|
|
From https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow :
"Secrets cannot be directly referenced in if: conditionals. Instead, consider
setting secrets as job-level environment variables, then referencing the
environment variables to conditionally run steps in the job."
|
|
release/materials_featurette
|
|
The previous construct produced:
Unrecognized named-value: 'secrets'. Located at position 1 within expression:
secrets.AZURE_KEY_VAULT_URI && ...
|
|
Specifically, when secrets aren't available (e.g. for external PRs), skip the
affected steps.
|
|
|
|
|
|
Issue #54 LLRender::init crash and SL-17896
|
|
Mark issues as stale but do not close them.
|
