Somewhere in the process of generating that Frankenstein font, most latin capital glyphs lost there "modifier" part (umlaut, accent, etc.). I added them again using fontforge auto tool, but not to all of them though, as some would add a shift to the whole font... :/
This is not a nice fix (the correct way would be to merge again the whole latin part of dejavu into blender font, but again, I couldn’t manage to do it without an ugly global font shift), but at least it works, doesn’t shift the font, and add back most modified capitals.
Regression was introduced in svn rev40343. It was caused by re-creating
EditMesh structure which was needed to solve issues with parenting to
vertices after topology changes. This would also erase derivedMesh.
Problem reported now is caused by missing derivedMesh which is used
to solve parenting and apply inverted matrix on ob->parentin, so
parented object used to stay at exactly the same position it used to
stay before parenting.
Not very nice solving of this issue: re-create derivedMesh after
re-creating EditMesh when parenting. Nicer solution would require
bigger changes and probably ful lrefactor of this tools.
* Added some RNA tooltips, now that they are supported by dropdown lists.
* Fixed some RNA num properties UI steps.
* Fixed a memory leak in Proximity modifier (when dm of "target" object had to be created, it wasn’t freed...).
The recent element index work broke edge split entirely, because edge rip was trying to use BM_Get/SetIndex across calls to other BMesh operators (which is bad practice). I've converted it instead to use the indices in the BMO layer, which belongs ot the edge split operator and won't be overwritten by BMO operators called in the process of doing the edge split.
- UV's were not being calculated if there were too many VColor layers.
- precalc (omd->size * omd->spatial_size) was being called in a loop.
- use vector functions to avoid pointer indrections on each access which the compiler wont optimize - eg: och->ibufs_disp[f]->rect_float[4*(res_x*j + i) + 1]
- dont call abs() on ints (converts to double and back to int in this case).
also unrelated render buttons change. move saving options directly under the file path since these were easy to confuse with image format options like zbuf, ycc, preview.. etc.
This patch adds a new CLIP_EVENTS flag for uiBlock, which will prevent the ui_but_find_mouse_over search function from looking into "lower" uiBlocks (i.e. those further back in the list). The order of block creation for nodes has also been updated to use the z-ordering (just the nodetree->nodes list).
In order for this to work, the bounding box values of the uiBlocks have to be set explicitely to fit the node size, those are usually either zero or calculated from the internal buttons.
Some drivers don't support passing include paths with spaces in them, nor does
the opencl spec specify anything about how to quote/escape such paths, so for
now we just resolved #includes ourselves. Alternative would have been to use c
preprocessor, but this also resolves all #ifdefs, which we do not want.
Bring back some old scanfill code to handle tesselating polys with some zero-length edges. This code used to cause #4544 but I haven't been able to recreate that now, so I'm going to revive the old code and if #4544 does come back, we'll have to fix it some other way I guess (or come up with a better solution for zero-length edges in polys).
* Reduce kernel arguments size, helps compile for apple nvidia.
* Fix use of unitialized variable in displace kernel.
* Use build flags in opencl kernel md5 hash.
* Reorganize code for kernel feature #defines a bit.
Constraint (bones case only for now). See [#29100] for some problematic test
cases
* It is no longer necessary to have to press "Clear Inverse" before doing "Set
Inverse" to get a reliable result. The calculation now calculates the pose with
the inverse cleared as it's "baseline" first now, which has the same result as
clearing the inverse manually first.
* Also, this commit trials a new method for computing inverses when there is
more than one constraint on the bone. Previously it just temporarily muted the
offending constraint, but kept all following constraints active, thus
potentially including their results in the inverse calculation. However, since
the inverse should only really care about what the stack looked like up to and
including when the constraint is applied, all constraints starting from this one
onwards are now disabled when calculating the inverse. PLEASE TEST!!! In the
few tests I've done, the effects appear minimal, but this may be quite an issue
in the wild
