- User Since
- Apr 18 2016, 11:44 PM (152 w, 4 d)
This is an unintended consequence of the fact that curves now default to Full fill mode, which doesn't exist for text objects, and so it falls back to None.
@YAFU (YAFU) it appears not to work. It is probably a dependancy/update issue.
I think this is ok. It's a shame you cannot change materials if it is pinned to the brush, but I suppose that can be handled later.
This commit seems to break building here on macOS.
@Nick (nickmade) That I cannot reproduce, unless you mean LookDev, which is currently (oddly) hard coded to use Eevee, even if you set the renderer to Cycles.
This doesn't appear to be a bug. Your Screw Modifier Render Steps are simply lower than the regular Steps.
I get similar visual glitches when using the Toon BSDF in Eevee:
Might also be similar to T62726. There are quite a number of cases where the Tool Properties show the wrong things.
More or less the same issue exists with the Cutter tool, which doesn't use brushes. But in the Tool Properties, it still shows brush settings.
Also, while it was not really mentioned in the original paper cut description, the exact same issue exists for the Scale gizmo:
I would not have expected the functionality issue to be fixed so easily.
@Campbell Barton (campbellbarton) Yes, agreed. Then it's nicely consistent, and users can use those keys in all the edit modes.
I mean, it is working as designed I think. Weights are multiplied on top of the colors and lighting.
This issue was solved in 8f3ecd08e1e
Looks all good :) This has also solved the text alignment issue
Here's how it could look if we moved the transform info to the bottom:
This behavior definitely seems wrong. If we are using the 1-3 number keys for the selection modes, it makes no sense to keep 4-9 for Collection visibility.
This seems like a combination of a bug report and a feature request.
The intention with this commit was to make sure the soft limit was 1. Previously, the hard limit was 2.0, so I didn't change that.
@Pablo Vazquez (pablovazquez) It is not a hard limit, but a soft limit.
This seems to have affected checkboxes even where we don't use property split.
Seems good to me I think.
It seems as, after these commits, there are some issues with text alignment in some controls, such as the brush sliders in the top bar:
And also, please provide an example blend file that demonstrates the issue.
@George Vogiatzis (Gvgeo): I think what you need to do is to add a new region. One reference example would be the left tabs region in the Properties Editor. Perhaps you can use this as a reference for adding editor regions.
In an effort to make Blender easier to use and understand, these items were moved into the options sub panel. This makes it possible to clarify what these items are for, all while not cluttering the top level UI.
Thu, Mar 21
Seems to be a duplicate
This feature was removed in 2.8.
Yes, you are right that it makes no intuitive sense why the Grab tool would be slower with Dyntopo enabled, given that the Grab tool doesn’t actually *use* dyntopo.
Yes, we should address this. We have done some work to make sure Blender 2.8 is less ‘blinky’ and ‘jumpy’ compared to 2.79, where header items would move around a lot more.
Probably we should also add Duplicate here, in addition to Copy and Paste?
@Jacques Lucke (JacquesLucke) you are right, it’s not really a bug, more a todo
@Jacques Lucke (JacquesLucke) it’s not actually fully fixed. If you select multiple nodes and drag on them, only the one you drag on is moved.
If you think of copying and pasting text, it works because everything goes into the same buffer. It would be very confusing if each text editor had its own clipboard buffer. The you would not be able to copy and paste between them, which is largely the point of copy/paste to begin with.
Great! IMO I don’t think we need different buffers. It might just end up being confusing then.
Ah yes, I can reproduce it. I was adjusting the viewport clip start, not the camera clip start.
Cannot reproduce here on macOS 10.14 with integrated intel GPU.
@Campbell Barton (campbellbarton) Yes, it just seems a bit inconsistent, given that Box Select doesn't work this way. Down the road, we could add a tool setting for it I suppose. But it's not a high priority item IMO.
Please add the description inside the bug report, and not inside a document needing to be opened in a third part app.
This is how Circle Select worked in previous versions of Blender too, so it doesn't appear to be a bug. I'm not sure why.
- You are using an ancient version of the beta. Please update and test the latest nightly build
- If you still get a crash, please provide exact steps to reproduce it
- We would also like an example file that demonstrates the issue
Blender 2.79 behaves the same.
Confirmed here on macOS.
Just another nudge to say, if we are having trouble fitting it onto the F-keys, I’ve used it with Return, it it seems to work nicely this way.
Wed, Mar 20
@Hans Goudey (HooglyBoogly) it would work exactly like changing the active material slot inside Material Properties.
@Dan Pool (dpdp) yes. We also should make it so you can click to select and shift-click to select more even when clicking on top of the gizmos.
@Sebastian Parborg (zeddb) You are right. I am testing on retina (2x) displays, and so the offset is exactly 2x.
Yes, that's fine.
After testing more, it seems like the offset from the coordinate system origin is applied exactly twice.
Could not reproduce here. I am able to delete and add back the same workspace with no crash.
Still cannot reproduce a crash here.
This is a known issue with edit mode.
Cannot reproduce a crash here.
@Sebastian Parborg (zeddb) No, it works normally here
This seems fine to me.
Tue, Mar 19
I tested this latest patch. For me the UI is ok, but I wasn't able to change the material on the active brush when Material Pin is enabled.
@Dalai Felinto (dfelinto) The constraints were removed from the transform redo panel because it doesn't make sense to move/rotate/scale.