| Age | Commit message (Collapse) | Author |
|---|
|
as requested by Bavid Dailey.
Having timestamp is set as the default.
|
|
|
|
now that we don't need the user to authorise Discord SDK to have
any access to the user's friends list, etc. (which are Discord
Relationships related, and not needed just for Rich Presence).
|
|
Use NearMeRange to minimize difference with SLv
|
|
|
|
|
|
|
|
|
|
Add option to show/hide avatar name in privacy panel & connect rich presense directly to llappviewer.cpp
|
|
I was going to use LLAgentUI::buildLocationString but there's no
location format that shows only region and coords without having
to have the parcel name empty, so I copied buildLocationString
implementation in the case of LOCATION_FORMAT_NO_MATURITY but when
the parcel name is empty.
I had to make updateDiscordActivity check agent's ID and the
existence of agent avatar pointer first before trying to set
Activity Details or State, cause I like the "Show location" button
be checkable not only after online when both the ID & pointer will
have existed. I think this way is simpler than programmatically
enabling the "Show location" button after the user is logged in.
I put a trigger to Activity update somewhere after the user is
logged in for now, not yet after a TP.
The elapsed time gets reset whenever Activity is updated for now,
but I'll try to make elapsed time extended instead.
No Party for now, because I couldn't find a way to make a Party
shown without showing its CurrentSize (I could still get away not
showing its MaxSize by setting it to 0), so the State (location)
is shown above the elapsed time, not on the right of it.
I'll try to figure out to get some representative numbers for its
CurrentSize & MaxSize next.
Also no privacy on hiding the username for now, until the UI is
ready.
|
|
Now the access token is saved the way passwords are saved, but
without a username, so we can have some persistence without having
to implement an OAuth2 backend server cause we would have to store
those tokens there anyway still and that would even require more
disclosure that the user token gets saved on a server, and it's
just simpler to not go that way. Discord Social SDK doesn't have
to have a helper for sending code to a custom server anyway, that
we would have to have some asynchronous HTTP requestor ready.
Show location check button gets enabled only when Discord
integration is enabled, though it's not functioning yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
for better comparison with collada output
|
|
|
|
First pass at adding expanded frametiming stats to the viewer.
|
|
|
|
Media changes including support for PRIM_MEDIA_FIRST_CLICK_INTERACT and HUD autoplay
|
|
|
|
(Eventually - marshalled by [GIRD LOWER])
|
|
Welcome Pack
|
|
|
|
Make DisableLookAtAnimation setting persistent across restarts.
|
|
Decrease to 256 to reduce aggressive culling & make user changes to this value persistent across restarts.
|
|
|
|
into 2025.04
|
|
|
|
|
|
|
|
illustration
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Refactor tonemap blending to preserve HDR detail during mix
|
|
The blending operation for the `tonemap_mix` uniform in `postDeferredTonemap.glsl` incorrectly used a prematurely clamped color value as the source for the linear mix target. Specifically, the exposed HDR input color was clamped to the [0, 1] LDR range before being used in the `mix()` function when `tonemap_mix < 1.0`.
This premature clamping resulted in the loss of High Dynamic Range (HDR) detail in highlights during the blend operation. As `tonemap_mix` was reduced, instead of smoothly blending towards the linear scene representation, clipped highlights were incorrectly reintroduced.
This commit modifies the `toneMap` and `toneMapNoExposure` functions to correct this logic:
1. The original linear input color is preserved before exposure/processing.
2. The appropriate exposure factor is calculated and applied separately.
3. The chosen tone mapping operator is applied to the exposed color, storing the result.
4. The `mix()` function now correctly blends between the appropriately scaled, *unclamped* linear input color and the fully tone-mapped result.
5. The final clamp to the [0, 1] LDR range is applied *after* the blend operation.
This change ensures that HDR information is preserved throughout the blending process, resulting in a smoother, more perceptually correct visual transition as `tonemap_mix` is adjusted. While the effect is nuanced, it is noticeable in bright highlights; with the legacy code, these highlights appeared visibly clipped and less intense during the blend, whereas the corrected code allows them to retain their peak brightness and detail more accurately. This makes the `tonemap_mix` control more intuitive, behaving as a true intensity blend for the tone mapping effect without introducing clipping artifacts. The computational cost is negligible.
|
|
Partial revert from d00b6e4216bb308ae075d90dfa871c902d765f8d
Our statistics claimed that AudioLevelWind is unused, but it is in use.
|
|
|
|
|
|
New optimisation and resolution shadow options
|
|
|
|
|
|
|
