Keyframe handle vertices (the circles on the ends of the handles)
should always be larger than the central vertex. This brings back the
"outer" radius value from the old gluDisk(), and doubles it to get the
necessary diameter, to scale it properly.
TODO's:
- Get rid of all fills inside these circles
- Make the central vertex square-shaped again
Goal is to make them more modular, to allow more variants (variable
single-color, thickness, ...) to be added without having to
copy-and-change-one-line of whole chain of shaders.
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
I started cleaning up UI_view2d_scale_get where the y scale was unused, then got carried away...
- for loop scope
- declare variables closer to where they are used
- move early exits closer to function start
- unsigned --> unsigned int
This also fixes a little bug, which caused `draw_fcurve_samples` to
never be called, and thus sampled curve range boundaries were not drawn.
Part of T49043
Updated shader names and code that uses them.
All of these shaders produce round points that are anti-aliased and blended against the background.
These were initially named SMOOTH because they replace glEnable(GL_POINT_SMOOTH). But SMOOTH in shader-land refers to vertex attribute interpolation (like glShadeModel(GL_SMOOTH)).
Using SMOOTH to mean two things is confusing, so we now use AA to mean "the point is anti-aliased".
Got rid of GLU and some matrix manipulation. Everything is shader driven now, drawn with point sprites.
Still plenty to do in this file...
Part of T49042 and T49043
This commit introduces a scale factor setting for scaling all keyframe indicators
in the Dopesheet Editor up/down, in order to make them easier to select. It is perhaps
most useful for keyframe types which are usually indicated using smaller keyframes
(e.g. breakdown), which may get tricky to quickly select.
This fixes some of the issues noted by venomgfx that were caused by
Se25ba162c0b62b19cf367f0f29e29d0c0960978d
Specifically, this commit fixes:
* Timeline: Keyframe lines
* Graph Editor: Curves and Handles
Each LINES draw call is now responsible for its own line width. No need
to set it back to its 1.0 default after every draw.
This eliminates half our calls to glLineWidth , similar to last week’s
work on glPointSize.
I put all usage of GL_POINTS under the microscope. Fixed problems &
optimized a couple of spots.
- reduce calls to glPointSize by about 50%
- draw selected & unselected vertices together for UV editor & EditMesh
- draw initial gpencil stroke point the proper size
- a few other smaller fixes
New policy: each GL_POINTS draw call needs to set its desired point
size. This eliminates half our calls to glPointSize (setting it back to
its 1.0 default after every draw).
Apparently this is the result of some sloppiness during 2.5 project and since then it confused people who were trying to understand the area-region relation (myself included).
Sorry if this causes merge conflicts for anyone, but at some point we really had to do it :/
When renaming animation channels, the old names are no longer drawn behind the
text boxes anymore. This used to cause problems if the names were long, or
if text boxes were set to have transparent backgrounds.
Thanks to kopias for reporting on IRC.
For FCurves where all the keyframes use the "simple" interpolation types
(i.e. Constant, Linear, and Bezier), we now use the old FCurve drawing
code that was used prior to the Easing Equations changes. This should
be generally faster in general.
When the "High Quality Line Drawing" option (View menu) is disabled,
the sampling rate (i.e. the size of timesteps to use when sampling
the FCurve for drawing it in most cases now) is set to be quite low
(i.e. at 0.1 frame increments). This amounts to at most 10 sub-steps.
In one test file (with a wide window), this had the effect of improving
the performance by over 3x. It's still not as good as a sampling-free
approach, but for this functionality is still needed for FModifiers,
so it's better that we can optimise this.
Make the UI API more consistent and reduce confusion with some naming.
mainly:
- API function calls
- enum values
some internal static functions have been left for now
This commit introduces support for a number of new interpolation types
which are useful for motion-graphics work. These define a number of
"easing equations" (basically, equations which define some preset
ways that one keyframe transitions to another) which reduce the amount
of manual work (inserting and tweaking keyframes) to achieve certain
common effects. For example, snappy movements, and fake-physics such
as bouncing/springing effects.
The additional interpolation types introduced in this commit can be found
in many packages and toolkits (notably Qt and all modern web browsers).
For more info and a few live demos, see [1] and [2].
Credits:
* Dan Eicher (dna) - Original patch
* Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase
* Joshua Leung (aligorith) - Code review and a few polishing tweaks
Additional Resources:
[1] http://easings.net
[2] http://www.robertpenner.com/easing/
Added two options to a header of FCurve editor:
- Normalize which makes it so every individual
curve is fit into -1..1 space.
- Auto-normalize, which probably is to be called
"Lock" which "locks" curve normalization scale.
This is useful to prevent curves from jumping
around when tweaking it.
It's debatable whether it need to be a button to
normalize curves n purpose only, and it's fully
depends on animator's workflow.
Here during Project Pampa we've got Francesco
who get used to auto-renormalization and Hjalti
who prefers locked behavior.
Docs are to be ready soon by Francesco.
Thanks Brecht for the review!
Remove usages of ANIM_unit_mapping_apply_fcurve in favor of
runtime scale factor apply.
There're still calls to ANIM_nla_mapping_apply_fcurve are
hanging around, they're the next t be cleaned up!
