Blender 2.80 changing mode in one window is changing it everywhere #58252

Closed
opened 4 years ago by nezumi · 19 comments
nezumi commented 4 years ago

System Information
Operating system: Windows 7
Graphics card: GTX 1070

Blender Version
Broken:
2.80 Beta
Date: 2018-11-29 15:57, Hash: 26d5a3625e, Branch: blender2.8
Worked: Blender 2.79b and 2.79 daily builds

When having divided screen changing between edit and object mode in one widow is changing it also in other. Not only that but it adds overlay of edges/verts/faces which makes render mode only usable in object mode. I cant work in one window in edit mode and see rendering updated in other which was possible earlier. Being forced to see edit overlay on rendered view totally kills the purpose of rendered view...

Exact steps for others to reproduce the error
Create any object, divide screen in 2 vertically, on right window set view to rendered, turn off all overlays, go to left side and change mode to edit. It also changes to edit on window that is set to render mode.

**System Information** Operating system: Windows 7 Graphics card: GTX 1070 **Blender Version** Broken: 2.80 Beta Date: 2018-11-29 15:57, Hash: 26d5a3625ed, Branch: blender2.8 Worked: Blender 2.79b and 2.79 daily builds When having divided screen changing between edit and object mode in one widow is changing it also in other. Not only that but it adds overlay of edges/verts/faces which makes render mode only usable in object mode. I cant work in one window in edit mode and see rendering updated in other which was possible earlier. Being forced to see edit overlay on rendered view totally kills the purpose of rendered view... **Exact steps for others to reproduce the error** Create any object, divide screen in 2 vertically, on right window set view to rendered, turn off all overlays, go to left side and change mode to edit. It also changes to edit on window that is set to render mode.
nezumi commented 4 years ago
Poster

Added subscriber: @nezumi

Added subscriber: @nezumi
Collaborator

Added subscribers: @WilliamReynish, @fclem, @brecht, @lichtwerk

Added subscribers: @WilliamReynish, @fclem, @brecht, @lichtwerk
WilliamReynish was assigned by lichtwerk 4 years ago
Collaborator

Thx for the report,

regarding modes being global in the application: I think this has always been the case (also see the manual )?
It was the case in 2.79 as well (but you did not see verts/edges/faces, true)

Not sure if there are plans to decouple editmode drawing from the actual mode you are in [or if this could simply turned off -- which I can see the benefit of (in rendered view)]
Maybe @fclem, @WilliamReynish or @brecht could comment?

That being said, I am not sure if this can be called a bug (it is working as intended after all), but for the presented usecase, this could be improved upon, I agree...

Since this is more of a design question, I'll leave open for now and assign @WilliamReynish, OK?

Thx for the report, regarding `modes` being global in the application: I think this has always been the case (also see [the manual ](https://docs.blender.org/manual/en/dev/editors/3dview/modes.html))? It was the case in 2.79 as well (but you did not see verts/edges/faces, true) Not sure if there are plans to decouple editmode **drawing** from the actual mode you are in [or if this could simply turned off -- which I can see the benefit of (in rendered view)] Maybe @fclem, @WilliamReynish or @brecht could comment? That being said, I am not sure if this can be called a bug (it is working as intended after all), but for the presented usecase, this could be improved upon, I agree... Since this is more of a design question, I'll leave open for now and assign @WilliamReynish, OK?
WilliamReynish was unassigned by brecht 4 years ago
fclem was assigned by brecht 4 years ago
brecht commented 4 years ago
Owner

The issue is that disabling Overlays does not disable the edit mode drawing.

I'm not sure if that's intentional, but I think edit mode drawing should respect the overlay setting?

The issue is that disabling Overlays does not disable the edit mode drawing. I'm not sure if that's intentional, but I think edit mode drawing should respect the overlay setting?

@brecht: It was always this way, but I actually agree with you. When using Eevee or Cycles in Edit Mode, it can be useful to model without seeing the edit cage. Disabling Overlays could completely disable mesh display.

Especially if you have two viewports as the reporter above is doing.

@brecht: It was always this way, but I actually agree with you. When using Eevee or Cycles in Edit Mode, it can be useful to model without seeing the edit cage. Disabling Overlays could completely disable mesh display. Especially if you have two viewports as the reporter above is doing.
Collaborator

@brecht: +1

btw.: we could probably remove the Wireframe Overlay setting from the UI when in editmode (since its showing all edges anyways)?

@brecht: +1 btw.: we could probably remove the `Wireframe` Overlay setting from the UI when in editmode (since its showing all edges anyways)?
nezumi commented 4 years ago
Poster

It is extremely useful to model something on one side of a screen and watch it updated in real time (or close to real time in case of cycles) in other window. Loved it for many years in Blender and now with Eevee it would be even more efficient. Having edit mode drawing overlay the rendering is imo defeating the purpose of rendered view. Specially when it comes to more dense meshes - render is being practically covered with wireframe display and we cant see it. Making it an option would not only brought back functionality present in 2.79 but expanded on it. Thats why I reported it as a bug - because this option was available in previous versions. Thank you for considering it!

It is extremely useful to model something on one side of a screen and watch it updated in real time (or close to real time in case of cycles) in other window. Loved it for many years in Blender and now with Eevee it would be even more efficient. Having edit mode drawing overlay the rendering is imo defeating the purpose of rendered view. Specially when it comes to more dense meshes - render is being practically covered with wireframe display and we cant see it. Making it an option would not only brought back functionality present in 2.79 but expanded on it. Thats why I reported it as a bug - because this option was available in previous versions. Thank you for considering it!
fclem commented 4 years ago
Collaborator

@brecht @WilliamReynish it was this way in the begining. But I think we reverted it because in 2.79 you still display edit wires on top of solid/material view if only render is enabled. Basically the old behavior of hidding the wires in rendered mode was a limitation.

For me it make sense to hide all overlays even edit ones. But that can create confusion I think.

@brecht @WilliamReynish it was this way in the begining. But I think we reverted it because in 2.79 you still display edit wires on top of solid/material view if only render is enabled. Basically the old behavior of hidding the wires in rendered mode was a limitation. For me it make sense to hide all overlays even edit ones. But that can create confusion I think.
nezumi commented 4 years ago
Poster

You decide of course but just last thing. If we have an OPTION to hide it all or leave edit lines - then we can have a choice. Not giving an option clearly is limiting whats possible. If somebody will hide all overlays - can be confused as well before he realizes whats up. 2.8 suppose to be able to do whatever was possible in 2.79, right? ;) OK, I shut up now.

You decide of course but just last thing. If we have an OPTION to hide it all or leave edit lines - then we can have a choice. Not giving an option clearly is limiting whats possible. If somebody will hide all overlays - can be confused as well before he realizes whats up. 2.8 suppose to be able to do whatever was possible in 2.79, right? ;) OK, I shut up now.
brecht commented 4 years ago
Owner

@fclem, for who was hiding the wires a limitation or confusing? I can imagine some setup where you want to focus on modeling only, and enabled "Only Render" to hide all other distracting stuff? 2.8 has more overlay options like Extras for that, which might be a good replacement. But I'm just guessing here.

In any case 2.79 had the option of having a rendered viewport without any overlays, so that's important to keep supporting too.

@fclem, for who was hiding the wires a limitation or confusing? I can imagine some setup where you want to focus on modeling only, and enabled "Only Render" to hide all other distracting stuff? 2.8 has more overlay options like Extras for that, which might be a good replacement. But I'm just guessing here. In any case 2.79 had the option of having a rendered viewport without any overlays, so that's important to keep supporting too.

@fclem @brecht I think one of the reasons we always show the wires, is to make it clearer that you are in Edit Mode.

But, we could make that clear in other ways. Some apps do things like having different colors in the UI chrome when you are in different modes (XSI for example). That is something we could solve separately.

In any case, it should be possible to view the scene in Edit Mode without the edit cage display

@fclem @brecht I think one of the reasons we always show the wires, is to make it clearer that you are in Edit Mode. But, we could make that clear in other ways. Some apps do things like having different colors in the UI chrome when you are in different modes (XSI for example). That is something we could solve separately. In any case, it should be possible to view the scene in Edit Mode without the edit cage display

Added subscriber: @paleajed-3

Added subscriber: @paleajed-3

Dear all,

I have nothing to blame for not including this feature, which adds possible working habits for 3D modelers, than a strange rigidity in the developers eyes, which truly I do not understand... All arguments against seem unrealistic, as we should aim on maximum expressive possibilities, instead of limiting functionality which only favours the beginning modeler, who will be delighted to later on discover these extra possibilities arereally there. I for one work on a more and more professional level, ALWAYS using multiple (up to five different) viewports using the same well-explored method, with one of the viewports in solid edit mode (with edit cage) to do the actual editing on. This allows fast working updates, using a low subd level to allow even faster updates. Rendered view just clouds the editing... It is really necessary to have the other viewports unclouded by the edit cage. Without, no real esthetic or emotional impression of the art piece can be obtained. Be very aware that this should be one of the high aims of every 3D creation suite, creating maximum awareness of exactly what one is shaping, together with expressiveness of operation. As I see it, Blender often realizes the second, but with this limitation falls short of the first.

Dear all, I have nothing to blame for not including this feature, which *adds* possible working habits for 3D modelers, than a strange rigidity in the developers eyes, which truly I do not understand... All arguments against seem unrealistic, as we should aim on maximum expressive possibilities, instead of limiting functionality which only favours the beginning modeler, who will be delighted to later on discover these extra possibilities *are*really there. I for one work on a more and more professional level, ALWAYS using multiple (up to five different) viewports using the same well-explored method, with one of the viewports in solid edit mode (with edit cage) to do the actual editing on. This allows fast working updates, using a low subd level to allow even faster updates. Rendered view just clouds the editing... It *is* really *necessary* to have the other viewports unclouded by the edit cage. Without, no real esthetic or emotional impression of the art piece can be obtained. Be very aware that this should be one of the high aims of every 3D creation suite, creating maximum awareness of exactly what one is shaping, together with expressiveness of operation. As I see it, Blender often realizes the second, but with this limitation falls short of the first.
nezumi commented 4 years ago
Poster

I have now reported other bug that is kind of related: https://developer.blender.org/T60254

I really tried to use to this new idea of overlay of mesh on rendered view but this is simply killing the purpose of "rendered view". I dont see what is being rendered because mesh is covering it. And if I have an option to turn overlays OFF, but it is hiding overlays only partially (mesh is still visible) then it doesnt make sense... Not in rendered view.
I know it could be confusing if you turned off mesh in edit mode because it would look like object mode. Sure, leave it there. But rendered view should represent what will be rendered regardless of mode you are in. By far this is the most frustrating part of working with new Blender for me. I was using it all the time and it worked beautifully. So helpful! Please kindly take a second look at this limitation.

I have now reported other bug that is kind of related: https://developer.blender.org/T60254 I really tried to use to this new idea of overlay of mesh on rendered view but this is simply killing the purpose of "rendered view". I dont see what is being rendered because mesh is covering it. And if I have an option to turn overlays OFF, but it is hiding overlays only partially (mesh is still visible) then it doesnt make sense... Not in rendered view. I know it could be confusing if you turned off mesh in edit mode because it would look like object mode. Sure, leave it there. But rendered view should represent what will be rendered regardless of mode you are in. By far this is the most frustrating part of working with new Blender for me. I was using it all the time and it worked beautifully. So helpful! Please kindly take a second look at this limitation.

@fclem: Would you be ok with making it so the edit cage display gets hidden when overlays are turned off?

@fclem: Would you be ok with making it so the edit cage display gets hidden when overlays are turned off?
fclem commented 4 years ago
Collaborator

Personally I'm ok. But I would like to see a collective consensus on this matter before changing it.

Also would it be ok to have the same behavior for other edit mode for consistency? (armatures edit/pose/curves etc..)

Personally I'm ok. But I would like to see a collective consensus on this matter before changing it. Also would it be ok to have the same behavior for other edit mode for consistency? (armatures edit/pose/curves etc..)

Sure, those would also be invisible I suppose. @brecht : you also agree to make it so turning Overlays off hides the Edit cage?

Sure, those would also be invisible I suppose. @brecht : you also agree to make it so turning Overlays off hides the Edit cage?
brecht commented 4 years ago
Owner

Yes.

Yes.
brecht commented 4 years ago
Owner

Closed as duplicate of #62774

Closed as duplicate of #62774
brecht closed this issue 4 years ago
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/Collada
Interest/Compositing
Interest/Core
Interest/Cycles
Interest/Datablocks and Libraries
Interest/Dependency Graph
Interest/Development Management
Interest/Eevee
Interest/Eevee & Viewport
Interest/Freestyle
Interest/Geometry Nodes
Interest/Grease Pencil
Interest/Images & Movies
Interest/Import/Export
Interest/Line Art
Interest/Masking
Interest/Modeling
Interest/Modifiers
Interest/Overrides
Interest/Performance
Interest/Pipeline, Assets & I/O
Interest/Translations
Interest/Undo
Interest/USD
Interest/Video Sequencer
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/Asset Browser (Archived)
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Code Quest
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/GPU / Viewport
legacy project/GSoC
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Motion Tracking
legacy project/Nodes
legacy project/Nodes & Physics
legacy project/OpenGL Error
legacy project/Papercut
legacy project/Performance
legacy project/Physics
legacy project/Platforms, Builds, Tests & Devices
legacy project/Pose Library Basics
legacy project/Python API
legacy project/Render & Cycles
legacy project/Render Pipeline
legacy project/Retrospective
legacy project/Sculpt, Paint & Texture
legacy project/Text Editor
legacy project/Tracker Curfew
legacy project/Triaging
legacy project/User Interface
legacy project/UV Editing
legacy project/VFX & Video
legacy project/Virtual Reality
legacy project/Wintab High Frequency
Meta/Good First Issue
Meta/Papercut
migration/requires-manual-verification
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 & Devices
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 Information 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

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#58252
Loading…
There is no content yet.