- User Since
- Mar 15 2015, 2:34 PM (192 w, 1 d)
Thu, Nov 15
@Campbell Barton (campbellbarton) from a graphic-design point of view it doesn't look very good. My (female) co-worker and I still prefer variant 1:
testing here, axes which are in-front are displayed brighter - which is the intent.
I mean the aligned axes (example 1,2) that worked on the previous commit
now they are always bright.
@Campbell Barton (campbellbarton) That's hard to understand and doesn't work as intended for the first paragraph:
+ /* Flip the faded state when axis aligned, since we're hiding the front-mode axis + * otherwise we see the color for the back-most axis, which is useful for + * click-to-rotate 180d but not useful to visualize. + * + * Use depth bias so axis-aligned views show the positive axis as being in-front. + * This is a detail so primary axes show as dominant. + */ + const bool is_pos_color = ( + ((axis_order[axis_index].depth > (axis_depth_bias * (is_pos ? -1 : 1))) == (axis_align != axis))); +
Wed, Nov 14
Anyways, will leave open for now...
Thanks, I still don't understand how this CMS works ;)
Tue, Nov 13
To evaluate this requires more than just recoloring a single screenshot …
You're right, we need a prototype to fine-tune the details.
Personally, however, I believe that you only construct problems that aren't a problem.
I think the negative signs are more disturbing. What if you only change the opacity?
It becomes clear which axis points forwards or backwards:
Fri, Nov 9
Oh, this null pointer is actually the cause of T57639.
Wed, Nov 7
I'm not familiar with the code, but it looks like some timing/concurrency problem.
I think this breaks the build
Tue, Nov 6
Unfortunately I don't know any pattern to reproduce.
Happens here randomly 2-3x / day during a quick work on low-poly game assets.
Mon, Nov 5
I marked it as invalid because it's not a bug and definitely not a crash (the only kind of reports allowed at this moment). But then I felt bad about it and spent my Friday night fixing it.
Sat, Nov 3
Although Pablo very kindly marked this task as Invalid, the problem was IMO resolved in:
UI: Darken the backdrop of navigation gizmos.
UI: Soft drop shadow on 3D Viewport info text.
Fri, Nov 2
Actually, the left mock-up looks good, the outlines are annoying.
I think it does not matter if the backdrop disappears. As long as the (white) text is still readable and the symbol is visible, the grey backdrop loses its original function.
Looks like we have a transparent (white) circle surrounding gizmos already (text doesnt). Unsure what a good solution would be here.
Well, I think the most important option in the entire Blender history would actually be [x] Position Lock ;-)
or maybe just [«] [»] for position undo/redo.
Thu, Nov 1
+ Add [Rotation x y z] – here and in the sidebar?
Setting the cursor position from the sidebar works here (Linux, current tip)
Apr 21 2017
clinfo 2.1.16.01.12 (mesa), this seems to be a related bug/error:
Unfortunately you are right, GCN1 arch ;-(
Even after upgrade to the latest AMD driver still the same issue.
Apr 3 2017
Apr 2 2017
The warning is confusing / probably outdated. Should be something like
'Enable Auto Run Python Scripts in User Preferences > File'
I can confirm the same error message with Ubuntu LTS 16.04 + proprietary AMDGPU-PRO Driver 16.6:
Jun 5 2015
Turns out, there is also a regression in the 'freehand' drawed strokes with the tablet pen. The first screenshot is from v2.74,
the second one from current tip at 94e7ac5b97dd0b15a53d47c78672b8ed1e8a4bf1
Even with my previous 'imrovement' the artist keeps calling
the GP pen pressure support a crap :(
Jun 4 2015
At least it works better for me with both tested Wacom tablets on Linux and Windows7.
Jun 3 2015
gpencil_paint.c:362 /* if this is just the second point we've added, increment the buffer size * so that it will be drawn properly... * otherwise, just leave it alone, otherwise we get problems */ if (gpd->sbuffer_size != 2) gpd->sbuffer_size = 2;
is kind of funny ;-)
Xinput events coming from the tablet pen (a quick rise from full pressure):
(blender probably pick-ups the last a=0 events for the line thickness)
A similar problem has the GP_PAINTMODE_DRAW_POLY mode.
Jun 2 2015
Apr 5 2015
Btw. almost everywhere in blender, the key-repeat doesn't make sense
and should be therefore disabled. I have been teaching already many kids
(using blender). For some reason this is causing big problems
for their fingers/brains. I am curious to see how it is with stickies ;)
(beware: I can't decipher the code and may completely misunderstand the stickies)
this enables the keyboard-repeat and makes the numpad keys behave as
before - here is it expected. But i think, this shouldn't be the default for shortcut-keys
set as hold aka sticky?
Apr 4 2015
The default long-press effect was (2.74):
0 - sort of fly effect
4,6,8,2 - continuous rotation +-h/v
+,- cont. zoom in/out
FWIIW, it seems to be also broken (in a different way) for emulated numpad keys (user preferences -> input).
I believe this is still not working properly. A long press
on numpad , ,  ... is causing weird effects.
It creates in total two clicks (a second one on release).
Mar 31 2015
I see, it's not just a string change, the code is slightly convoluted ;)
Mar 25 2015
Mar 15 2015
+ tiny black lines in the timeline
(see the commit https://developer.blender.org/rBc50003c )