The emitter visibility option is messy design, it makes such checks unnecessarily complicated. A better approach would be to allow non-mesh objects to carry particle data, these objects would just be invisible anyway without having to care about extra settings. However, this conflicts with the simplistic particle design of "owner is the emitter" ...
Caused by modifier updates during dupli-list generation. The dupli-list generation temporarily changes the ob->obmat matrix, which in turn leads to wrong particle states if used for reset. Skip the particle update if no timestep is performed or initialization required.
Proper solution for this problem would be to avoid changing the object data (= particles) state altogether in modifiers, which are usually only writing to DM data and not touching the object or base mesh. This would require a well designed physics framework and integrating it into current particles is close to impossible.
This makes it possible to do a border render inside a viewport even
when not looking through the camera.
Render border could be defined by Ctrl-B shortcut (works for both
camera render border and viewport render border).
Camera render border could still be defined using Shift-B (so no
muscule memory would be broken). Currently used a special flag of
operator to do this, otherwise you'll need to either two operators
with different poll callback or it could go into conflict with a
border zoom,
Border render of a viewport could be enabled/disabled in View
panel using "Render Border" option.
objects in the scene will also cause motion blur.
This change does come with a bit of a slow down to the CPU rendering kernel even
with motion blur disabled, due to extra overhead in handling of object matrices.
It's a few percentages on simpler scenes, not so noticeable on more complex ones.
With motion blur enabled rendering is of course also slower as would be expected,
though from testing especially GPU rendering handles it quite well.
This does not support motion blur from deforming objects yet, only translation,
scale and rotation. Deformation blur is probably for another release.
Issue was caused by some boost filesystem routines accessing current locale
and such an access failed in cases code page isn't specified for the current
locale.
Made it so UTF-8 locale name would be tried to be used first.
- when there was a vertex with 2 boundary edges and one manifold edge (vert at the boundary between 2 quads) it could assert.
- when there is a vertex with 2 boundary verts connected that both use the same face, it would do nothing.
* The symmetrize operation makes the input mesh elements symmetrical,
but unlike mirroring it only copies in one direction. The edges and
faces that cross the plane of symmetry are split as needed to
enforce symmetry.
* The symmetrize operator can be controlled with the "direction"
property, which combines the choices of symmetry plane and
positive-negative/negative-positive. The enum for this is
BMO_SymmDirection.
* Added menu items in the top-level Mesh menu and the WKEY specials
menu.
* Documentation:
http://wiki.blender.org/index.php/User:Nicholasbishop/Symmetrize
* Reviewed by Brecht:
https://codereview.appspot.com/6618059
That was an old check whether tiled EXRs are used during rendering
since version 2.42 where there indeed was a special check for tile
size in EXR tile code.
Now it seems EXR could handle tiles with non-equal size and no
extra tile size check happens for EXR. Anyway EXR tile initialization
happens after initparts, so clamping size in initparts should be
safe for EXR tiles as well.
This operator used to be called "Jump to Frame". It basically takes the midpoint
(frame number and/or value) of selected keyframes, and positions the current
frame (or2d-cursor in Graph Editor) at this point.
The hotkey for this is now Ctrl-G (i.e. as it's similar to a "Goto Frame"
feature). It is also now in the Key menu instead of in the relatively obscure
View menu, even though it doesn't actually result in any keyframe edits taking
place.
(Also, fixed a typo/grammer issue with one of Remove Bone Group operator)
check if the object is already parented to said deformer before trying to add a
new modifier
This should help reduce the number of cases where users inadvertantly end up
creating multiple deform modifiers pointing to the same object, which has been
known to be a cause of "double-transform" artifacts.
Note that this is only able to detect these cases by checking if the parent
object is selected, so this will only really work for the Ctrl-P shortcut where
you have to select both objects first. However, it shouldn't be a problem either
in the Outliner (drag and drop), as the object probably won't be a child of its
parent already if you're doing this.
modifiers now
This makes it harder for users to unwittingly create multiple deform modifiers
by parenting and unparenting a number of times, with the net result being that
"Clear Parent" is now the true inverse operation of "Make Parent".
The Ctrl-G menu for managing Bone Groups has always been a bit clunky,
especially when compared to the Hooks menu (Ctrl-H). This was because the old
menu was more data-orientated (Bone Group Management, Membership to these
groups) whereas this new arrangement should be a bit more task-orientated (Add
to new group, Add to active group, Remove from all groups, Remove active group).
