The problem is that the visibility of view edges in the view map may be incorrect.
The main cause of this issue is that view edges are constructed from a series of FEdges
without testing the visibility of the FEdges being concatenated. Later view edges
are split into pieces if two view edges intersect in the 2D image coordinate system.
After that the visibility of the view edges is computed by taking account of occluding
faces in the 3D scene. In many cases this procedure results in correct line visibility,
but not always (that is the problem).
A simple solution experimentally implemented here is not to chain FEdges at all.
Instead view edges are constructed from at most one FEdge now. This solution is only
applied to sharp FEdges (roughly corresponding to edges in the input mesh data; specifically,
silhouette, crease, border, edge mark, contour, external contour, and material boundary).
A better solution is to reorder the three steps of view edges construction mentioned above,
i.e., first splitting FEdges at 2D intersection, computing the visibility of the FEdges,
then concatenating them to build view edges. This solution is left for future work for now.
* Location: Basically the same as the location from Object Info node for object instances on particles, but in principle there could be additional offsets for dupli objects, so included for completeness.
* Size: Single float scale of the particle. Also directly translates to object scale for current dupli objects, but handy to have as a single float to start with instead of a scale vector (currently not even exposed in Object Info).
* Rotation: This is a quaternion, which are not yet supported by Cycles nodes. The float4 is copied to internal Cycles data and stored in the particles texture data, but the node doesn't have a socket for it yet and the data is not yet written to the stack. Code is just commented out so could be enabled quickly if/when rotation support is added to cycles.
* Velocity: Linear velocity vector of particles.
* Angular Velocity: Angular velocity around principle axes.
The texture data is currently packed tightly into the particles texture, which saves a few bytes, but requires an additional texture lookup for some vector attributes which spread over two float4s. Could also add another float4 to particle size to avoid this.
bone renaming
* Renaming F-Curves now checks if the corresponding F-Curve's group can also be
renamed accordingly.
* Changed the RNA updates for bone renaming so that they properly update the
channel lists
WM_keymap_add_item(keymap, "TEXT_OT_insert", KM_TEXTINPUT, KM_ANY, KM_ANY, 0);
<--- this catch-all key map item at the end of the Text Editor keymap was
gobbling all the key events for user-defined hotkeys added after it in the
keymap. This includes all hotkeys for new operators defined by addons (via
keymap.keymap_items.new()).
As a slightly hacky workaround for this, I've added an extra parameter to
keymap_items.new() which will force the newly added item to get added to the
start of the key map items list (i.e. with top priority). To enable, simply add,
head=True to keymap_items.new() calls. For example:
keymap.keymap_items.new("MY_OP_my_operator_id", type='E', value='PRESS',
alt=True, head=True)
This should be useful for cases where there are similar catch-alls, where it is
necessary to insert our item before the offending catch-all (without knowing
which one it is). However, in general, it's recommended not to use this, unless
all other methods (inlcuding choosing another key combination if your first
choice doesn't work) fails.
Avoid using tricks with ibuf->profile to check whether image buffer is
in sequencer or linear space. Assume the whole sequencer works in non
linear float space and do transformation to linear where it;s needed
only.
This removes confusion from the code, fixes wrong behavior of some
effects.
Around Frame is enabled
It turns out that the final "rebuild pose" at the end of each ghost drawing step
was at fault here, as it resulted in bones referring to a different set of
constraints after each ghost drawing step. However, most of the time, these new
references pointed to non-existent locations, causing the segfaults.
To fix this, I've removed this last rebuild step, which seems to work fine (no
major problems seem to arise from this). Also, to ensure that the other object
parameters have not changed (as a result of the reevaluation that needs to go
on), we now evaluate the object once more after all the ghost drawing (but
before final restore) so that object parameters (and potentially sub-data) are
all restored to their original values.
An upside of removing the final rebuild step is that "In Range" and "On
Keyframe" ghosting options now work with proxies again. Previously, trying to
move bones (but without autokey enabled) would mean that bones would snap back
to their unkeyed positions.
Makes it possible to investigate color managed ranges.
Not ideal but it's the quickest thing which could be done to remove
current grading stoppers for Mango.
