the render branch.
When a material is linked in and has a light group override, this can now use
a local group in the scene file, by replacing the linked light group with a
local group that has the same name. A use case might be controlling the specular
highlight on linked character's eyes per scene.
Patch from render branch by Pablo Vazquez.
Bit flag 5 has apparently been used for another purpose in old versions, then deprecated and was actually removed from DNA (this should never be done), then later it got reused for SOCK_DYNAMIC. Now a one-time check to clean up these flags is done in do_versions.
The issue here is that the particle instance modifier (pimd) accesses data from the linked particle system modifier (psmd). This data is only correctly generated when the psmd is enabled; here the design violates the modifier principle of providing valid object data (or rather DM) even when disabled.
The solution in this case is to make a custom isDisabled check for the pimd to see if the psmd is enabled. This means the pimd won't work for disabled psmd, but doesn't crash.
- move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice)
- move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators).
- some some cmake includes as system-includes.
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.
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".
