- define array sizes for functions that take vectors.
- quiet some -Wshadow warnings.
- some copy/paste error in readfile.c made it set the same particle recalc flag twice.
Center Cursor uses BKE_object_minmax(), which uses pchans' bone member to check whether a bone is visible or not. But after a duplication, the duplicated pchan->bone are NULL, skiping in this case (as if they were hidden, not optimal but should do the work for now - anyway, using pchan's values in Edit mode does not really make sense, imho).
Made it so meshes, curves, surfaces and metaballs are scaling to a grid cell size,
which makes them behave consistently now.
There're still issues to be resolved still:
- Lattice is not scaled to grid cell size yet, it uses slightly different add
function which makes scaling a bit tricky and hacky. Would prefer to do a
bit bigger refactor here, so it's a TODO for now.
- Cameras, speakers and other helpers are not scaling. They don't have data
on which scale could be applied and perhaps it should be some kind of draw
scale. Also would consider it's a TODO for now.
When inset and bevel used the mouse input as a distance value, the change could be far too great when zoomed in, or far too small when zoomed out. Now get the pixel-size based on the center point of the selection.
Seems the issue was caused by G.is_break set to Truth on both escape
press and release. This ended up in situation when after press event
compositor was tagged to redraw and new job was started. On escape
release this compositor job was cancelled.
Made it so G.is_break is setting on escape press event only.
- maintains quads & ngons
- supports some customdata (weight paint for example works fine).
TODO
- add suppory for loop data (UV's / VCol's).
- outputs invalid geometry when heavily reducing some meshes, needs to be made stable in these cases.
Was a mistake in a code cleanup commit, r51118.
Fixes bug [#32919] Sculting performance regression in svn_51118
projects.blender.org/tracker/?func=detail&aid=32919&group_id=9&atid=498
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.
