![[ChimeraX Issue Tracking System]](/trac/ChimeraX/chrome/site/ChimeraX-icon.svg){kind=icon}
#2491 closed defect (can't reproduce)
first model does not retain soft lighting when second model opened
| Reported by: | Elaine Meng | Owned by: | Tom Goddard |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Graphics | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Notify when closed: | Platform: | all | |
| Project: | ChimeraX |
Description
UCSF ChimeraX version: 0.91 (2019-10-10)
Something strange happens to lighting of first model when second model is opened. Tried in today’s build with large models:
open 5gmk
light soft
open 6s0z
… lighting of 5gmk (on the right) changes. Screenshot attached. I also observed similar changes to the first-opened model’s lighting when I opened them in the opposite order.
Reissuing "light soft" does not fix the problem.
Attachments (2)
Change History (12)
by , 6 years ago
| Attachment: | Screen Shot 2019-10-11 at 9.18.11 AM.png added |
|---|
comment:1 by , 6 years ago
comment:2 by , 6 years ago
It was completely reproducible about 5x in my first round of tests, but now when I try again, it only happens some of the time. It can be a very marked effect, like the first model is suddenly stripped of all shadowing. But yes, I can confirm that hiding/showing the model does fix the issue for me, as does saving and restoring the session, so it’s not as bad as I thought.
follow-up: 2 comment:3 by , 6 years ago
I put in a print statement when the shadows were recomputed and then the bug went away. Then I instead wrote an message to sys.stderr and still the bug went away. Then I took out by debugging, and the problem still went away. When I started I could reproduced the bug every time with your 3 commands, but now neither my devel build or the Oct 7 daily build I tested on will produce the bug. This surprisingly does look like a graphics driver bug.
comment:4 by , 6 years ago
Did you use Help / Report a Bug to report this bug? Because I didn't get your macOS version of graphics driver information in the bug report.
comment:5 by , 6 years ago
No, since I was trying to spare Eric from having to assign/categorize. This is my laptop known to have graphics driver problems, but at least this time you report the same behavior as me: initially very reproducible, less so after repeated testing. Mojave 10.14.6 MacBook Pro (Retina, 15-inch, Mid 2015) Graphics Intel Iris Pro 1536 MB Chipset Model: Intel Iris Pro Type: GPU Bus: Built-In VRAM (Dynamic, Max): 1536 MB Vendor: Intel Device ID: 0x0d26 Revision ID: 0x0008 Metal: Supported, feature set macOS GPUFamily1 v4 Displays: Color LCD: Display Type: Built-In Retina LCD Resolution: 2880 x 1800 Retina Framebuffer Depth: 24-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Rotation: Supported Automatically Adjust Brightness: No
follow-up: 5 comment:6 by , 6 years ago
The bug is that shadows are not rendered for the first model, as if the shadow map texture is not bound.
When the bug happens, resizing the window does not fix it.
Changing background color does not fix it.
Changing the color of model #1 does not fix it.
Command light full does not fix it, although the single cast shadow appears.
Command light simple, then light soft does not fix it.
Selecting atoms does not fix it.
Showing silhouette edges does not fix it.
Showing single shadow does not fix it.
It appears that parts of model #1 that are overlapping with model #2 actually do have ambient shadows. This suggests that the problem is really that the bounds or shadow map really only covered model #2. Or maybe it covered both models but model #1 was not rendered into the shadow map. This would explain why once it breaks, nothing fixes it unless the scene geometry changes causing a recomputation of the shadow map.
comment:7 by , 6 years ago
It appears the model #1 is getting shadows cast by #2 but it is not getting any shadowing cast from itself. I've only seen the bug when the second model is initially opened. Maybe something is special about that first rendering with model #2 around, for example, maybe it makes thumbnail snapshot of #2. Also when I put in debugging print statement, the ambient shadows were for some reason computed twice when the second model opened. I expected only to see it once.
comment:8 by , 6 years ago
| Resolution: | → can't reproduce |
|---|---|
| Status: | assigned → closed |
The multishadow transform matrices are different when model #1 shows no shadows and when it does show shadows. So it appears the bug is in computing the shadowmap. Probably related to the shadowmap being computed twice when the second model is opened.
The shadowmap was being computed twice due to an optimization problem where computing the bounds caused Drawing._displayed_positions = None to be changed to an array of one element with value true, which caused a shape changed event. I fixed this so this attribute does not get set when asking for a drawings displayed positions.
After the above change I could not get the shadow bug to reproduce -- tried 5 times. I don't understand what causes it.
Report the bug again if you see it again.
comment:9 by , 6 years ago
Alas, I get this on my desktop machine in the first use of today’s daily build (UCSF ChimeraX version: 0.91 (2019-10-10)), same three commands as in the initial report. open 5gmk light soft open 6s0z … lighting of 5gmk (on the right) changes. Now that I know there’s a workaround, however, it may be one of those things we just live with. iMac 27-inch late 2012 running macOS 10.13.6 Graphics NVIDIA GeForce GTX 675MX 1024 MB
follow-up: 9 comment:10 by , 6 years ago
Oops, I guess 10-10 build is not “the latest.” Sorry about that. Disregard...
Hiding and showing either model with model panel fixes the lighting. Somehow the computation of the shadows is wrong, probably it has the wrong bounding box when the second model is opened.