2.8: Code-Quest (Topics we plan to cover) #54387

New Issue

Campbell Barton · 2018-03-21T11:39:17+01:00

Campbell Barton commented

2018-03-21 11:39:17 +01:00

This is a rough proposed outline of tasks to work on for the code quest (based on discussion between @ideasman42 & @Sergey).

Note: comprehensive design docs should be linked from here (not inlined).
Note: this is a work in progress document, if you think something is missing, please reply saying so.

Alembic

When reading, write to scene data rather than DNA data.
Have a collection connected to an Alembic file.
Reading/writing custom properties (#50725).
Read particles/curves in a way compatible with a new particle/hair system?

Asset Manager?

Make it part of code-quest?

Needs discussion w/ Bastien

Suggest to finalize design w/ UI guys, can focus on some of the technical issues later.

Depsgraph

Building depsgraph from an arbitrary ID block.
This can be used for efficient calculation of motion paths. Viewport motionblur
** Sequencer prefetch rendering frames (in threads).
Performance (investigate)
COW
Get input from Sergey for detailed planning.

Drawing API's

Resolved fixed buffer size for immediate mode (IMM_BUFFER_SIZE, also see: #51921).
GPU - cleanup naming, remove deprecaed API's.
Move GWN to GPU? (Don't use C++, we can use BLI_threads) Use blender's code style.
Wayland (ok after code-quest!)

Drawing Code Basics

Workbench Engine
Add back some missing options? - xray, wireframe.
OpenGL selection has remaining bugs

Maybe small, need investigaion.

Sculpting Bug #53837
Performance (investigate)
Clipped output (alt-b)

Grease Pencil

Basic working functionality
Review greasepencil-object branch, merge in bite sized chunks.

Interface

UI design and larger changes (proposed by @WilliamReynish) See: #54387#489773

This has large scope, so we'll need to plan how much is fesable for the code-quest.
COW display evaluated data, edit original.

Layers

UI (design)
Check Performance

For larger scenes current layer system likely has poor performance
given the way linked lists are used.
It would be good to measure what the difference w/ 2.7x is,
if this is something to address, set as TODO or if we can leave as-is.

Moving between layers
Best get input from Dalai

More work is needed to finish this off, not sure how much.

How do set-scenes work w/ layer visibility?

Manipulators

UI Design

Reevaluate existing design. check if any changes are needed.

More work to do, polish, usability, continued development.
Confirm current API design is OK to go ahead with (since add-ons will use it, better not break it after 2.8 release).

We could re-evaluate a handful of minor things.

Use to replace notifiers over the rest of Blender.

Modifiers

Remove derived-mesh

Operators

Port to COW
Undo system restructure and make linear (optional)
Multi-object edit-mode (optional)

Overrides

UI Design
See: Bastien, Dalai for UI, more development, testing.

Depends on COW.

Access from Python (for later).

Physics & Particles

Bring back 2.7x level of support

Make the modules a blackbox, keep existing files working-ish.

Python API

COW support

At least exporters should export evaluated data.

Various minor changes blender/blender-addons#47811 (best handle after the code-quest).
Update all add-ons (again, after code-quest)

Refactor

Split some files to help w/ merge conflicts

Check files over ~3000 LOC, also use common sense!

CMake: remove BLENDER_SORTED_LIBS see: P522

This is near impossible to reason about and always confuses anyone adding new modules.

Sequencer

Scene strips w/ COW, layers.. drawing engines?
Make breaking changes

Using pixel units maskes output at different sizes confusing.
while we don't have time for a large project, we could improve things we know are bad-by-design.

Transform especially has very strange behavior (see: #35028 #7862 #53664 #6829 #54273). Remove grading in linear space option.

FUN: Camera navigation in sequencer (optional).
Prefetch frames (optional, nice to have, fits nice w/ COW)

Tools

101 Project, design is needed.

Versioning

Tests loading complex production files.

Ensure basics are supported & no crashes.

Check if we can make 2.8 files load in 2.7x

On basic level, all layers visible.

Workspace

Topbar design (keep redo panel where it is)
Fix crashes in scene linking.
Finalize object mode design & stabilize.
Finalize bare minimum for release, possible extras.

Remove Features

Blender Internal!
Texture Nodes (redo or remove - currently)
Armature Sketch
Mesh Legacy Format (pre BMesh).
Remove tessface
Cycles: use looptri (detect quads if needed). Remove from RNA: Python IO needs updating
Particles: We need operator to re-distribute to tris (can't do in readfile.c because we need evaluated mesh). BVH utils uses still.
Remove non-triple buffer drawing.
Screen Capture
Frame Server
AVI-RAW/JPEG (remove our own implementations, use FFMPEG).
BGE & Player

Replace with interaction mode (see T54389)

After Code-Quest Topics

Nodes

Move cycles away from hard-coded C definitions.

This is a rough proposed outline of tasks to work on for the code quest (based on discussion between @ideasman42 & @Sergey). * Note: comprehensive design docs should be linked from here *(not inlined)*. * Note: this is a work in progress document, if you think something is missing, please reply saying so. ## Alembic * When reading, write to scene data rather than DNA data. * Have a collection connected to an Alembic file. * Reading/writing custom properties (#50725). * Read particles/curves in a way compatible with a new particle/hair system? ## Asset Manager? Make it part of code-quest? * Needs discussion w/ Bastien ``` Suggest to finalize design w/ UI guys, can focus on some of the technical issues later. ``` ## Depsgraph * Building depsgraph from an arbitrary ID block. **This can be used for efficient calculation of motion paths.** Viewport motionblur ** Sequencer prefetch rendering frames (in threads). * Performance (investigate) * COW * Get input from Sergey for detailed planning. ## Drawing API's * Resolved fixed buffer size for immediate mode (`IMM_BUFFER_SIZE`, also see: #51921). * GPU - cleanup naming, remove deprecaed API's. * Move GWN to GPU? (Don't use C++, we can use BLI_threads) Use blender's code style. * Wayland (ok after code-quest!) ## Drawing Code Basics * Workbench Engine * Add back some missing options? - xray, wireframe. * OpenGL selection has remaining bugs ``` Maybe small, need investigaion. ``` * Sculpting Bug #53837 * Performance (investigate) * Clipped output (alt-b) ## Grease Pencil * Basic working functionality * Review `greasepencil-object` branch, merge in bite sized chunks. ## Interface * UI design and larger changes (proposed by @WilliamReynish) See: #54387#489773 *This has large scope, so we'll need to plan how much is fesable for the code-quest.* * COW display evaluated data, edit original. ## Layers * UI (design) * Check Performance ``` For larger scenes current layer system likely has poor performance given the way linked lists are used. It would be good to measure what the difference w/ 2.7x is, if this is something to address, set as TODO or if we can leave as-is. ``` * Moving between layers * Best get input from Dalai ``` More work is needed to finish this off, not sure how much. ``` * How do set-scenes work w/ layer visibility? ## Manipulators * UI Design ``` Reevaluate existing design. check if any changes are needed. ``` * More work to do, polish, usability, continued development. * Confirm current API design is OK to go ahead with (since add-ons will use it, better not break it after 2.8 release). ``` We could re-evaluate a handful of minor things. ``` * Use to replace notifiers over the rest of Blender. ## Modifiers * Remove derived-mesh ## Operators * Port to COW * Undo system restructure and make linear (optional) * Multi-object edit-mode (optional) ## Overrides * UI Design * See: Bastien, Dalai for UI, more development, testing. ``` Depends on COW. ``` * Access from Python (for later). ## Physics & Particles * Bring back 2.7x level of support ``` Make the modules a blackbox, keep existing files working-ish. ``` ## Python API * COW support ``` At least exporters should export evaluated data. ``` * Various minor changes blender/blender-addons#47811 (best handle after the code-quest). * Update all add-ons (again, after code-quest) ## Refactor * Split some files to help w/ merge conflicts ``` Check files over ~3000 LOC, also use common sense! ``` * CMake: remove `BLENDER_SORTED_LIBS` see: [P522](https://archive.blender.org/developer/P522.txt) ``` This is near impossible to reason about and always confuses anyone adding new modules. ``` ## Sequencer * Scene strips w/ COW, layers.. drawing engines? * Make breaking changes ``` Using pixel units maskes output at different sizes confusing. while we don't have time for a large project, we could improve things we know are bad-by-design. ``` **Transform especially has very strange behavior (see: #35028 #7862 #53664 #6829 #54273).** Remove grading in linear space option. * FUN: Camera navigation in sequencer (optional). * Prefetch frames (optional, nice to have, fits nice w/ COW) ## Tools * 101 Project, design is needed. ## Versioning * Tests loading complex production files. ``` Ensure basics are supported & no crashes. ``` * Check if we can make 2.8 files load in 2.7x ``` On basic level, all layers visible. ``` ## Workspace * Topbar design (keep redo panel where it is) * Fix crashes in scene linking. * Finalize object mode design & stabilize. * Finalize bare minimum for release, possible extras. ## Remove Features * Blender Internal! * Texture Nodes (redo or remove - currently) * Armature Sketch * Mesh Legacy Format (pre BMesh). * Remove tessface **Cycles: use looptri (detect quads if needed).** Remove from RNA: Python IO needs updating **Particles: We need operator to re-distribute to tris (can't do in `readfile.c` because we need evaluated mesh).** BVH utils uses still. * Remove non-triple buffer drawing. * Screen Capture * Frame Server * AVI-RAW/JPEG (remove our own implementations, use FFMPEG). * BGE & Player ``` Replace with interaction mode (see T54389) ``` # After Code-Quest Topics ## Nodes * Move cycles away from hard-coded C definitions.

Campbell Barton commented

2018-03-21 11:39:17 +01:00

Added subscribers: @ideasman42, @brecht, @fclem, @Sergey, @mont29, @dfelinto, @JoshuaLeung, @Jeroen-Bakker, @dr.sybren, @pablovazquez, @WilliamReynish

Duarte Farrajota Ramos commented

2018-03-21 12:51:47 +01:00

Added subscriber: @DuarteRamos

Jorge Bernal commented

2018-03-21 13:30:39 +01:00

Added subscriber: @JorgeBernalMartinez

Antonio Vazquez commented

2018-03-21 15:54:06 +01:00

Added subscriber: @antoniov

Antonio Vazquez commented

2018-03-21 15:54:06 +01:00

@ideasman42 Nothing about grease pencil or this is before Code quest?

Campbell Barton self-assigned this 2018-03-21 16:01:23 +01:00

William Reynish commented

2018-03-21 23:03:15 +01:00

Nice one Cambo, but is this list set in stone? I would say the tool settings/top bar/active tools system should be a very high priority, and would be good to do while everyone is together. This also fits into the manipulators design topic - can't really see how we can do one without the other? Same goes for the 101 project, which requires a tools system that works.
I put together a design for it that we could look at too, and I'm sure we can do a great job.

Here's the relevant 2.8 document, mainly outlining the tools design issues: {F2478607}

We can also take a closer look at these issues when we arrive. Here's a brief list of what I think we could add to the topic list:

tool settings in top bar
Workspace tabs along the top
clean up tool settings flags so they are actually useable
Remove header-hotkey weirdo tool settings
fully implement active tools
integrate the manipulators with active tools
make tools consistent and beautiful to use
tweak default Blender settings to be more sane
re-implement View Modes, but more consistently compared to 2.79. Everything in the same menu.
Update default theme to be cleaner, calmer and more modern
Add consistent icons to all tools for all our modes
Add ridiculous amounts of UI polish, to make it insanely great

Looking forward to doing lots of great work in A'dam! :)

Cheers

Nice one Cambo, but is this list set in stone? I would say the tool settings/top bar/active tools system should be a very high priority, and would be good to do while everyone is together. This also fits into the manipulators design topic - can't really see how we can do one without the other? Same goes for the 101 project, which requires a tools system that works. I put together a design for it that we could look at too, and I'm sure we can do a great job. Here's the relevant 2.8 document, mainly outlining the tools design issues: {F2478607} We can also take a closer look at these issues when we arrive. Here's a brief list of what I think we could add to the topic list: - tool settings in top bar - Workspace tabs along the top - clean up tool settings flags so they are actually useable - Remove header-hotkey weirdo tool settings - fully implement active tools - integrate the manipulators with active tools - make tools consistent and beautiful to use - tweak default Blender settings to be more sane - re-implement View Modes, but more consistently compared to 2.79. Everything in the same menu. - Update default theme to be cleaner, calmer and more modern - Add consistent icons to all tools for all our modes - Add ridiculous amounts of UI polish, to make it insanely great Looking forward to doing lots of great work in A'dam! :) Cheers

Leandro Cavalheiro commented

2018-03-21 23:47:48 +01:00

Added subscriber: @leandro_cavalheiro

Lucas Boutrot commented

2018-03-22 00:26:29 +01:00

Added subscriber: @thornydre

Nahuel Belich commented

2018-03-22 02:29:23 +01:00

Added subscriber: @NahuelBelich

Leroy commented

2018-03-22 03:05:15 +01:00

Added subscriber: @Leroy-Xie

Leroy commented

2018-03-22 03:05:15 +01:00

I'm not sure I can reply in this area, I saw lots ui idea in 2.8, it's make me crazy, even hate and angry, the Blender from amazing magical to normal and ordinary, lots style from photoshop, max, maya and modo, put them together and called it 101, lost itself for new users, WHY not make more tools tip for first open in blender, as far as I now, in photoshop 2018, unreal and 3d coat, they all have good tools tip to lets users to see it clear, for example, switch editor have hotkeys in blender, but less people know that, even lots old users. Actually not myself don't like the new ui design, include my friends, lots are old users, they are uses autodesk at before, and now blender start like autodesk in ui design. for photoshop, it's really not good in ux, tools bar in left, layer and property in left, move mouse left to right, right to left, the tools setting topbar more inconvenient, so in new photoshop version, more and more move in property panel, I have used photoshop in five years, almost less in topbar setting, yeah must be move your eye look for from left to right, the option panel is much more better. I really like blender, because it provided the different idea and operation than others, clear and light, very efficient in work. but now, more like autodesk with obese and awkward.

Campbell Barton commented

2018-03-22 07:05:46 +01:00

@antoniov: added grease pencil topic.

@WilliamReynish: No this is not set in stone. Thanks for the UI planning info, I was aware we had bigger plans for the UI, (now noted under Interface).

More detailed planning can be done when we meet. I'm mostly interested to get a big picture overview on things we'll plan to work on for the code-quest.

@Leroy-Xie: Blender 101 is something we try and not a new direction for all future development, further this design task is not a place to discuss pros and cons of each UI change.

@antoniov: added grease pencil topic. @WilliamReynish: No this is not set in stone. Thanks for the UI planning info, I was aware we had bigger plans for the UI, (now noted under *Interface*). More detailed planning can be done when we meet. I'm mostly interested to get a big picture overview on things we'll plan to work on for the code-quest. @Leroy-Xie: Blender 101 is something we try and not a new direction for all future development, further this design task is not a place to discuss pros and cons of each UI change.

Vaughan Ling commented

2018-03-22 09:43:07 +01:00

Added subscriber: @heavypoly

ronan ducluzeau commented

2018-03-22 16:19:22 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2018-03-22 16:19:22 +01:00

@WilliamReynish , some points of your proposal are ignoring some aspects of toolsettings or manipulators.
I mostly agree with proposal but I may disagree with some examples and remarks mentionned to justify what is in proposal.
And some parts of proposal are outdated, not taking into account what has been done in 2.8 branches (Grease Pencil Object,EEVEE,workspace/collections...).
I had too many remarks to formulate. So, here, a separate file that groups them.
2.8_Design_Proposal_remarks.txt

Do you have time to clean it and make it a little bit more up-to-date before codequest beginning ?

@WilliamReynish , some points of your proposal are ignoring some aspects of toolsettings or manipulators. I mostly agree with proposal but I may disagree with some examples and remarks mentionned to justify what is in proposal. And some parts of proposal are outdated, not taking into account what has been done in 2.8 branches (Grease Pencil Object,EEVEE,workspace/collections...). I had too many remarks to formulate. So, here, a separate file that groups them. [2.8_Design_Proposal_remarks.txt](https://archive.blender.org/developer/F2482385/2.8_Design_Proposal_remarks.txt) Do you have time to clean it and make it a little bit more up-to-date before codequest beginning ?

Antonio Vazquez commented

2018-03-22 19:43:09 +01:00

Added subscribers: @mendio, @pepe-school-land

Antonio Vazquez commented

2018-03-22 19:43:09 +01:00

@WilliamReynish Most of your comments about grease pencil have been solved in greasepencil branch and now the tool is working as any other tool in Blender with modes, brushes, etc. We still have pending the use of grease pencil in 2D and the use as annotation tool.

Another important point is to create a template for 2D animators. The idea is to attract to Blender a new type of artists, and the interface for these 2D artists should be more oriented to them. We have been working on the design during this last year and @pepe-school-land and @mendio have an idea formed of the needs. You can contact with us for more information.

@WilliamReynish Most of your comments about grease pencil have been solved in greasepencil branch and now the tool is working as any other tool in Blender with modes, brushes, etc. We still have pending the use of grease pencil in 2D and the use as annotation tool. Another important point is to create a template for 2D animators. The idea is to attract to Blender a new type of artists, and the interface for these 2D artists should be more oriented to them. We have been working on the design during this last year and @pepe-school-land and @mendio have an idea formed of the needs. You can contact with us for more information.

Juan Gea commented

2018-03-23 16:17:51 +01:00

Added subscriber: @juang3d

Juan Gea commented

2018-03-23 16:17:51 +01:00

I would like to add two suggestions to Alembic:

1.- Make the spline workflow a bit more generic, this could facilitate the conversion in other packages of formats like DWG to be correctly imported in Blender, right now DXF is not working very well, and Alembic, being a more modern format could work better, also as a way to be able to import trajectories or splines modeled in other packages, wich right now is pretty hard to do, for example importing a spline from max is not possible AFAIK since FBX don´t support it and you will have to do different exports to use DXF, and again, it´s slow and not working very well for a bit complex scenes with splines.

2.- Include here the motion blur for deforming meshes with variable vertex count, since there is already a patch maybe this could be reviewed here and added, very useful to be able to cache fluid simulations and use it in production without the overhead of the simulator itself, we can do that right now, but Cycles motion blur won´t work on those imported meshes from Alembic.

I don´t knwo if those two are plausible or possible right now, but I wanted to remark them.

Cheers!

I would like to add two suggestions to Alembic: 1.- Make the spline workflow a bit more generic, this could facilitate the conversion in other packages of formats like DWG to be correctly imported in Blender, right now DXF is not working very well, and Alembic, being a more modern format could work better, also as a way to be able to import trajectories or splines modeled in other packages, wich right now is pretty hard to do, for example importing a spline from max is not possible AFAIK since FBX don´t support it and you will have to do different exports to use DXF, and again, it´s slow and not working very well for a bit complex scenes with splines. 2.- Include here the motion blur for deforming meshes with variable vertex count, since there is already a patch maybe this could be reviewed here and added, very useful to be able to cache fluid simulations and use it in production without the overhead of the simulator itself, we can do that right now, but Cycles motion blur won´t work on those imported meshes from Alembic. I don´t knwo if those two are plausible or possible right now, but I wanted to remark them. Cheers! Cheers!

Paweł Łyczkowski commented

2018-03-23 20:10:13 +01:00

Added subscriber: @PawelLyczkowski-1

Pierre Schiller commented

2018-03-24 10:00:44 +01:00

Added subscriber: @PierreSchiller

Pierre Schiller commented

2018-03-24 10:00:44 +01:00

Commenting on F2478607 on William Reynish document:

Blender icon (without perspective) distortion should be default now. It is communicating clearly a PIVOT (edges around a center) .
On the startup screen. Right after bypassing splash screen, we should have a .png sequence to overlay the interface, showing what the RIGHT click button can do, 3 simple steps at the end tutorial asks: Which interaction mode would you like: RIGHT click or LEFT click? = Leave the choice to the user.
We need floating FOCUS windows. Not just ctrl+alt+U. What if I just want a (selected property) from the property object menu? F6 helps but it doesn´t combine, nor it can stay afloat. Let the user configure more space by "undocking" (floating) windows.
Page 23 makes total sense when using Blender as a 2D application. Finding grease pencil palettes in an object property *yet, there is not a clear view of it on the outliner (or it´s properties) seems confusing for first time users.
Sticky keys are a must (specifically with edit modes. I just want to press "G" and directly move vertices -as a toggle key-) entering edit mode and exiting is almost a 3 step process for every session on the day. Too many wasted clicks just to move a vertex.
We need right click context menu directly from the mouse and not from the bars or spacebar shortcuts.

Thanks for moving such great ideas into the ui design.

Commenting on [F2478607 ](https://developer.blender.org/F2478607) on William Reynish document: 1. Blender icon (without perspective) distortion should be default now. It is communicating clearly a PIVOT (edges around a center) . 2. On the startup screen. Right after bypassing splash screen, we should have a .png sequence to overlay the interface, showing what the RIGHT click button can do, 3 simple steps at the end tutorial asks: Which interaction mode would you like: RIGHT click or LEFT click? = Leave the choice to the user. 3. We need floating FOCUS windows. Not just ctrl+alt+U. What if I just want a (selected property) from the property object menu? F6 helps but it doesn´t combine, nor it can stay afloat. Let the user configure more space by "undocking" (floating) windows. 4. Page 23 makes total sense when using Blender as a 2D application. Finding grease pencil palettes in an object property *yet, there is not a clear view of it on the outliner (or it´s properties) seems confusing for first time users. 5. Sticky keys are a must (specifically with edit modes. I just want to press "G" and directly move vertices -as a toggle key-) entering edit mode and exiting is almost a 3 step process for every session on the day. Too many wasted clicks just to move a vertex. 6. We need right click context menu directly from the mouse and not from the bars or spacebar shortcuts. Thanks for moving such great ideas into the ui design.

Michael P. commented

2018-03-24 20:19:06 +01:00

Added subscriber: @MichaelParucha

Michael P. commented

2018-03-24 20:19:06 +01:00

@ideasman42

Texture Nodes. I use them in the Compositor primary for Procedural textures and Blends. So please redo. Btw, it would be nice if there was a texture input in Cycles too.
Screen Capture (Alt F3). I literally found out about this feature few days ago. This is very useful if you want to record your Blender session.

@ideasman42 * Texture Nodes. I use them in the Compositor primary for Procedural textures and Blends. So please redo. Btw, it would be nice if there was a texture input in Cycles too. * Screen Capture (Alt F3). I literally found out about this feature few days ago. This is very useful if you want to record your Blender session.

Albert commented

2018-03-26 10:50:25 +02:00

Added subscriber: @wevon-2

Albert commented

2018-03-26 10:50:25 +02:00

This comment was removed by @wevon-2

*This comment was removed by @wevon-2*

Albert commented

2018-03-26 10:56:54 +02:00

I completely agree with William Reynish's design document. Working with active tools is more intuitive and unifies all the attributes, options and manipulators related to that tool.
The active tool system is better when you have to repeat an action several times, and although it is less direct, at any time you can call an action directly thanks to the use of Sticky Keys.
The use of Sticky Keys seems to break the current modal system, because it is uncomfortable to press more than one key at a time. I think that by pressing RMB during the execution of the tool, you can display a floating menu with all the options of the tool.
I leave a .gif showing the suggested option.

I completely agree with William Reynish's design document. Working with active tools is more intuitive and unifies all the attributes, options and manipulators related to that tool. The active tool system is better when you have to repeat an action several times, and although it is less direct, at any time you can call an action directly thanks to the use of Sticky Keys. The use of Sticky Keys seems to break the current modal system, because it is uncomfortable to press more than one key at a time. I think that by pressing RMB during the execution of the tool, you can display a floating menu with all the options of the tool. I leave a .gif showing the suggested option. ![StickyN.gif](https://archive.blender.org/developer/F2509940/StickyN.gif)

Jacob Merrill commented

2018-03-28 20:37:12 +02:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2018-03-28 20:37:12 +02:00

What about a system to prerender scene reflection and lighting probes to get decent performance out of eevee?

https://research.activision.com/t5/Publications/Precomputed-lighting-in-Call-Of-Duty-Infinite-Warfare/ba-p/10346417

What about a system to prerender scene reflection and lighting probes to get decent performance out of eevee? https://research.activision.com/t5/Publications/Precomputed-lighting-in-Call-Of-Duty-Infinite-Warfare/ba-p/10346417

William Reynish commented

2018-03-28 20:55:20 +02:00

Didn't really realise the doc would get picked up, but here's an update:

Added concept of a tool menu, for when the toolbar is closed. Currently we don’t have a good solution for that scenario, and the toolbar takes up a lot of space. It'd be nice if it were easier to work with it closed
Drivers UI ideas
A few other bits and pieces

2_8_design_proposal_v02.pdf

Didn't really realise the doc would get picked up, but here's an update: - Added concept of a tool menu, for when the toolbar is closed. Currently we don’t have a good solution for that scenario, and the toolbar takes up a lot of space. It'd be nice if it were easier to work with it closed - Drivers UI ideas - A few other bits and pieces [2_8_design_proposal_v02.pdf](https://archive.blender.org/developer/F2528574/2_8_design_proposal_v02.pdf)

michael knubben commented

2018-03-29 17:11:12 +02:00

Added subscriber: @michaelknubben

michael knubben commented

2018-03-29 17:11:12 +02:00

@WilliamReynish Radial menus are a designed, defined thing, with clear pros and cons. Throwing 30 things into a circle goes against the point.
A pie menu with north, northeast, southeast, east, southwest and northwest in it similarly isn't great. The cardinal directions (north, east, south, west) are the most important, they should be given preference.

Any extra slices after 8 are subject to diminishing returns

@WilliamReynish Radial menus are a designed, defined thing, with clear pros and cons. Throwing 30 things into a circle goes against the point. A pie menu with north, northeast, southeast, east, southwest and northwest in it similarly isn't great. The cardinal directions (north, east, south, west) are the most important, they should be given preference. Any extra slices after 8 are subject to diminishing returns

Antonio Vazquez commented

2018-03-29 17:29:39 +02:00

About adding some type of menu of selection area when tool is collapsed, we had this exact issue in grease pencil branch. When an artist is drawing, he needs the maximum drawing area, and the tools and menus are only annoying things.

As in grease pencil we need select colors, we decided to implement a color selector not depending of the toolbar (we want collapse it). This color picker can be activated from bottom bar or pressing P in the viewport.

Example calling from bottom bar:

Example calling using P key (here all tools are collapsed):

About adding some type of menu of selection area when tool is collapsed, we had this exact issue in grease pencil branch. When an artist is drawing, he needs the maximum drawing area, and the tools and menus are only annoying things. As in grease pencil we need select colors, we decided to implement a color selector not depending of the toolbar (we want collapse it). This color picker can be activated from bottom bar or pressing P in the viewport. Example calling from bottom bar: ![image.png](https://archive.blender.org/developer/F2540636/image.png) Example calling using P key (here all tools are collapsed): ![image.png](https://archive.blender.org/developer/F2540641/image.png)

Vaughan Ling commented

2018-03-29 18:27:20 +02:00

Antonio, I agree! Especially for repetitive tasks like color picking, it's a huge deal to have a popup happening under the cursor to reduce mouse travel.
https://youtu.be/QNixxQ6BVxQ Here is a materials popup I made for this purpose + a few convenience scripts. This also frees up a properties area for something else...before I found myself switching tabs there too often to get to materials.

Antonio, I agree! Especially for repetitive tasks like color picking, it's a huge deal to have a popup happening under the cursor to reduce mouse travel. https://youtu.be/QNixxQ6BVxQ Here is a materials popup I made for this purpose + a few convenience scripts. This also frees up a properties area for something else...before I found myself switching tabs there too often to get to materials.

Juan Gea commented

2018-05-05 20:46:48 +02:00

I´m not sure where to put this, so I´ll put in this more generic thread, but please point me to the correct place if there is one.

This comment is related to the tool settings shown in the Top Bar, the options of Pop Overs is good, but it is rather limiting in some situations, please check this pictures.

The current design is great to hide all the clutter of the tool settings from the UI:

But the current design is also very limiting because it adds an additional click and mouse travel to fix a setting, something you may want to do a lot and very fast in some situations, so some people suggested to put a "pin" in the pop up to keep it visible at all times:

But this is not a solution either because the pop ups are bigger than their names so as soon as you have two pop ups together you get a pretty big overlap problem:

The solution I propose to this is pretty simple, to create a Tool Settings panel, in a similar fashion to the Properties panel, something that is not related to the viewport, it´s a full panel on it´s own, and it will have the same settings shown in the top bar, this could allow more freedom to develop different kinds of tools or addons, and this will give us the ability to rapidly iterate over settings and not loosing sight of them:

This could host also settings and options for more complex addons or tools like ArchiPack, where not everything is just a button activated tool, or for example the Asset Manager addon, where you may want to have all settings at hand at any time.

Hope this is useful in some way, cheers!

I´m not sure where to put this, so I´ll put in this more generic thread, but please point me to the correct place if there is one. This comment is related to the tool settings shown in the Top Bar, the options of Pop Overs is good, but it is rather limiting in some situations, please check this pictures. The current design is great to hide all the clutter of the tool settings from the UI: ![ToolSettings_01.png](https://archive.blender.org/developer/F3277230/ToolSettings_01.png) But the current design is also very limiting because it adds an additional click and mouse travel to fix a setting, something you may want to do a lot and very fast in some situations, so some people suggested to put a "pin" in the pop up to keep it visible at all times: ![ToolSettings_02.png](https://archive.blender.org/developer/F3277245/ToolSettings_02.png) But this is not a solution either because the pop ups are bigger than their names so as soon as you have two pop ups together you get a pretty big overlap problem: ![ToolSettings_03.png](https://archive.blender.org/developer/F3277263/ToolSettings_03.png) The solution I propose to this is pretty simple, to create a Tool Settings panel, in a similar fashion to the Properties panel, something that is not related to the viewport, it´s a full panel on it´s own, and it will have the same settings shown in the top bar, this could allow more freedom to develop different kinds of tools or addons, and this will give us the ability to rapidly iterate over settings and not loosing sight of them: ![ToolSettings_04.png](https://archive.blender.org/developer/F3277278/ToolSettings_04.png) This could host also settings and options for more complex addons or tools like ArchiPack, where not everything is just a button activated tool, or for example the Asset Manager addon, where you may want to have all settings at hand at any time. Hope this is useful in some way, cheers!

Leroy commented

2018-05-06 05:42:05 +02:00

@juang3d What you worry about is exactly what I worry about too, in 2.7x, the tool panel is very friendly for addons setting, yeah, the icon in 2.8 is very beautiful, but not friendly for tools setting and look for tools, e.g. the brush, in 2.7x all in one grid list, but in 2.8, If you are not familiar with it, you must unfold everyone groups to look for, the tools setting too. for quick unfold groups, so I am highly recommended can use hot keys to do this, like when the cursor over the tools group, press A to unfold, and the tool groups can auto unfold when the cursor across over the tools. and best this worked for the top bar too, this very useful for quick work, please please please to add this hotkey. btw I find when the mouse cursor over the value domain will become double arrows, it's make me fill strange, like the old behavior much more. sorry my poor English

Brecht Van Lommel commented

2018-12-11 15:56:03 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-12-11 15:56:03 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.8: Code-Quest (Topics we plan to cover) #54387

Alembic

Asset Manager?

Depsgraph

Drawing API's

Drawing Code Basics

Grease Pencil

Interface

Layers

Manipulators

Modifiers

Operators

Overrides

Physics & Particles

Python API

Refactor

Sequencer

Tools

Versioning

Workspace

Remove Features

After Code-Quest Topics

Nodes