Please, focus more on contrast and apparent curvature rather than making it look the same.
Sat, May 25
Fri, May 24
May 16 2019
May 14 2019
May 10 2019
Just to point out, would be nice to have modifiers working on sculpt mode, not the other way around.
May 8 2019
May 5 2019
I like the idea, its really annoying to reach the editing options, but what about X-Mirror? those were together for a while, they will miss each other... why not put them on their private popup menu along with all other object editing options?
Apr 29 2019
Apr 28 2019
Well, I didn't get if you agreed to me or not but you seem right.
I personally don't care about the topbar, I don't like it to be honest, I like the idea of having my settings on the N-bar but from what I understand the topbar is only being used for settings of the active tool system, I also don't use active tools, so I never cared about anything but be able to hide the topbar, but if in the future we happen to have other important settings on the topbar, I'm glad to have them duplicated on the N-bar so, I am not forced to unhide it.
Well, those tool options are not that frequently used, I kinda like the idea of moving these options to the N-bar because I can hide and show it easily whenever I want without much trouble, as opposite to the topbar that doesn't have a shortcut.
I don't care about wasting viewport space if I can hide what I am not using with one keystroke, the only thing that bothers me for the newbies a bit is that the N-bar is kinda far away from the toolbar, but its kinda cool that we could have all those settings located in one comprehensive and meaningful and hiddable place.
This is getting confuse to me.
Anyway the only thing this patch does is moving the topbar to inside the viewport, nothing is really changed from a usage point of view, only that if there are multiple editors with multiple active tools, now each region have its own topbar and even if you hide it you still have access to the same settings in the N-panel isn't that?.
I think my argument is clear. Why can't an active tools user see his tool options in the same bar as other users?
you can! the point is that in addition to having the topbar now its also available in the N-bar If it annoys you that topbar enabled isn't the default anymore, at least keep in mind that it wasn't removed just like Right click isn't.
Apr 27 2019
I like this change a lot, seems like the most mature way to deal with the topbar problem but currently its too hard to hide and unhide the topbar, it should be easier, either by having a shortcut just like N and T bars or by having a toggle somewhere in the viewport header written "Show Tool Settings".
@Alberto Velázquez (dcvertice) I don't quite understand what is your argument, this path seems to be about adding an extra option for you to customize the interface either by using the topbar or not, If I get it right this allows you to hide the topbar and use the n-panel instead but doesn't remove the topbar permanently and doesn't relegate active tool users.
Apr 25 2019
that was my fear, old keymaps not being backwards compatible.
maybe you can upload your keymap file so devs can import and test it?
Apr 23 2019
I just want to point out a thing.
Apr 20 2019
I did mostly for sculpting because as I said more contrast is better.
Apr 19 2019
Apr 18 2019
could we get a soft limit for the sliders, so we can extrapolate if we really wanted?
And yes Please, a curvature blend matcap option would be fantastic for sculpting on a waxy, or oxidation material!
Apr 16 2019
Humm, interesting results but as a sculptor, the stronger the cavity effect, the better, for sculpting, contrast is better than realism, if we could control separately the hue, saturation and brightness of the cavity and ridges it would be perfect.
Got the same issue with GTX 1050, windows 7, and the latest GPU driver, is there any news?
Apr 12 2019
As far as I know its just a matter of using the same normals that are currently used to compute the diffuse shading, It seems like the hair strand vector is being used instead.
Apr 9 2019
Mar 29 2019
Its happening again.
Mar 26 2019
do they work when you start blender using the factory starup batch file in the blender folder?
Well for me the delay seems to be of ∞ seconds.
Please use https://devtalk.blender.org/c/user-feedback for usability feedback, this tracker is strictly for bugs.
Mar 25 2019
Mar 19 2019
@Philipp Oeser (lichtwerk) the purpose of this check is to cycle though items under the cursor when you're not moving it.
This should be a very small value - otherwise the users might move the cursor slightly to select a different item - instead of selecting what is now under the cursor - it will select the *next* item from all items near the cursor.
Would rather avoid a preference - although we could have one which is the distance allowed before the cursor is considered to have moved. (different from drag distance).
Committed rB57395061042fe336dae7ee33e3ae11e53d068194 adding WM_EVENT_CURSOR_MOTION_THRESHOLD which is now scaled by the DPI, if it's still needed the preference can be added there too.
Mar 12 2019
How many times I see this happening.
I kinda agree with @Reinis Adovics (kroko) W should activate context menu both in Left and Right keymaps, there's not a relevant point on making this seemingly random distinction between keymaps. It only makes harder for users who learn different keymaps to talk about the same thing.
Feb 10 2019
@Clément Foucault (fclem), One more information
Feb 6 2019
all the numbers start bigger than 1ms, then they quickly converge to small usual values before I have a chance to take a screenshot, not sure if its the sampling accumulating or actual times.
But those stats don't seem to follow the viewport lag.
@Sebastian Parborg (zeddb) Yes it helps make the viewport smoother. but there must be something changed because it was not happening before even with the driver settings untouched.
Feb 5 2019
Feb 2 2019
Jan 27 2019
Jan 25 2019
It seems related: T60776
Jan 24 2019
Jan 23 2019
@Jacques Lucke (JacquesLucke) It turns out that this problem is being caused by the emulate 3 button mouse option,
here's the .gif
WOW, developers fighting because of an abbreviation.
It might be slightly harder to read but its not the end of the world.
Jan 20 2019
As you might see on this post on devtalk, it's actually an undesirable behavior,
We need selection to behave consistently either by moving the mouse between clicks or not.
Jan 17 2019
@Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht)
sorry annoying you guys, I wish I could get a second review on this. This is not such a big feature but I really believe it could make blender sculpting more competitive.
For some reason, some reviews neither get rejected nor approved, just stay stagnated.
I missed to fix the speeling from one comment... again ><
Jan 16 2019
Jan 15 2019
Jan 14 2019
Removed some unnecessary vector normalizations.
I guess there's not much to do to improve this.
The animator doesn't need to see the whole path all the time, its like onion skin, so this could be solved by limiting the number of frames evaluated, adding a start_clip and end_clip, maybe even with a pretty fading gradient.
I'm not sure it's really deprecated, since those are comments from 10 years ago. @Joshua Leung (aligorith) would know what the status is here I think. Maybe ghost drawing needs to be restored in 2.8, and the comments updated?
Does it compile now?
Jan 13 2019
looks like you missed this one.
Remove pmap check
last diff was corrupted.
Radial may be quite hard to implement on edit mode objects are rarely radially symmetric.
We don't need to unify everything, only the axial symmetry, radial symmetry is a sculpt specific feature.
@Julien Kaspar (JulienKaspar):
The reverse is also true. If you enable Symmetry, and switch to a different object, you'll accidentally then start to manipulate it without Symmetry, because the tool setting was forgotten, because it is now a different mesh. That is equally as annoying. This is my point: There are cases where you may want to use it only with certain objects, and there are other cases where you won't. And that applies to any tool setting.
If Symmetry is really going to be per object, we should do so consistently in all modes, and display it in the ObData Properties.
But, the most consistent solution is simply to make it a mode-wide tool setting, and make it work the same in Edit Mode, Sculpt Mode and the paint modes. There's no difference in use-case, and no logical reason why they should work differently in the various modes.
Jan 12 2019
- Direction estimation now uses sculpt_normal rather than just screen space movement.
- Removed unused if statement.
Jan 11 2019
Yeah, I was willing to implement this for a while, finally I could, lets wait to see if comes a review.
- Improved a bit the performance, by referencing the BMVerts instead of copying the coordinates from it.
- Variable number of iterations depending on the brush strength, maximum iterations is now 5.
Jan 10 2019
Number of alignment iterations was too low, set to 3.