volumecommand.volume transparency argument broken

[tic20@…]

The following bug report has been submitted:
Platform:        Linux-4.20.8-200.fc29.x86_64-x86_64-with-fedora-29-Twenty_Nine
ChimeraX Version: 0.9 (2019-05-15)
Description
This was working fine on my work machine yesterday (on a ~1-week old ChimeraX build - after the Volume API changes Tom notified me about). Now, if I open a model and map using the Clipper plugin and start navigating around, those volumes with a transparent representation fade to invisibility within the first few frames (they're still there - it's just that the alpha channel is somehow being multiplied down every time the contours are recalculated). 

Log:
UCSF ChimeraX version: 0.9 (2019-05-15)  
© 2016-2019 Regents of the University of California. All rights reserved.  
How to cite UCSF ChimeraX  

> isolde start

before.pdb title:  
Crystal structure of etub from clostridium kluyveri [more info...]  
  
Chain information for before.pdb #1  
---  
Chain | Description  
A | predicted microcompartment protein  
  
before.pdb title:  
Crystal structure of etub from clostridium kluyveri [more info...]  
  
Chain information for before.pdb  
---  
Chain | Description  
1.3/A | predicted microcompartment protein  
  
Done loading forcefield  

> volume selMaps style surface

> volume selMaps style surface




OpenGL version: 3.3.0 NVIDIA 410.93
OpenGL renderer: GeForce GTX 1070/PCIe/SSE2
OpenGL vendor: NVIDIA Corporation

[Tristan Croll]

After a little more playing around, I've been able to isolate this to volumecommand. If I open up a map in a fresh ChimeraX session, then in the shell:

v = session.models.list()[0]
from chimerax.map import volumecommand
volumecommand.volume(session, [v], transparency=0.05)

... then every time the map is re-contoured, the opacity will drop 5%. Every repeat call of volumecommand.volume() will _also_ reduce rather than set the opacity.

[Tristan Croll]

I can see the problem. VolumeSurface._set_appearance() calls Volume._modulated_surface_color(self.rgba) to set its final color from the surface's rgba and the volume's surface_brightness_factor and transparency_factor properties. But since VolumeSurface.rgba is now calculated directly from VolumeSurface.color the result is a vicious cycle.

[goddard@…]

Yep. Thanks for qfinding this.  I will fix this for 0.9 release.  UCSF strike today, and possible vacation tomorrow, so probably Monday.

[Tom Goddard]

Fixed.

I eliminated the volume surface transparency_factor and surface_brightness_factor settings. These values allowed modulating the surface color without actually changing the color. This added complexity that was almost never needed. Now that they are gone you would directly change the transparency or color of the surface.

From Python I suggest setting the surface transparency with

v.set_parameters(transparency = 0.5)

Using the volume command, the transparency and brightness options still work but they do so by changing the volume surface color, not by setting scale factors as was done formerly.