* Green (current frame) color now extends to the segments on either side of the
current frame point. This is so that the path is more visible (especially on the
black/dark side), as those segments were prone to being interpolated such that
they became invisible
* Added padding for frame number strings so that they do not overlap the dots
anymore
* Fixed off-by-one error, which meant that the frame number for the first frame
step (white dot) didn't get shown
projecting it. The original paper suggests to simply interpolate between
the two points of an edge if the distance of the point to that edge is
smaller than a threshold.
* Fixed both 3D and 2D code to utilize this. Possibly other places in
blender where this scaling is done will have to be adjusted.
* Changed vertex interpolation to use 2D interpolation, since it already
did projection on plane and 2d calculations are faster.
* Also added notifier on hard recalc when uvcalc_transfor_correction is
used. Results in instant feedback on UV editor when edge sliding.
* Added new option to chose the tile order.
In addition to the "Center" method, 4 new methods are available now, like Top -> Bottom and Right -> Left.
Thanks to Sergey for code review and some tweaks!
Otherwise it'll be nasty crashes when, say, adding and removing
screens with lists visible on the screen.
Thanks Ton for assisting looking into this issue :)
This was difficult to do because we group theme colours and display them
together in user preferences. To make the background options more
presentable and keep them grouped and separate, I needed to group the
two gradient colours somehow. I added a separate ThemeSpaceGradient RNA
struct as opposed to ThemeSpaceGeneric. This struct is the same as
ThemeSpaceGeneric but it lacks the window background option (which does
nothing now) and includes the UiGradient struct which now has both
gradient colours. I modified the clear functions to use a new high
colour from the gradient. Now all options appear grouped and any other
editor that may use a gradient for the window background may do so.
Also corrected incorrect MAIN_VERSION_ATLEAST macro, it would not detect
versions correctly
Issue was caused by preview job starting just moment before
sequencer starts rendering. This lead to threading conflicts
since renderer itself is not thread-safe.
Now all preview jobs would be killed before sequencer starts
rendering stack when final render for preview is enabled.
Replace Tracks.add(count, frame) with Tracks.new(name, frame)
which will return newly created track. Before there was no
reliable way to get newly created tracks.
In most cases it's harmles since this call was intended to be used
for importers only where pattern size was overriding after creation
anyway. But better don't allow things which will work unpredictable.
The problem was that SCA_Joystick::pAxisTest() was using shorts, and tried to store abs(MIN_SHRT) in a short. However, on most systems MIN_SHRT == -32768 and MAX_SHRT == 32767. This means that abs(MIN_SHRT) > MAX_SHRT, and thus the short would overflow.
- Old issue: on scrolling button views, tooltips could open or stayed open.
- New fix: alt+swipe now changes button values again
- Removed test print, from WIP code project.
sculpt_multires_active() now returns NULL if dynamic topology is
enabled. Fixes bug #33718:
projects.blender.org/tracker/?func=detail&aid=33718&group_id=9&atid=498
since we fill it later anyway. Usually OpenGL does color + depth buffer
concurrently so this probably won't have any noticable effect. Still
better be pedantic about it in case we do earn some performance out of
it. Added alpha component in sky color to make sure it is set to zero in
the framebuffer too.
Trackpad zoom (swipe + CTRL) direction was inverted compared to MMB-drag
or scrollwheel usage. In the 3D viewport it was OK, in all others not.
Now the same physical gesture maps identical to zooming everywhere. Or to
recap (with blender factory settings)
Zooming in:
- MMB-drag, move mouse towards screen
- Scroll wheel, move finger towards screen
- Magic Mouse, move finger towards screen
- Trackpad 2-finger swipe: move fingers toward screen.
To make this extra confusing: this is only consistent if you set your system
to inperpret trackpad swipes as "inverted" (pan view left = swipe to right).
This is a typical default, although Apple wants you to call this "Unnatural" :)
Next commit will be testing on laptop if all pinch gestures zoom consistent.
And following to that, a sensible user preference to map trackpad use for
Blender yourself, to invert system defaults again. :)
Blame and thanks goes to Sebastian Koenig, for his perseverance on getting this
solved :)
This will only make object display with proper shape in textured
view, but all materials and textures will be replaced with default
gray color. There's currently no better way to deal with textured
display when dynamic topology enabled because of all UV/tfaces are
clearing when enabling dynamic topology sculpt.
Anyway, better to display gray object with proper lighting in this
case rather than not update object's shape during sculpt.
Proper solution will be possible once CD layer will be preserved
by BMesh log.
without hurting quick texture painting
- ED_view3d_draw_offscreen will now output buffer with
transparent alpha, if sky needed it should be alpha-undered
later.
- ED_view3d_draw_offscreen_imbuf now accepts alpha mode as an
argument which could be either R_ADDSKY or R_PREMULALPHA
- OpenGL render and sequencer's opengl preview will now reflect
scene's Alpha Mode
- Quick Edit will use OpenGL with transparent alpha mode
The current C callback functions are too simple allow a straightforward implementation, in particular they don't receive the PropertyRNA pointer itself as an argument, which means the callback cannot directly access the PropertyRNA's py_data pointers which store the python function objects. For this reason a second runtime variant of these callbacks has been added. It is only used for runtime callbacks and not in makesrna, but otherwise works the same way.
This sub-type is actually *only* needed for the "text" property of UI rna api (maybe we should rename it to "PROP_PY_TRANSLATE", as it is anyway only 'active' during conversion from py string to RNA string property...). In fact, I think it should only be used in RNA func properties anyway, as it stores the translated string into the property, it should only be used with "one time" RNA stuff...
