@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.
Tue, Mar 19
Tue, Mar 12
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.
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.
Jan 9 2019
Hey, I wanna make a patch and submit for review but this problem is happening when I try to build blender for debugging.
I wanna make some changes to sculpt.c, should I just ignore or it can cause problems?
Dec 16 2018
Thanks for a good answer, now, I can understand a bit what happened, the fact that a thing designed to display global settings is being used to display local properties, is really alkward.
,A per-editor bar doesn't exclude topbar, it moves local settings like tools into it, while topbar can keep the global mode-related settings.
Many users are concerned that it's too disconnected from the editors when working with multiple splits in the screen, the topbar switch like crazy and is seemingly disconnected from the editors that it inherits settings from.
Dec 15 2018
Damn! Why you do this?
You look like a bot, Cmon, at least answer the question.
It can be on the devtalk thread, at least tacle the subject a bit, you are the interface designer.
Dec 12 2018
Hey, could someone take a look in this?, its stuck here without triage for a while.
Dec 11 2018
This is a bug, G to move does not work at all in LMB mode
Dec 9 2018
Dec 8 2018
Dec 4 2018
Its just a guess but there's something wrong with the shadow computation when its multiplyied by the reflection, seems like its not completelly zero allowing verry bright spots to "LEAK" when lamps are too strong.
Dec 3 2018
Dec 2 2018
I wish I could start learning the api soon.
Can someone share a download link for the zipped docs so I can try to fix locally?
Weird, it's still not working.
Based on filenames loaded from my browser, I could check which files arent working and which ones are:
Dec 1 2018
Oh, @Erick Tukuniata (erickblender) I found, its a really hidden setting, I guess it should be disabled by default, it is a fundamental fature.
Year, being able to switch from one object to another whithout changing modes is fundamental while sculpting. I am curious also.
Nov 30 2018
Nov 28 2018
Okay, I am kinda mad now.
Nov 26 2018
Why not Clay Engine?
Nov 23 2018
I've just downloaded new font files and replaced on a downloaded copy of the manual and this seems to fix the problem.
Hope someone do the same the the official docs..
Nov 22 2018
- Z Toggle wireframe
- ALT Z Toggle Xray
- Shift+Z Complete pie menu.
Its loading all *.wolf2 fonts but somehow its not rendering some of them
Oh, I guess I figured out.
It looks like a font rendering problem:
I tried with both Firefox and chrome, and the bug happens exactly the same, since I disabled hardware acceleration on chrome and it happens exactly like in Firefox which have acceleration enabled, I guess it's not a hardware specific problem neither software specific.
@Aaron Carlisle (Blendify)
No messages in console