Features:
* Both still image and animation rendering, as well as polygon
fills are supported.
* The exporter creates a new SVG layer for every Freestyle line
set. The different layers are correctly sorted.
* SVG paths use data from line styles, so the base color of a
line style becomes the color of paths, idem for dashes and
stroke thickness.
* Strokes can be split at invisible parts. This functionality is
useful when exporting for instance dashed lines or line styles
with a Blue Print shader
* The exporter can be used not only in the Parameter Editor mode,
but also from within style modules written for the Python
Scripting mode.
Acknowledgements:
The author would like to thank Francesco Fantoni and Jarno
Leppänen for their [[ https://github.com/hvfrancesco/freestylesvg | Freestyle SVG exporter ]].
Differential revision: https://developer.blender.org/D785
Author: flokkievids (Folkert de Vries)
Reviewed by: kjym3 (Tamito Kajiyama)
* Fill brush did not do proper srgb conversion for byte images (reported
by Sebastian Koenig, thanks!)
* Color sampling for palettes did not refresh the toolbar.
trash with float images.
Issue is uninitialized alpha in the clone brush + a clamping issue for
float images. There's still some 'swimming' and brightness issue here
but I have to do work for the weekly, will investigate further later.
Just do not use crazyspace correction with childof constraints in this case.
Note this is only a very partial fix (partial use of parent loc on some axes
is still broken in transform), a real fix would probably require a full rewrite
of constraints handling in transform code (a mere static correction matrix
just cannot work in all possible cases, we'd need a full dynamic correction system here).
Anyway, transform code as a whole is horrible. :/
Old behavior of shuffling the meta made it hard to use metas
in a complex edit since you couldn't be sure if exiting a meta would move it in the stack.
This is so-called GPU limitation boundary hit, told compiler to NOT include
volume bound function, otherwise some real weird things used to happen.
We actually might want to do the same for CPU, inlining everything is not
the way to get fastest code.
Noise function's significant bits are up to 31st bit. This should now
give the same visual result as before, minus the stripes.
Issue pointed out by Anthony Edlin, thanks!
This was way too verbose, heavily factorized the code.
Also made sure only changed data are applied (was not always the case,
especially for curves and lattices), and that we always use raw value
when only one element is affected (was only that way for coordinates).
Note I checked performances, they seem to be roughly the same as previously.
Afaik, a hidden BMesh element should never be selected. And this check was done in an
awfully inconsistent way! If it should really be needed, should be added back as a macro
used everywhere!
Mostly reorganizing mesh data handling to be always in the same order, this piece of code
is rather verbose, let's try to keep it organised a bit.
Also some visual UI tweaking.
