behave the same as in 2.4x.
- merge BMesh / Pre-BMesh code shape key conversion code, old code was called as a fallback but merge instead.
- fix possible crash - new bmesh code was clamping the vertex index for the oldverts array by the new total number of verts.
The Post Processing tab in the Render buttons has new Line Thickness options for
defining unit line thickness in two different modes as follows:
1. Absolute mode: The unit line thickness is given by a user-specified number
in units of pixels. The default value is 1.
2. Relative mode: The unit line thickness is scaled by the proportion of the
present vertical image resolution to 480 pixels. For instance, the unit line
thickness is 1 with the image height set to 480, 1.5 with 720, and 2 with 960.
It was a regression since 2.62 caused by how texface is passing to drawParamsMapped
Previously it was used from CD layer but now it's getting copied from MexPoly
into a variable allocated in stack for function void emDM_drawFacesTex_common.
To set texture needed to draw particular face function set_draw_settings_cached
is used, which tries to not to copy texture into GPU when it's not needed (for
example, when drawing bunch of faces with the same texture) and one of condition
if texture should be updated in GPU was comparing address of texface passed to
this function and cached texface. But this address are exactly the sane and
points to a memory inside stack of emDM_drawFacesTex_common.
Fixed by cacheing texface content, not it's address.
faces to a loop quite different than the original first loop. This makes e.g.
duplifaces give rotated results after subdivide or loopcut.
Now it tries to find a first loop that is similar to the old one, to try to keep
the rotations the same.
use the same precision for location all over (2-5 was used), use define as 5.
also disallow boolean to have any subtype besides PROP_LAYER_MEMBER, some booleans had TRANSLATION / XYZ subtypes which don't make sense.
summery: when both verts are outside the viewport
this is in fact a very old annoyance but good to resolve.
fix by doing segment/rectangle intersection between the edge and the viewport so it works when the both verts are outside the view.
Currently copies behavior of clip and image editors:
- On file load, all strip will reference clip they're using
- On adding new strip, clip would be referenced only if it've got zero user
- On removing strip clip wouldn't be de-referenced to prevent clip editors
pointing to zero-counted datablocks.
Not actually ideal from human beings point of view, but referencing/dereferencing
clip on each strip add/delete is getting crappy because of current logic of how
clip datablocks are referenced from clip editor (which is designed to work fine with
loading files without loading UI).
