* Made changes to the Controller so that dynamically allocated
memory areas (e.g. imported mesh data, winged edges, and a view map)
are released soon after they become unnecessary.
* Added a new feature edge selection criterion based on image border.
When the "Selection by Image Border" option is enabled, feature edges
are selected only if they are within the border of the image being
rendered. The border is defined either by the frame size or a border
region (specified by the Shift-B key in a 3D View window). When large
scenes are rendered, this clipping by the image border leads to less
memory consumption.
* Enabled the "Silhouette", "Border", and "Crease" edge types of
the Selection by Edge Types option by default.
When no edge types are specified, all feature edges including "Ridge",
"Valley" and "Suggestive Contour" are detected at the cost of extra
memory consumption. Disabling these three edge types and enabling
some other edge type leads to less memory consumption. This change
is intended to help new Freestyle users by providing a typical, low
memory consumption default setting.
* Slightly rearranged the UI controls for feature edge selection.
The Freestyle tab in the Render buttons has a couple of new
options "Group" and "Group Negation". The Group option specifies
a group of objects (defined through the Groups tab in the Object
buttons), while the Group Negation value is either INCLUSIVE or
EXCLUSIVE. If INCLUSIVE, feature edges belonging to some object
in the group are selected. Otherwise, those feature edges not
belonging to any object in the group are selected.
With this option disabled, the smoothness of faces is ignored and
jagged feature edges (when seen from a three-dimensional viewpoint)
are generated. If the new option is enabled, face smoothness is taken
into account during the view map calculation, resulting in smooth
feature edges in 3D. This generally leads to more stable strokes, and
also permits more stylization possibilities relying on the feature
edge smoothness in 3D. The downside of smooth feature edges is that
the visibility is mathematically not well-defined and may cause some
artefact in rendering results. The new option is thus intended to
allow users to try both jagged and smooth feature edges and see which
ones would fit individual application needs. This option is disabled
by default.
- bpy.app.driver_namespace, read-only dictionary, edit in-place.
- reset on file load and new file.
- on errors the namespace used to be reset, this should not be needed.
simple example.
def driverFunc(val):
return val * val
bpy.app.driver_namespace['driverFunc'] = driverFunc
... now all drivers can access this function.
(userpref->system), with a great help from brecht (its been way too long
for me).
However as brecht pointed out that the non-AA text is slightly lareger
then AA'ed Text :S, i did not do anything about this as this commit was
just the option not the text drawing.
this commit also makes it possible to do all kinds of UI textrender options
Crash was caused by invalid utf8 sequence pasteing from the clipboard.
Prevent memory corruption by giving utf8slen() the same rules of bytes checking
as utf8towchar() does.
added r31826.
This is valid python syntax but I rather be strict with data path format else it becomes harder to parse them if we try to support this.
it means checks like fcurve.data_path.startswith('pose.bones["SomeBone"]') isn't ensured to work, since blender uses "" quotes everywhere for keyframe paths I dont think its an advantage to allow users to do it differently.
- glReadPixels() was running to get the depth on each pixel, this works fine one some cards but was locking up on OSX.
- Replace glReadPixels() call with a single call to view3d_update_depths() right after view3d_validate_backbuf(), so the depths are only read once.
- Unrelated to the changes above, but should improve performance: view3d_validate_backbuf() was being called on every redraw while combing, now only call once when combing starts.
we were using SENSOR_RAY for the radar sensor axis. However the Ray axis is inverted (God knows why) so I created a set of defines only for radar sensor.
Also I thought it was a good idea to replace some hardcoded values in Radar and Ray codes by their defines in DNA_sensor_types.h (similar to what Benoit did for Armature Sensor, so I see no problem on that).
from Josh Wedlake (joshwedlake), who provided a reference script used to apply changes in ED_rollBoneToVector().
- Obvious bug fixed where Z-Up didnt work right.
- More align axis options to Recalculate Roll operator: X/Y/Z/View Axis & Negate.
- Axis Only option, ignore the axis direction, use shortest rotation to align bones.
ED_rollBoneToVector() changes:
- would give bad roll when the axis wasn't normalized or perpendicular to the bone.
some callers accounted for this but not all.
- option to align to the axis but not the direction.
Binding code had off-by-1 error, which meant that when "Even Divisions" was disabled the length of the wrong bone would get used.
This error was most noticeable when the lengths of the bones were quite different - for example, a chain with 3 bones of increasing length. Thanks to "Julius" on BlenderArtists for catching this. Cheers!
---
Also, simplified the binding code loop a bit to prevent this sort of error in future.
