Notes:
* Made those edits by full checking of py files, so I should have spoted most needed edits, yet it remains quite probable I missed a few ones, we'll fix if/when someone notice it...
* Also made some cleanup "on the road"!
In previous optimization in outliner I assumed that order in treehash was not important.
But testing outliner in datablocks mode revealed a problem: when user expands multiple recursive levels and then closes any element, it always closed the top level of recursion.
Now it should work fine with recursive trees.
Now treehash contains groups of elements indexed by (id,nr,type). Adding an element with the same (id,nr,type) results in appending it to existing group. No duplicates are possible in treehash.
This commit should also make lookups a little bit faster, because searching in small arrays by "used" is faster than searching in hashtable with duplicates by "id,nr,type,used".
col = layout.column(True)
row = col.row(False)
Items in row would be 'aligned' in the same group as those in col. Now to get this happening, you have to set row as aligned as well.
Please note that fixes for py UI scripts will follow in another commit.
Also fixed labels of RNA pointers searchboxes, which were missing the colon!
builtin classes. This was done in Python 2.3 to prevent changes to the 'object' type definition and similar issues. As explained by Guido van Rossum in the following mail, the python check will look for
the *closest* base class, which fails for RNAMetaPropGroup because its first base is RNAMeta, which is in turn a subclass of 'type'.
http://code.activestate.com/lists/python-dev/34489/
The easiest and safest way to prevent this issue therefore seems to be
to swap the base class order for RNAMetaPropGroup, so that StructMetaPropGroup is the first base, which has a perfectly valid setattr implementation.
Code could enter in an infinite loop when curve value was an odd multiple of PI (i.e. 180°)...
Current code was also factorized and got rid of fabs calls! ;)
and "Branched Path Tracing", to try to make it more clear that this is not
related to progressive refinement, non-progressive was always a bad name anyway.
cuts the mesh in half based on the cursor location and the viewport,
optionally supports filling the cut area (with uvs. vcols, etc),
and removing geometry on either side of the cut.
- Collapse plane track panels by default
- Hide 3D markers when in mask edit mode
- Remove alpha from mask layers list
Discussed with Sebastian and Roman.
- Solved issue with changing marker's frame number
for tracks which doesn't belong to camera object.
- Support find_frame, insert_frame and delete_frame
functions for plane markers.
* Add a "Total Samples" info at the bottom of the panel.
This makes understanding the Non-Progressive integrator easier, as it displays how many samples are used for the different ray types.
* Rename Squared Samples to Square samples, to indicate that the action is not already done. The new Total Samples info should make this easier to understand now as well. Also added back for Progressive integrator, for consistency.
Screenshot:
http://www.pasteall.org/pic/show.php?id=57980
calls: bisect, duplicate, scale, flip, weld.
resolves report [#36475] Symmetrise does not keep uv/weight
also fixes issues with faces that cross the axis more then once.
- plane_point_side_v3(), a bit like line_point_side_v2()
- isect_point_planes_v3(), moved from paint_hide.c
functions to convert between point/normal pairs.
- plane_from_point_normal_v3()
- plane_to_point_normal_v3()
That was not really a bug (code working as expected), but the way tex context was handled was a bit raw, now it is much smarter:
* Default fallback context (when current one is no more valid) will now choose "most specific" ones first (i.e. material/lamp/particules before world and "others").
* When using that default fallback context, previous one is stored and we try to revive it later, if possible. Thus e.g. object[mat tex ctxt] -> empty[default world ctxt] -> object[mat tex ctxt] is now working as expected.
* However, when user explicitely or implicitely (through e.g. going to Material context...) sets a tex context, previous one is not stored, so that only default fallback context switch may later automatically revive a previous (presumably user-set) context.
Problem report by Light BWK through personal communications, thanks a lot!
Apparently there is something wrong in the way how edges are chained to
create strokes. For some unknown reason, strokes may contain a very small
line segment that proceeds in the opposite direction (e.g., downward
even when adjacent stroke segments proceed upward), resulting in the
reported visual artefact.
This revision is intended to address the reported issue in most cases.
The present solution is not a proper fix of the issue. Another code
update with better understanding of the real cause is due in the future
work.
