| Age | Commit message (Collapse) | Author |
|---|
|
- use same names as render threads
- remove OpenMP from UI
- remove details from tips
|
|
|
|
be needed according to mapping in code) and change the property to
float.
|
|
|
|
- autodetect optimal default, which typically avoids HT threads
- can store setting in .blend per scene
- this does not touch general omp max threads, due i found other areas where the calculations are fitting for huge corecount
- Intel notes, some of the older generation processors with HyperThreading would not provide significant performance boost for FPU intensive applications. On those systems you might want to set OMP_NUM_THREADS = total number of cores (not total number of hardware theads).
|
|
Previously, amplitude was more of an "absolute" value in the sense that whatever value
you set it to became a sort of "maximum bounce" height. However, it turns out that this
approach isn't so nice when dealing with large gaps between the values of two keyframes,
as the elastic easing equations expect that "amplitude > |change|" (where change is the
difference in values from key1 to key2).
Now, the "amplitude" value we pass to the easing functions are "|change| + amplitude".
This is easier to control, as now, as soon as you start changing that value, there are
immediately visible effects.
|
|
|
|
format is BMP.
|
|
|
|
|
|
grids.
|
|
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
|
|
display gamma
Issue was caused by the old color space settings being lurking around
seq->anim after the changes in color space settings.
|
|
also for SpaceNodeEditorPath
|
|
do not use different stroke property names for different paint systems.
This was done due to different stroke sets being supported for each
system, but this lead to trouble if we changed the names (due to
different stroke sets being supported) and users created custom keymaps
with the old property name saved.
The first part of this fix addresses master. A similar commit will be
done to soc-2013-paint.
|
|
|
|
Crashes due to bad dm face calculation in particle RNA/cycles hair.
This stuff is a total mess, but this kind of check is used in other
places and prevents crashing at least.
|
|
|
|
Located on topology panel.
To use just click on button and click on mesh.
Operator will just use the dimensions of the triangles below to set the
constant detail setting.
Also changed pair of scale/detail size with nice separate float
percentage value.
|
|
Nothing spectacular here, fill tools are easy. Just take the dyntopo
code and repeat until nothing more to do.
The tool can be located in the dyntopo panel when the dyntopo constant
detail is on.
Also added scale factor for constant detail. This may change when detail
sampling gets in, I am not very happy with having two numbers here,
still it will give some more control 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/
|
|
|
|
|
|
|
|
|
|
When path to resolve "finishes" on a collection prop, do not erase the returned prop!
This caused py's path_resolve to return same PointerRNA as the one passed as parameter, leading to
inifinte recursion in Operator's accessor func (__getattribute__)...
|
|
dummy code!)
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D364
|
|
and value/lightness slider stops midway.
Issue here is manyfold:
Color wheel does not support properties with different soft min/max
values than 1.0 (which after experimenting a little I left as is), and
also color management is completely destroying the mapping between the
value slider and the RNA property value range. To solve this I have
disabled color management by setting the property to gamma corrected
(only in RNA, Sequence editor coders please check!), otherwise it will
just become a big mess of tracking where color comes from and what kind
of color transforms it needs in different color pickers (if property has
non normalized range etc). HSL is not really meant to represent colors
outside a normalized space so I have disabled setting lightness above
1.0 in this model.
This will work, however it is hacking a color picker to do something
other than what it is supposed to do: pick a color from the screen
accurately. Which means normalized values always. The non normalized
colors picked for lift/gain/gamma through the pickers do not correspond
to any accurate colors; they are rather a user friendly way to 'sort of'
choose a color and a gamma with an indication of maximum value.
I think that lift/gamma/gain nodes need a dedicated widget for this
(besides it is quite clear that some options are written for that use
case) -or- a separate gamma multiplier for the picked color (which
should itself be in a normalized space)
|
|
Was using wire or black in many places, this color is used for cursor,
camera guides, transform helper lines. So its possible to have a dark
background with light overlay color.
Patch D331 by Brita, with some edits.
|
|
|
|
This is mostly useful for precision in lift/gamma/gain nodes. Display of
those values is done with linear interpolation while saturation is
interpolated cubically. This will lead to color inconsistency between
selected and displayed color on color pickers for instance, which should
be avoided on those use cases.
|
|
|
|
The previous fix 162d6c73e3d0 has been cancelled because it caused a
problem that mesh deform cages and so on mess up the preview. To avoid
the problem, viewport doesn't show mesh object if its draw type is
bounding box or wireframe.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D375
|
|
|
|
This is a standard Hue - Saturation - Lightness model
(see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV)
Note though the difference between HSV and HSL saturation, which are not the same.
The advantage of having this color selection scheme is that artists can select
shades and tints of a color easily by using the lightness slider. Also colors
are arranged on (approximated) perceived lightness on the color wheel.
Beware, Old files opened with this preference saved will crash!
Reviewers: sergey, brecht, campbellbarton
Differential Revision: https://developer.blender.org/D385
|
|
Expose all four quadviews in a collection in RNA API.
Note the region returned by old region_quadview property is now region_quadviews[2].
|
|
The copy-to-selected operator for RNA buttons uses paths for copying
object pointer properties. Copying other ID data blocks is deliberately
disabled:
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_ops.c$274
However, the RNA_path_resolve_full function is not properly working for
retrieving pointer properties: it always will dereference pointer
properties in anticipation of further path elements.
In fact the return value of RNA_path_resolve_full has a conflicting
double meaning. It returns `false` when
* the RNA path is invalid
* any of the pointer properties is NULL
This means that it is not capable of returning pointer properties at all.
To make this possible, there is now an internal function for path
parsing, which returns false //only// if the the path is invalid.
On top of this there are 4 wrapper functions for retrieving either
actual property values (RNA_path_resolve, RNA_path_resolve_full) and for
retrieving pointer+property pairs (RNA_path_resolve_property,
RNA_path_resolve_property_full). The latter 2 variants will **not**
dereference pointer properties at the end of the path, so callers can
actually get the property itself. The `***_full` variants include an
array index return value.
Differential Revision: https://developer.blender.org/D396
|
|
consistency.
|
|
* Moved collection key parsing and array index parsing into their own
functions, to make the main path loop easier to follow.
* Unified boolean return values.
|
|
|
|
|
|
All textures are sampled bi-linear currently with the exception of OSL there texture sampling is fixed and set to smart bi-cubic.
This patch adds user control to this setting.
Added:
- bits to DNA / RNA in the form of an enum for supporting multiple interpolations types
- changes to the image texture node drawing code ( add enum)
- to ImageManager (this needs to know to allocate second texture when interpolation type is different)
- to node compiler (pass on interpolation type)
- to device tex_alloc this also needs to get the concept of multiple interpolation types
- implementation for doing non interpolated lookup for cuda and cpu
- implementation where we pass this along to osl ( this makes OSL also do linear untill I add smartcubic to the interface / DNA/ RNA)
Reviewers: brecht, dingto
Reviewed By: brecht
CC: dingto, venomgfx
Differential Revision: https://developer.blender.org/D317
|
|
These are quite rough and could use some more attention to read better
|
|
|
|
- Added update callback to perform on-update validation when changing the
extrapolation mode on F-Curves
- There was a patch in the tracker for adding an "update()" method to F-Curves
which does a similar thing when manually called by scripts. Since we've added
a function for this in RNA anyways, we might as well add this too while we're
at it. (NOTE: upon closer inspection, the original patch by Tom Edwards had a
number of issues, so I ended up reimplementing here)
|
|
extrapolation from RNA
|
|
|
|
Fix for regression accidentally introduced in 5f18d863a97 (affecting current 2.70 rc-1)
which means that this setting wasn't working anymore at all.
|
|
|
