Excuse the trashing here, but seems users prefer this most (though both can be useful).
Note that the UI remains the same,
so this is an option for 'Incremental' snapping instead of a new snapping mode.
Make sure SEQ_TYPE_EFFECT is only used as a flag, not as number
comparison.
This should allow us to add new non-effect types in between
effect types (every 8 indices).
Dirty, but alternative of separating type/subtype means we lose
forward compatibility.
This is not really supported by OpenCL but might happen in certain
configurations. There might be some remained cases when this happens
but so far can not find any,
This is a regression since dced56f and root of the issue comes to the fact
that grid distribution sets UNEXIST flag during distribution, which is then
being reset in initialize_all_particles().
This commit solves the issue, but it's not really nice and some smart guy
might want to revisit it.
It's quite tricky to see if the driver actually depends on time or not,
so currently used approach when we'll be doing some extra updates.
This seems to correspond to how old depsgraph was dealing with this.
Performance tests now have their own CMake macro, which ensures they do not get
added to ctest list, so we do not have to bother about them anymore, and can always
build them (when GTests are enabled, of course).
This is essential for video projection, and the alternative until now was to manually change the projection matrix via Python.
( http://www.blender.org/manual/game_engine/camera/introduction.html#camera-lens-shift
- this page will be removed as soon as I commit this)
Also this is working for perspective and orto cameras BUT if the sensor is not AUTO it will only look correct in blenderplayer (this is an unrelated bug, but just in case someone runs into it while testing this, now you know why you got the issue).
Kudos for the BlenderVR project for supporting this feature development.
Differential Revision: https://developer.blender.org/D1379
Parallel rendering was not working.
The idea of having parallel convergence mode to render as parallel but
visualize as off-axis was good, but it was leading to some complications
in the code.
I think it's more clear to the user if parallel looks and render as
parallel, and if she wants to pre-visualize the converged planes, simply
temporarily set the camera to off-axis.
