- User Since
- Nov 4 2019, 11:05 AM (85 w, 4 d)
Mar 17 2021
Jul 8 2020
Thanks much for that. But it could be better reachable by
- Adding an entry to the uv context menu next to the stitch menu entry
- Add some shortcuts to the Industry Compatible Keymap for stitching and ripping too.
Jun 17 2020
That's disappointing. I didn't know that there's a well defined threshold for that and hard to believe while looking at all these color values for themes in the prefs. The reason why I brought that up, was because there are quite some people who argued for a more compact layout for modifiers, like the modfiers addon, with a single modifier visible at a time. And with an option for the default behaviour to collapse all modifiers except the most recent unfolded one, you would have made a step to bring those back in. The people on devtalk are just representative for more users with that kind of preference.
Jun 16 2020
A user preference setting would be nice that swaps the behaviour of ctrl clicks and simple clicks completely.
Jun 1 2020
May 21 2020
If workspaces have more than one editor with same type, how to determine which area in one workspace corresponds to the area in another workspace?
May 6 2020
This is no bug and there is no danger that this is introducing problems. If the algorithm finds patches that can be evenly unsubivided it simply takes the position of the "remaining points" of the finegrained mesh itself. This is just the simplest solution for positioning the basemeshes points. Technically this is as valid as any other position and is rather a safe choice. The only thing that decides here about right or wrong is if the baseshape and the displacement combine to be the original smooth input surface.
May 2 2020
Apr 24 2020
Apr 18 2020
See 3378 and 3379 now have duplicates
Apr 17 2020
According to summarizing post, this topic is about solving two problems:
View Selection Occlusion/select through problem and Face boundary selection.
Is it OK to include the 3 options as operators? Like subdivide, subdivide simple and subdivide linear. Then we can disable the simple mode of the modifier in a later patch if we find that it does not have any other use case.
Apr 14 2020
@Jeroen Bakker (jbakker) : I also hope this is still on track for 2.83. If there are some concerns, can we at least have this included and activatable as experimental feature in master.
Apr 7 2020
This problem of unsync meshstates between editmode/objectmode and sculptmode also happens in other cases. It's quite easy to reproduce by using the polygon editing addon polyquilt. It's 100 percent reproducable by using it. I also informed the addon developer about the problem, but I think the info might be placed better here.
Apr 1 2020
Thanks much @Michael Soluyanov (crantisz) for keeping improving it. Personally I really like this version, it is much easier to handle than the previous one. Concerning on what should be included in the syncing I am personally rather agreeing with @Brecht Van Lommel (brecht), that syncing the transforms between the viewports is the most important thing.
Mar 27 2020
@Campbell Barton (campbellbarton) : Any news on this? I am having high hopes for this.
Mar 24 2020
@Richard Antalik (ISS) I tested it on multiple PCs with 1920 x 1200 WUXGA single and multimontor systems. Happening everywhere.
As I've written the amount of deadspace can be increased or decreased depending on the outliners "aspect ratio". So if you increase the horizontal width before duplication the error increases until no scrollbar is displayed at all ( before resizing after duplication)
Mar 22 2020
Mar 20 2020
Mar 18 2020
Mar 17 2020
Mar 16 2020
Oops. Didn't reread what I had written. Yes mixed it up accidently in the last statement. Short taps are obviously meant to permanently activate the tool. (Where you read something about toggling is unclear to me.) But at some point you have to make a decision if it's meant as sticky key or not. And by putting it to the keyrelease timestamp the behaviour will be much more direct.
@Campbell Barton (campbellbarton): I think the functionality should be triggered immediately on press and deciding if it was a tap or a sticky key should be done on key release purely based on the time between press time stamp and release time stamp.
Mar 15 2020
Mar 14 2020
In 2.83 it's working for me and the patch is definitely applied. I don't know if this patch made it into 2.82a. Did you check if that entry is at the top of the list as shown in the patch? ( industry_compatible_data.py )
Mar 10 2020
Yes sure, 0..1 is too wide, but you get the point what I meant. I added the golden angle approach here as it is a simple deterministic series solving that problem very elegant to my view. But I fully agree with what you said.
Contrasting rotations around the colorwheel can be done with the golden angle.
Mar 9 2020
Thanks much @zachman for this. Is there a chance to get this working with Undo?
Mar 8 2020
I also hope this will continue to grow. Sticky keys functionality really deserves to be a global feature.
Mar 6 2020
If you have no OpenCL devices listed, try loading factory settings in the preferences. That should trigger an update of the devicelist.
@William Reynish (billrey) I can see the reasoning, but as @Zachman is also engaged to get this done, I'd wish blenders policy to treat things like this would rather consider that there are people out there using blender as part of their productive environment, than judging on if something feels like a hack.
Hi @Zachman, no worries. I know pretty well how it was during that time. Thanks for your valuation.
Mar 5 2020
@William Reynish (billreynish): Hi William, yes it's certainly annoying. And it's like that for no reason.
Mar 4 2020
Yes obviously it's a duplicate, sorry for that. But that's from July 2019
@William Reynish (billreynish) Could you please have a look.
Mar 3 2020
I agree that red platinum would still fit in quite nicely. It's a lighter grey scheme, something that is no in there yet, places itself nice between "blender light" and "white8". Needs the same kind of fixes as white3 did. preferences, property icons, timeline background, if the camera is the active one the green icon is hard to read.
@Michael Soluyanov (crantisz) : Well done. All good improvments, looks good to me.
Mar 2 2020
Tried out some fixing values for white3.
While I think white3 does overall a good job for a theme that is so bright, it has readability problems with the Properties Panel icons, there's nearly no difference to the background. And the toolbar icons have a much too strong contrast on the other hand. I think that should be tweaked, it feels unfinished.
@Charlie Jolly (charlie) : I never had the shading workspace crash. I still think that this is not one but two different bugs. So did you try applying D6959? It's not yet reviewed, so it's also not in master yet.
I disagree on this being unintuitive. This is behaving exactly as extruding faces, where extruding selected areas normally just cause meshchanges at the selection-border. And if the selection is big enough to contain faces that don't touch this border they are treated the same as these center vertices here. This is how it should be done to my view.
I had a similar case some days ago, where I suddenly had lost track of the object completely, couldn't even restore the view with "View Selected" or "View All". Does this fail in your case too?
Mar 1 2020
Updated to version: 2.83 (sub 5), branch: master, commit date: 2020-02-28 16:45, hash: rB85f980c517e4
Feb 29 2020
@Richard Antalik (ISS): Not sure if https://developer.blender.org/T74303 and this one belong together. I tried importing some images from within the Shading Workspace to the scene and aswell as to the shader editor. Both worked fine for me even if my material properties panel causes crashes.
Feb 28 2020
Don't know if it still has to get narrowed down to what causes it, but it still worked in:
@Campbell Barton (campbellbarton): I testet it some more. And yes seems ATI dependent. And it turns out that this is not related directly to the color chooser.
It's just chrashing delayed, so I got it wrong.
It's crashing because the Material Properties are open.
Feb 27 2020
Hmm strange. This is the latest nightly. Didn't have it before.
Feb 26 2020
Hi Harley, sure for whatever the solution will be like, there will be at least one person that fails using it. But that also applies to other ridiculous things like people could open a save dialog instead of an open dialog and overwrite the file they wanted to load.
Feb 25 2020
@William Reynish (billreynish) : If I get you right you're talking about the change to enable "Selection Only" as Default. Ok yes having this as default might be somehow unexpected. But the feature itself is not seldom useful. So why not simply duplicate the Export Submenu to a "Export Selection". We currently also have "Save As" and "Save Copy".
@William Reynish (billreynish): I know it's not the perfect place/patch to mention the following, but as this patch is at least still pending and is highly related to this topic, I'd like to ask for adding the "Selection only" functionality itself not only to the exporters but also to the FileSave Dialog for blend files. It's just logical to my view to have it in there too and could make saving parts of a blend file much more straightforward if this would be available in combination with "Save Copy".
Feb 19 2020
Feb 18 2020
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/ viewport to opt out of this syncing process, without introducing more control flags.
Feb 9 2020
@William Reynish (billreynish) 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.
Feb 5 2020
"Teardown Extrude" would be my proposal for this.
Feb 4 2020
Feb 3 2020
Feb 1 2020
- 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.
Jan 31 2020
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.
Jan 30 2020
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.
Jan 29 2020
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.
@CobraA (CobraA) 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'.
Jan 27 2020
Jan 26 2020
@Julian Eisel (Severin) Ok, you're right,that are indeed cases I've overlooked.
@Julian Eisel (Severin) I also think such a recalc is unneccessary. A change 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.
Jan 25 2020
I had to factory reset to get it working in blender keymap.
Jan 24 2020
Jan 22 2020
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 they lead to misunderstandings in isolation.