- User Since
- Nov 4 2019, 11:05 AM (15 w, 2 d)
What I tried to say was this. I think it would be a nice achievement if a single workspace could have multiple 3d-viewports synced and multiple unsynced viewports at once.
@Brecht Van Lommel (brecht) The main drawback of a "Sync Across Workspaces" checkbox is, that there is no longer a way for a distinct workspace to opt out of this syncing process, without introducing more control flags.
Sun, Feb 9
Yes things like these could be much clearer with submenus. But most dropdownlists have their dropdown unfolding icon placed on the right side. But here it's on the left side.
And on the right side there would be exactly the expected icon. But that would be for another functionality. So to prevent confusion this should be changed.
Wed, Feb 5
"Teardown Extrude" would be my proposal for this.
Tue, Feb 4
Mon, Feb 3
Sat, Feb 1
- How to handle non US keymaps?
- We could support binding raw keycodes (so we don't need to expand our fixed table of keys to include keys from all keyboard layouts).
- We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference.
Well, speaking of terminology
Xray as word is mainly describing that it's a LookTrough Mode to me. The fact that occluded elements can be selected by this is not really communicated by that and is rather "just" known by it's users. And using it for activating cases where you no longer can't look through is an unfortunate choide of words I think. But lets ignore that for a moment. Perhaps there is a better word that could remedy that.
Yes, you are right with that, the entry itself is there.
Fri, Jan 31
Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling). It is widespread behaviour in industry standards software, so, as industry standard solution, it is more about popularity.
Thu, Jan 30
While technically true, I don't think this is a reasonable argument, The same could be said for select-linked, select-all, select-more... Border and lasso select are projecting selected elements in screen-space, which is different to topology based selection functions.
Wed, Jan 29
Sure, sorry for that.
I personally think a debate should be open to discuss differing approaches and generally look for the solution with the most advantages and I think the devs agree on that too.
No this thread is not turning into a mess. From what I get the description this is about discussing advantages and drawbacks for designing and improving a specific tool. And just saying something has been in there somehow, just to wipe away different approaces is not helpful in any sense. Your argumentation is just about conservation. And I think your agresssive tone was and still is damaging here. I gave you some examples why your argumentation makes no sense, that's all I will say to that sort of comments.
How to make it obvious selecting-trough is enabled
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
Mon, Jan 27
Sun, Jan 26
Ok, you're right,that are indeed cases I've overlooked.
@Julian Eisel (Severin) I also think such a recalc is unneccessary. A change within for a centroid's position that differs from the transform itself is just neccessary if the considered elements change their relative position to each other. That's neither the case for multiple objects nor face, edge or vertex positions. Also in the case of proportional editing the selected elements keeps their relative positions and the unselected transformed ones are not relevant for the gizmo. So I also don't see a concrete cae for a recalc needed. Perhaps we are overlooking a special case, but shouldn't that be treated as a special case for the sake of performance anyway then? So if such a case exists we could also deactivate the cursor for that case until it can be adressed.
Sat, Jan 25
I had to factory reset to get it working in blender keymap.
Fri, Jan 24
Wed, Jan 22
Still unclear to me why this is an argument against "Focus" as a verb, but yes there may be more important topics indeed.
In the end it's relatively unimportant if we use the verbs "frame" or "focus" or "go to" in this case. Personally I like "go to" not that much as frame and focus are geared more towards moving a view or a scope and that is what is happening here.
@William Reynish (billreynish) I understand why you think Playhead is less ambitious. Words like "view" or "frame" are used for many different noncorrelating things. In both forms as noun or as verb. So the lead to misunderstandings in isolation.
- @Campbell Barton (campbellbarton): No I dont think these glitches were introduced by this patch. These already exist.
- Default startup file.
- Duplicate all objects until outliner has vertical scroll-bar.
- Hovering over the right scroll-bar
- doesn't do anything if you are in the upper part of the outliner and move the mouse towards the right side
- works from a specific point on below y wise
Tue, Jan 21
What kind of operation could have set those values ?
Hi Julien, you did use an additional transform by having values set in the delta transform. (Object Properties Panel; below Tranform values).
Jan 16 2020
Yes very nice indeed. Quite some usecases may be somehow comparable to layers though.
Jan 15 2020
Animated Gif (Click to View)
Blender 2.80 Official Release
What would you expect to see here?
For the box select eg. this would fit. No? bpy.ops.wm.tool_set_by_id(name="builtin.select_box)
Jan 11 2020
@David (hlorus) Yes I know that, thanks anyway. I wrote that rather as an info for you. I already have set it up testwise, and probably will suggest it if I will find an equally nice remapping for the conflicting loopselections that aligns with the idea of this keymap. Haven't yet found the time to think about that.
Jan 9 2020
Ok, no problem. Thanks anyway.
Ok I see. And when it finally arrives we'll be there to have a look. But especially in the grayscale version the treshold is not a hardcoded value in that sense but rather an epsilon (the invert2 variant). Could you perhaps also have a look if the icons invert well with that version?
We will eventually have color management on everything.
Hi @Yevgeny Makarov (jenkm), no I don't think we will have to invert the complete icon content. That might be true for arbitrary image content , images with lossy compressions, or icons with many different shades. But in the given case the we have just handdesigned icons with a heavily reduced color palette. I think we have just greyscales and a single keycolor in an icon. That's the opposite of an impossible case for getting a good color separation working.
Anyhow I just wrote it quick down in a couple minutes , so none of the cases I posted were extensively tested or tweaked yet. I posted it just as a base to discuss this as an option.
@Yevgeny Makarov (jenkm) @William Reynish (billreynish)
Hi, by restricting the color inversion the whole shader could be much simpler.
I dropped the HSV conversion completely and tested out the following two inversion ideas. This also has the benefit that the inversion keeps the intended look of the icon better as colored parts keep their values unchanged.
The first one is limiting the inversion to bright and dark colors.
The second one is identifying all values that are nearly greyscale and inverts just these.
I put both invert methods next to each other in the same shader, which is meant as a possible replacement for gpu_shader_image_color_reverse_frag.glsl
Jan 8 2020
@David (hlorus) Thanks much for the info. I wasn't aware of the availability of the _pick variant and have simply assumed you covered the changes within this patch. I am testing the intregration of the _pick variant in my keymap right now. And yes it's exactly what I was asking your for, sorry for that, I wasn't aware of that, cause it's nowhere utilized in the Industry Compatible Keymap, which I am using for Blender.
We'll make sure this works for all tools
@David (hlorus) @William Reynish (billreynish) : Hi David, yes I guess quite some people hope for such an improvement. I think it's great. The control is faster and much more direct that way. I also thought if it's better to have a fourth mode or treat it as a tool as you did. But both method have their pros and cons
@William Reynish (billreynish) Tested it out. Works really well.
Jan 7 2020
@William Reynish (billreynish) : Hi William, a relating proposal was brought up over at Devtalk. I post the link here as it's worth to reread it regarding this patch and for further thoughts about why it is useful and how it could be embedded in blenders workflows.
Jan 6 2020
@Yevgeny Makarov (jenkm): Hey very cool. You could restrict inversion to just very bright colors based on their luminance value compared to a treshold.
Jan 5 2020
Jan 3 2020
Jan 1 2020
I also like what is proposed here. And I disagree to treat collection as a replacement or substitute for object hierarchies, they aren't really the same. Sure collections can be used for instancing and offer partially comparable things for scenemanagment as eg. empties, but as collections themselves have no editable transform, they are per definition no real substitute for object hierachies and I hope collections are seen as an additional tool for scene management but not as a way to remove object hierarchies with transforms as almost any other software out there has and throw it away and solve it once again somehow but differently. Empties and object hierachies are common, they are a simple and efficient solution for many usecases.
Dec 19 2019
Hi Pablo, thats great. As the visualization seems placed at the meshes frontfacing boundingbox side rather than the current mouse position. Is it possible that you also enable this visualization while dragging the slider in the toolsettings remesh popup at the top of the viewport? I think it's as helpful if its contolled from there.
Dec 17 2019
Nov 28 2019
Nov 16 2019
Nov 13 2019
My whole last comment was based on taking up your idea of using the move manipulator, so once again I agree on move gizmo being a good choice for an advanced rewrite and also on the z axis as normal movement handle. If that will be decided it's all fine and dandy and I'm with you.
Nov 12 2019
@Stanislav Blinov (radcapricorn) Sorry I completely overread that you meant the overlay to be individually editable before ripping. My proposals further above are assuming the rip tool itself isn't changed and is based on a single reference point (screenspace, surfacebound raycasted point or whatever) Still I'm not sure if this is beyond of scope for this topic, but it's a nice idea to have the side choices editable. It makes the setup more complex, but offers much more versatile selection options.
@Stanislav Blinov (radcapricorn): I really like the idea of the overlay.
Nov 4 2019
A gizmo as dominant tool access has more pro's than you have listed, eg
-it can easily be used to better present and trigger options, that are right now placed in a hidden popup
-it reduces the overall number of shortcuts needed in blender