Gumball + selection causing restart of cycles (and others)

Rendering
1

As per subject, with gumball activated, I get cycles restarting when selecting certain objects:

I also see the same behavior when I use my own viewport renderer (not loaded in the above video) – my realtime viewport is torn down and reconstructed. However, this behavior is not universal, so you can try to reproduce it using this file:

gumball-vs-raytraced.3dm (315.0 KB)

The behavior should survive save small, with no textures or plugin data, but it does not survive a geometry-only save. That apparently “fixes” the file.

Checked on Windows, Rhino version 7.4.21078.1001, 2021-03-19

2

Hi JD!

I’m not seeing that here on a daily 7.6. Could you check if the public 7.5 release candidate fixes this?
-wim

3

Hi Wim, sure thing – I just checked with 7.5.21074.17001, 2021-03-15 and the behavior appears to be unchanged.

4

Hi JD -

Thanks for testing that!
I’ve put it on the list as RH-63421 to be taken a closer look at.
-wim

1 Like
5

For what it’s worth, I remembered I also have a realtime display mode in a test plugin, so checked, and that one behaves the same. And secondly, I have now checked and confirm that the same also occurs on mac (version 7.4.21078.01002, 2021-03-19).

Added some logging to that test plugin, and here is what it yields:

Display mode set to "TestRealtimeDisplayMode".
 TestRealtimeDisplayMode() (instance 0)
 TestChangeQueue() (instance 0)
 NotifyBeginUpdates
 NotifyEndUpdates
 ApplyViewChange: name: a
 ApplyEnvironmentChanges: usage: Background
 ApplyEnvironmentChanges: usage: Skylighting
 ApplyEnvironmentChanges: usage: ReflectionAndRefraction
 ApplySkylightChanges: enabled: True
 ApplySunChanges: id: 62ee2cf6-b855-4549-a277-e2bbf609f328, name: sun
 ApplyMeshChanges: delete 0, add 7
 ApplyMeshInstanceChanges: delete 0, add/change 7
 ApplyGroundPlaneChanges: mat id: 3858557068, alt: 1.06586011914637
1 open surface added to selection.
1 closed surface added to selection.
1 open surface added to selection.
1 closed surface added to selection.
 TestChangeQueue.Dispose(true) (instance 0)
1 closed surface added to selection.
 TestRealtimeDisplayMode() (instance 1)
 TestChangeQueue() (instance 1)
 NotifyBeginUpdates
 NotifyEndUpdates
 ApplyViewChange: name: a
 ApplyEnvironmentChanges: usage: Background
 ApplyEnvironmentChanges: usage: Skylighting
 ApplyEnvironmentChanges: usage: ReflectionAndRefraction
 ApplySkylightChanges: enabled: True
 ApplySunChanges: id: 62ee2cf6-b855-4549-a277-e2bbf609f328, name: sun
 ApplyMeshChanges: delete 0, add 7
 ApplyMeshInstanceChanges: delete 0, add/change 7
 ApplyGroundPlaneChanges: mat id: 3858557068, alt: 1.06586011914637
 TestChangeQueue.Dispose(true) (instance 1)
1 closed surface added to selection.
 ~TestRealtimeDisplayMode() (instance 0)
 ~TestChangeQueue() (instance 0)
 TestRealtimeDisplayMode() (instance 2)
 TestChangeQueue() (instance 2)
 NotifyBeginUpdates
 NotifyEndUpdates
 ApplyViewChange: name: a
 ApplyEnvironmentChanges: usage: Background
 ApplyEnvironmentChanges: usage: Skylighting
 ApplyEnvironmentChanges: usage: ReflectionAndRefraction
 ApplySkylightChanges: enabled: True
 ApplySunChanges: id: 62ee2cf6-b855-4549-a277-e2bbf609f328, name: sun
 ApplyMeshChanges: delete 0, add 7
 ApplyMeshInstanceChanges: delete 0, add/change 7
 ApplyGroundPlaneChanges: mat id: 3858557068, alt: 1.06586011914637
 TestChangeQueue.Dispose(true) (instance 2)
1 closed surface added to selection.
 ~TestRealtimeDisplayMode() (instance 1)
 ~TestChangeQueue() (instance 1)
 TestRealtimeDisplayMode() (instance 3)
 TestChangeQueue() (instance 3)
 NotifyBeginUpdates
 NotifyEndUpdates
 ApplyViewChange: name: a
 ApplyEnvironmentChanges: usage: Background
 ApplyEnvironmentChanges: usage: Skylighting
 ApplyEnvironmentChanges: usage: ReflectionAndRefraction
 ApplySkylightChanges: enabled: True
 ApplySunChanges: id: 62ee2cf6-b855-4549-a277-e2bbf609f328, name: sun
 ApplyMeshChanges: delete 0, add 7
 ApplyMeshInstanceChanges: delete 0, add/change 7
 ApplyGroundPlaneChanges: mat id: 3858557068, alt: 1.06586011914637

The interesting bits to note are these:

 TestChangeQueue.Dispose(true) (instance 1)
1 closed surface added to selection.

What occurs there is that we see my change queue being destroyed before Rhino prints the message about the object being selected.

If I had to guess, some detail in how gumball stores data has changed subtly, causing the change queue mechanism to generate a different hash for something or other, and therefore believe that the scene needs updating, and that this is why I see this behavior in common between three different realtime display modes that all make use of the change queue.

6

@jdhill I can’t repeat this here - sorry. Could you try disabling every plug-in that doesn’t ship with Rhino and see if you can still repeat it?

7

I have a very similar issue, running Version 7 SR5 (7.5.21082.11001, 2021-03-23).
Clicking the bottom object restarts cycles and does weird glitches to the viewport:

image
image937×590 62 KB

Here is the file as an example:denoisertest.3dm (506.0 KB)

8

Hi Andy, indeed that is how I have tested it, on both windows & mac. I tried to use safe mode but did not find a way to get cycles running in a viewport after starting in safe mode.

Checking RD3’s file I see similar behavior, but not exactly similar, since with this file I am able to observe cycles restarting regardless whether gumball is enabled.

9

However, in a further test with RD3’s file, I have saved it small, with geometry only, and no textures or plugin data, and the resulting file does now show similar gumball-dependent behavior, with a cycles restart resulting specifically from selecting the middle object, after having the top object selected, when gumball is enabled. Tested this and see the same behavior on windows & mac.

That is still slightly different than my case, where the file is “fixed” by saving with geometry only (and apparently any combination of other save-as options).

10

@jdhill and @RD3 - we were able to reproduce that issue on 7.5 and tested more on 7.6. This appears to have been fixed in 7.6. If all goes as planned, 7.5 will be released next week and the first public 7.6 release candidate will then also become available. Let me know if you need it earlier.
-wim

2 Likes
11

Thanks a lot! (and no early copy needed for me)

12

I am still seeing this, currently on 7.7.21160.5001, 2021-06-09, now without gumball involved, and after having tried to clean the file by saving with geometry only. Zero non-standard plugins are loaded, and I renamed the settings & Plug-ins directories under AppData/Roaming/McNeel/Rhinoceros/7.0 to try to eliminate the possibility that some setting I have enabled affects it.

The behavior looks the same whether rendering with cpu or gpu, and I see it quite commonly, whenever I start trying to do any non-trivial work in rhino (i.e. don’t usually notice it when running simple tests while coding).

selection-cycles-restart.3dm (1.6 MB)

13

Still seeing this on windows, with Rhino 7.15.22039.13001, now on two different machines, with one tested as I normally run, and one again tested after having entirely deleted Rhino’s AppData/Roaming/McNeel/Rhinoceros/7.0 directory, to rule out anything with settings or other plugins:

Checked on macos (7.15.22039.13002 on m1) and it appears not to happen there, at least with this example file (selections-cycles-restart.3dm from the previous post). There, the “Choose Objects” window pops up as expected, where on windows it (named “Selection Menu” on windows) is usually but not always prevented from popping up, when the selection triggers this restart behavior.

And as initially mentioned, this is not a cycles issue, I only use cycles to provide a minimal repro – the same issue also occurs with other realtime display mode renderers.

When this occurs with a file, it makes rhino nearly unusable, since a non-trivial model can take some seconds to be re-transferred to the renderer, so you find yourself being hesitant to even select anything in the viewport, and/or you begin to develop some intuition about what you can select without triggering this behavior.

14

This is still occurring on 7.19.22165.13001, 2022-06-14, using the same file provided two posts up:

Not too easy to see what’s going on there in raytraced, besides the flickering, so here it is with bella, which shows what it has exported, and how long it took, every time it is asked to do so:

Was prompted to bump this thread again, since I was looking at a customer’s screen recording today and saw the same behavior on his machine.

15

nearly two years later now, and still happening on 7.27.23032.13001

do you have any idea how disruptive this is, when working with a large model that takes a few seconds or more to transfer geometry to the renderer?

by now I basically just avoid ever making any selection at all in a rendered viewport

I can consistently reproduce this exactly as shown in the videos, using the same “selection-cycles-restart.3dm” file attached to the july 2021 post above, with non-standard plugins disabled, and even the settings folder deleted, on two completely dissimilar machines, one a newer desktop, the other an older laptop

systeminfo.txt (2.0 KB)
systeminfo2.txt (2.2 KB)

16

Hi JD -

I see this here as well on Rhino 7 but am unable to reproduce this on the current Rhino 8 WIP. Are you also seeing this there?
-wim

17

hey Wim, no I do not see it with this file on v8, nor on the current v7 macos (have not checked on v8 macos)

18

I don’t see this in v7 macos either, but there is another interesting behavior.

Right after you have opened the file and Raytraced is tracing its rays select one object, then click through the different icons in the properties panel. While Raytraced is still running clicking through these will have Raytraced restart. Can you confirm?

19

yes I confirm that here, but it is something I have always seen – props pages can be tricky to get initialized without triggering changes – and it has been more of an annoyance than a problem, since restarting the renderer is one thing, but having it re-export everything from scratch is another