| Age | Commit message (Collapse) | Author |
|---|
|
Done using:
source/tools/utils_maintenance/c_sort_blocks.py
|
|
Comment or remove unused defines.
|
|
Without this clang-format may wrap them onto a single line.
|
|
Prevents clang-format wrapping text before comments.
|
|
Needed for clang-format in some cases, see: T53211
|
|
Sometimes the text doesn't fit. What to do in this case?
* Overflow: The default behaviour still is to overflow the text.
* Truncated: If any text box is defined we can also not draw the text
that goes outside the text boxes.
* Scale to Fit: For single-text box texts we can scale down the text until
it fits.
To support textboxes we are bisecting the scale until we find a good
match. Right now the hardcoded iteration limit is 20, and the threshold 0.0001f.
An alternative in the future would be to tackle this by integrating existing
layout engines such as HarfBuzz.
Note: Scale to fit won't work for multiple text-boxes if any of them has
either width or height as zero.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3874
Feature development sponsored by Viddyoze.
|
|
This commit add one regression: it is impossible to currently hide handles
in the viewport. But this should be fixed in another commit.
|
|
They way Blender handles vertical alignment is very buggy:
- Top-Base: It works perfectly.
- Bottom: It is actually bottom-baseline,
and it fails when line size is != 1.0 when working with text boxes.
- Top: Poorly implemented, it should use font's ascent
(recommended distance from baseline),
so it has room for accents,
but it's not one line distance far from the origin (as it is now).
- Center: Poorly implemented.
This is tricky since there is no silver bullet.
To clear this situation I created a new option (Bottom-Baseline),
and addressed the issues above.
I'm getting the ascent and descent from freetype2,
and use this for padding above/below the text.
Also for vertically centering the text.
|
|
|
|
|
|
|
|
|
|
|
|
Strip unindented comment blocks - mainly headers to avoid conflicts.
|
|
|
|
Differential Revision: https://developer.blender.org/D3160
|
|
|
|
Solves these security issues from T52924:
CVE-2017-12102
CVE-2017-12103
CVE-2017-12104
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
|
|
|
|
The legacy algorithm only considers two adjacent points when computing
the bezier handles, which cannot produce satisfactory results. Animators
are often forced to manually adjust all curves.
The new approach instead solves a system of equations to trace a cubic spline
with continuous second derivative through the whole segment of auto points,
delimited at ends by keyframes with handles set by other requirements.
This algorithm also adjusts Vector handles that face ordinary bezier keyframes
to achieve zero acceleration at the Vector keyframe, instead of simply pointing
it at the adjacent point.
Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>;
code mostly rewritten to improve code clarity and extensibility.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2884
|
|
|
|
Access from the curve clean-up menu
|
|
|
|
Cyclic extrapolation is implemented as an f-curve modifier, so this
technically violates abstraction separation and is something of a hack.
However without such behavior achieving smooth looping with cyclic
extrapolation is extremely cumbersome.
The new behavior is applied when the first modifier is Cyclic
extrapolation in Repeat or Repeat with Offset mode without
using influence, repeat count or range restrictions.
This change in behavior means that curve handles have to be updated
when the modifier is added, removed or its options change. Due to the
way code is structured, it seems it requires a helper link to the
containing curve from the modifier object.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2783
|
|
Draws the curve centerline and editmode verts/handles.
Handle theme colors, and normal display still need adding.
|
|
Currently "long keyframes" are only useful for indicating where stationary
holds occur. If however you try to create a "moving hold" (where the values
are slightly different, but in terms of overall effect, it's still a hold)
then it could get tricky to keep track of where these occur.
Now it's possible to tag such keyframes (using the keyframe types - RKEY)
as being part of a moving hold. These will not only be drawn differently
from normal keyframes, but they will also result in a "long keyframe"
being drawn between each pair of them, just like if they had been completely
stationary instead.
Currently the theming/styling of these is a bit rough. They reuse the existing
theme colours for long keyframes.
|
|
|
|
A new option for Font/Text objects vertical alignment:
* Top Base-Line (current mode)
* Top
* Center
* Bottom
The Top is the equivalent as the Top-Baseline with an empty line at the begin of the
text. It's nice to have this option too though, since if we are driving
the alignment via Python we don't want to add extra lines to the text
only to accomodate to the desired vertical alignment.
The Center and Bottom are as intuitive as their name suggest.
When working with text boxes, the vertical alignment only work for
paragraphs that are not vertically full.
Many thanks to Campbell Barton (ideasman42 / @campbellbarton) for the
code review, code comments, and overall suggestions and changes :)
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D2061
|
|
Changing the filepath wouldn't reload the font even after calling scene.update().
|
|
|
|
Code attempted to sync them with materials,
but its not needed (and wasn't reliable).
|
|
|
|
|
|
curve factor.
Root of the issue goes to the fact that bevel list calculation might drop some points
if they're at the same position. This made spline length calculation goes wrong.
Now the length of the bevel segments is stored in the bevel list, so values are
always reliable.
Initial patch by Lukas Treyer with some tweaks from me.
|
|
|
|
|
|
This option (alongside the Ease In/Out/InOut options already available) aims to make it
easier to get an initial curve that looks closer to the one you were expecting, by
automatically picking whether Ease In or Ease Out should be used based on the type of
interpolation being used for the curve segment in question.
Notes:
* The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in)
* This does break compatability with files saved in previous dev builds, but only
if you were using Bounce/Elastic/Back with "Ease In"
|
|
|
|
Summary:
The title actually says it all, it's just possible to
have independent free handles for mask splines. Also
it's now possible to have aligned handles displayed
as independent handles.
Required changes in quite a few places, but they're
rather straightforward.
From user perspective there's one really visible change
which is removed Handle Type menu from the panel. With
asymmetric handles it's not clear which handle type to
display there. So now the only way to change handle type
is via V-key menu.
Rewrote normal evaluation function to make it deal
with new type of handles we support. Now it works in
the following way:
- Offset the original spline by maximal weight
- Calculate vector between corresponding U positions
on offset and original spline
- Normalize this vector.
Seems to be giving more adequate results and doesn't
tend to self-intersect as much as old behavior used to,
There're still some changes which needed to be done, but
which are planned for further patch:
- Support colors and handle size via themes.
- Make handles color-coded, just the same as done for
regular bezier splines in 3D viewport.
Additional changes to make roto workflow even better:
- Use circles to draw handles
- Support AA for handles
- Change click-create-drag to change curvature of the
spline instead of adjusting point position.
Reviewers: campbellbarton
CC: sebastian_k, hype, cronk
Differential Revision: http://developer.blender.org/D121
|
|
Bevel Factor Mapping allows to control the relation between bevel factors
(number between 0 and 1) and the rendered start and end point of a beveled
spline.
There are three options: "Resolution", "Segments", "Spline". "Resolution"
option maps bevel factors as it was done < 2.71, "Spline" and "Segments"
are new.
* "Resolution“: Map the bevel factor to the number of subdivisions of a
spline (U resolution).
* "Segments“: Map the bevel factor to the length of a segment and to the
number of subdivisions of a segment.
* "Spline": Map the bevel factor to the length of a spline.
Reviewers: yakca, sergey, campbellbarton
CC: sanne
Differential Revision: https://developer.blender.org/D294
|
|
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/
|
|
This option was only exposed to the interface and internally
was doing basically nothing.
Removing it to prevent artists from being confused.
|
|
Changed curve active point from pointer to index. Allows curve active point to be saved to file and retained between modes for free. Also some small optimisations by removing pointer look up code.
- Made active point access functions into BKE API calls.
- Fixes operators where curve de-selection resulted in unsel-active point.
- Split curve delete into 2 functions
|
|
Increase the maximum allowed amount of points in a spline from currently 32,767 (short) to 2,147,483,647 (int).
Change variables that get assigned the value from pntsu/pntsv to int type all over the codebase.
Change function parameters that previously passed the count as short to int type as well.
(because https://developer.blender.org/T38191)
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D212
|
|
resolves T38079
|
|
|
|
|
|
EditFont's use of Curve.len was very confusing, in editmode it
represented the number of characters, in object mode the number of
bytes. add Curve.len_wchar and keep track of both.
Also don't convert the editmode text into utf8 on every keystroke.
Now this is done on exiting editmode or save - to match most other
object types.
This also fixes curves 'body_format' being reported with an invalid size.
|
|
There were several issues with how bounding box and texture space
are calculated:
- This was done at the same time as applying modifiers, meaning if
several objects are sharing the same curve datablock, bounding
box and texture space will be calculated multiple times.
Further, allocating bounding box wasn't safe for threading.
- Bounding box and texture space were evaluated after pre-tessellation
modifiers are applied. This means Curve-level data is actually
depends on object data, and it's really bad because different
objects could have different modifiers and this leads to
conflicts (curve's data depends on object evaluation order)
and doesn't behave in a predictable way.
This commit moves bounding box and texture space evaluation from
modifier stack to own utility functions, just like it's was done
for meshes.
This makes curve objects update thread-safe, but gives some
limitations as well. Namely, with such approach it's not so
clear how to preserve the same behavior of texture space:
before this change texture space and bounding box would match
beveled curve as accurate as possible.
Old behavior was nice for quick texturing -- in most cases you
didn't need to modify texture space at all. But texture space
was depending on render/preview settings which could easily lead
to situations, when final result would be far different from
preview one.
Now we're using CV points coordinates and their radius to approximate
the bounding box. This doesn't give the same exact texture space,
but it helps a lot keeping texture space in a nice predictable way.
We could make approximation smarter in the future, but fir now
added operator to match texture space to fully tessellated curve
called "Match Texture Space".
Review link:
https://codereview.appspot.com/15410043/
Brief description:
http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2013/Results#Curve_Texture_Space
|
|
|
