* Fix for SL-20652 shadows on mac breaking alpha blended objects.
fixsecondlife/jira-archive-internal#71030
* clean up surrounding indentation
* Skip unnecessary casting
* Clean up LLGLSLShader::sIndexedTextureChannels usage and improve fix for SL-20652
* #1139 Fix for world going black/white in some scenes (NaNs)
NaNs were coming from normal encode/decode. Take advantage of available gbuffer space to send full normal instead of encoding.
* #1139 Cleanup
remove now unused encodeNormF.glsl
* #1139 Remove final reference to encodeNormF
* #1139 Fix for getNormalEnvIntensityFlags referencing wrong sampler for env intensity
* Mac build fix
* #1176 Somewhat working GLTF Node support for translate tool
* #1176 Missing file from last commit
* #1176 Better translation for rotated nodes.
* #1176 Fix for objects snapping back to original position
* #1176 GLTF Samples compatibility pass -- attempt at improving rotation manip support, incidental cleanup, GLTF node debug display
* #1176 Clean out some unused and not working functions.
* #1176 Fix for mac build, incidental cleanup
* Mac build fix
* #1126 GLTF Scene import initial prototype (working geometry import for some assets)
* #1126 WIP -- Expand support for more vertex formats, PoC material import, shadow support, scale support
* #1126 move GLTF implementation to newview/gltf
* #1126 Refactor attribute loading to be less copy/pasta for each combination of types
* #1126 Partially working object selection. Ability to have multiple scenes at once. Helpful message on how to use the preview button.
* #1126 Add bounding box debug display and untangle GLTF raycast from LLVOVolume raycast
* #1126 Working raycast on GLTF scenes.
* #1126 Remove some #pragma optimize offs
In the recent emojis implementation, the text color alpha is ignored
(emojis are always rendered with an opaque white color), causing them
to fail and fade properly with the rest of the text they are printed
with.
This trivial patch fixes this issue.
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:
326055ba82
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.
Andrey Kleshchev