Blender 2.78b Cycles compute device selection UI issue #50628

Closed
opened 2017-02-09 03:45:49 +01:00 by David Black · 19 comments

System Information
Linux Mint 18.1 Cinnamon 64bit
GTX 580m

Blender Version
2.78b (3c043732d3)

Short description of error
Cycles seemingly hidden CPU/GPU compute device UI selection

Exact steps for others to reproduce the error

  • Launch Blender 2.78b (without previously created config files)
  • Select Cycles render engine
  • Blender UI CPU/GPU compute device option remains selectable, even though greyed out, and won't actually change compute devices until User Preferences compute device is chosen, see screen capture
    Blender 2.78b issue.jpg

Is this the expected behaviour, or should it be the same as 2.78a where CPU/GPU compute device selection is hidden until a GPU compute device is selected within User Preferences? Current 2.78b implementation could be confusing for newer users.

Alternatively, until a GPU compute device is selected within User Preferences, it may help if only CPU is available as an option within Blenders UI?


User Preferences observation, selected GPU devices appear same UI grey colour as above mentioned (seemingly hidden) Blender UI CPU/GPU compute device selection.
Would check boxes be clearer for quick visual reference of selected GPU devices?

Thank you all developers for your hard work, very much appreciated!

Edit: Second attempt to help clarify

**System Information** Linux Mint 18.1 Cinnamon 64bit GTX 580m **Blender Version** 2.78b (3c043732d3f) **Short description of error** Cycles seemingly hidden CPU/GPU compute device UI selection **Exact steps for others to reproduce the error** - Launch Blender 2.78b (without previously created config files) - Select Cycles render engine - Blender UI CPU/GPU compute device option remains selectable, even though greyed out, and won't actually change compute devices until User Preferences compute device is chosen, see screen capture ![Blender 2.78b issue.jpg](https://archive.blender.org/developer/F463433/Blender_2.78b_issue.jpg) Is this the expected behaviour, or should it be the same as 2.78a where CPU/GPU compute device selection is hidden until a GPU compute device is selected within User Preferences? Current 2.78b implementation could be confusing for newer users. Alternatively, until a GPU compute device is selected within User Preferences, it may help if only CPU is available as an option within Blenders UI? --- User Preferences observation, selected GPU devices appear same UI grey colour as above mentioned (seemingly hidden) Blender UI CPU/GPU compute device selection. Would check boxes be clearer for quick visual reference of selected GPU devices? Thank you all developers for your hard work, very much appreciated! Edit: Second attempt to help clarify
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @david_black

Added subscriber: @david_black

Added subscriber: @Alexandermitchell

Added subscriber: @Alexandermitchell

This comment was removed by @Alexandermitchell

*This comment was removed by @Alexandermitchell*

Added subscriber: @brecht

Added subscriber: @brecht

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Brecht Van Lommel self-assigned this 2017-02-09 23:30:09 +01:00

It's by design, in the Blender UI such greyed out / low contrast options always mean that the option has no effect, and we still generally allow users to change them. I think this is consistent.

It was done so that user can look at the tooltip and discover that they have to set up their GPU in the user preferences, which is a common confusion among first time users.

It's by design, in the Blender UI such greyed out / low contrast options always mean that the option has no effect, and we still generally allow users to change them. I think this is consistent. It was done so that user can look at the tooltip and discover that they have to set up their GPU in the user preferences, which is a common confusion among first time users.

Added subscriber: @sindra1961

Added subscriber: @sindra1961

I think that Hidden condition of UI is not only written.
It works properly in 2.78a.

2.78a(ui.py)

       device_type = context.user_preferences.system.compute_device_type
        if device_type in {'CUDA', 'OPENCL', 'NETWORK'}:
            layout.prop(cscene, "device")
I think that Hidden condition of UI is not only written. It works properly in 2.78a. 2.78a(ui.py) ``` device_type = context.user_preferences.system.compute_device_type if device_type in {'CUDA', 'OPENCL', 'NETWORK'}: layout.prop(cscene, "device") ```

I intentionally switched it from hiding the button to showing greyed out, it's not an issue in the code, though some might disagree with the design choice.

I intentionally switched it from hiding the button to showing greyed out, it's not an issue in the code, though some might disagree with the design choice.
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

TBH I find the behavior of .active utterly confusing, I much prefer using .enabled. A button should either be disabled or enabled, not some state in-between.

TBH I find the behavior of `.active` utterly confusing, I much prefer using `.enabled`. A button should either be disabled or enabled, not some state in-between.

If you changed it like that intentionally, I think that there is not the problem.
However, I can choose it as the gray out.
If it is selectable, do you not think that a chosen thing is used?

If you changed it like that intentionally, I think that there is not the problem. However, I can choose it as the gray out. If it is selectable, do you not think that a chosen thing is used?

It's been a Blender UI behavior for a long time, when we did the initial button layout for 2.5 the convention was to only use .enabled if strictly necessary (when you could end up in an invalid state or so). I've always seen .active as more convenient than confusing, but I can see how it could seem strange.

The advantage is that you can change options in any order, and edit options that might matter but have no effect right now (due to animation, rigging, ..). It could be interpreted as trying to do the non-modal, non-blocking thing as much as possible. In this case for example it might be useful to enable GPU compute to send it to another computer for rendering, even if the computer you are working on can only do CPU rendering.

Not that I care particularly strongly about this, if the UI teams like to change it that's fine with me, just explaining the reasoning.

It's been a Blender UI behavior for a long time, when we did the initial button layout for 2.5 the convention was to only use `.enabled` if strictly necessary (when you could end up in an invalid state or so). I've always seen `.active` as more convenient than confusing, but I can see how it could seem strange. The advantage is that you can change options in any order, and edit options that might matter but have no effect right now (due to animation, rigging, ..). It could be interpreted as trying to do the non-modal, non-blocking thing as much as possible. In this case for example it might be useful to enable GPU compute to send it to another computer for rendering, even if the computer you are working on can only do CPU rendering. Not that I care particularly strongly about this, if the UI teams like to change it that's fine with me, just explaining the reasoning.
Author

Thank you all for taking time to reply, and explain usage scenarios.

Since compute device selection now uses .active by default, would it help remove possible confusion for users if CPU always appears .enabled (since it always is), and GPU appears .active until enabled in user perseverances? See screen capture mockup.
Render panel idea.png

@brecht, Considering render farm usage, and GPU option appearing .active due to lack of local GPU compute device, it may help if the tool-tip is updated to reflect this usage scenario?

Tool-tip suggestions, also tried more condensed versions.

Current
Use GPU compute device for rendering, configured in the system tab in the user preferences

Proposed
Use GPU compute device for rendering, configured in the system tab of user preferences

Use GPU compute device for rendering, configured in user preferences (system tab)

Use GPGPU for rendering, configured in user preferences (system tab)

Proposed, helping explain various usage scenarios

Set also for GPU enabled render farms, even if local GPU compute device is unavailable```

or

```Use GPU compute device for rendering, configured in user preferences (system tab).
Set also if using a GPU enabled render farm, even if local GPU compute device is unavailable```
Thank you all for taking time to reply, and explain usage scenarios. Since compute device selection now uses `.active` by default, would it help remove possible confusion for users if CPU always appears `.enabled` (since it always is), and GPU appears `.active` until enabled in user perseverances? See screen capture mockup. ![Render panel idea.png](https://archive.blender.org/developer/F482352/Render_panel_idea.png) @brecht, Considering render farm usage, and GPU option appearing `.active` due to lack of local GPU compute device, it may help if the tool-tip is updated to reflect this usage scenario? Tool-tip suggestions, also tried more condensed versions. **Current** `Use GPU compute device for rendering, configured in the system tab in the user preferences` **Proposed** `Use GPU compute device for rendering, configured in the system tab of user preferences` `Use GPU compute device for rendering, configured in user preferences (system tab)` `Use GPGPU for rendering, configured in user preferences (system tab)` **Proposed, helping explain various usage scenarios** ```Use GPU compute device for rendering, configured in user preferences (system tab). Set also for GPU enabled render farms, even if local GPU compute device is unavailable``` or ```Use GPU compute device for rendering, configured in user preferences (system tab). Set also if using a GPU enabled render farm, even if local GPU compute device is unavailable```

This issue was referenced by blender/cycles@37f1ca1eaf

This issue was referenced by blender/cycles@37f1ca1eafc2919cceae8f1e449f8376de98d255

This issue was referenced by 68ca973f7f

This issue was referenced by 68ca973f7f81e551889532d0c1b76485d9f40245

I've now changed the greying out behavior to what you proposed, I agree that's more clear. I don't think the extra detail in the tooltip is needed, it's too specific an example.

I've now changed the greying out behavior to what you proposed, I agree that's more clear. I don't think the extra detail in the tooltip is needed, it's too specific an example.

Changed status from 'Archived' to: 'Resolved'

Changed status from 'Archived' to: 'Resolved'
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#50628
No description provided.