Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

7.1.11 blacks screen when entering certain RLV zones with setenv_scenegamma:0.0=force

Description

Since Kokua 7.1.11 the viewer changes to a completely black screen when entering certain RLV zones.

The same RLV zones were fine with Kokua 7.1.10.

Comparing the effects of a) safewording and b) leaving the RLV zone makes me assume that “setenv_scenegamma:0.0=force” is related to the problem, esp in combination with “setenv=n”. The former makes the screen black and the latter prevents the RLV user from changing their environment to regain vision.

Observation: When I safeword from the RLV zone but don’t leave it, the screen remains black. But then I can manually change the environment and get vision again. After this I can enter and leave the RLV zone and experience the expected vision (darkened view in the zone, clear view outside). But just until changing the environment again. If I do so, the next entry to the zone leads to the black screen again.

Attachements show examples for the observed view and the one after the safeword-based workaround.

 

Thanks to Dilfuza for showing me the behavior!

Environment

RLV debug when entering the zone:

Executes: tploc=n

Executes: tplm=n

Executes: tplure=n

Executes: shownames=n

Executes: camdistmax:2=n

Executes: setenv=n

Executes: setenv_scenegamma:0.0=force

 

When safewording:

Executes: setenv=y

Executes: camdistmax:2=y

Executes: shownames=y

Executes: tplure=y

Executes: tplm=y

Executes: tploc=y

 

When finally leaving:

Executes: setenv_scenegamma:1.0=force

Attachments

2

Activity

Show:

Chorazin Allen 4 January 2025 at 18:22

Fix merged into Marine’s repo - applying it for Kokua next. That’ll automatically close this ticket but it can be reopened if the new values turn out to be significantly wrong on Mac

Marine Kelley 4 January 2025 at 17:28

Thank you for looking into it and for registering the values. I don’t know what function gamma uses, it looks logarithmic to me but I’m sure there’s a clever function defined somewhere. Your table will yield acceptable results, I think, but eventually I guess it will be replaced by the actual function, once someone figures out what it is. If you want to implement it, go ahead, I’ll accept the PR as soon as it comes.

Thanks a lot !

Chorazin Allen 4 January 2025 at 17:24
Edited

As a spot check, could you try setenv_scenegamma:0.5 and confirm that’s like the effect there was previously from setenv_scenegamma:0.0 - I did my tests on Windows rather than Mac.

Chorazin Allen 4 January 2025 at 17:22

Thanks for the comments. After some experimenting I think this gives a behaviour like before. The translation is non-linear although I’ve tried to break it into linear segments, ie 0 to 1, 1 to 5, 5 to 20. It’s not helped by 1 being the default value before and after.

setenv_scenegamma

new internal value

<= 0

0.5

1

1

5

2

10

2.3

15

2.6

>= 20

2.9

Since scenegamma can be read back with getenv, there’s going to need to be a both way translation to support the principle that a script should be able to read back the same value that it put in.

Note: Although the API docs define it as 0-10, it’s really 0-20 underneath, so I’ve allowed for that here.

If this looks OK, I’ll do it as a pull request for the RLV repo initially and then pull it into Kokua once it’s been accepted into your repo.

Marine Kelley 4 January 2025 at 14:05

I agree, I think the best course of action is to make sure the command does the same as it always did, i.e. setting value 0 should yield pitch black but not entirely black, while 20 should keep being moderately bright as it used to be. So some kind of double interpolation is needed. Old scale to a ratio between 0 and 1, then that ratio to the new scale.

Then, later, maybe make a second version of the command that uses the current scale (provided it does not change again in the meantime) so old scripts keep working and new scripts have the choice.

Done

Details

Assignee

Reporter

Variant

FTRLV

Platform

Mac

Fix versions

Components

Affects versions

Priority

Created 2 January 2025 at 13:26
Updated 15 March 2025 at 11:57
Resolved 4 January 2025 at 18:36