- Added MaskLayer.splines.new (which creates single spline
and returns pointer to it).
- Added MaskLayer.splines.remove() to remove given spline.
- Added MaskSpline.points.new() which creates new point
in the origin and returns pointer to it.
- Added MaskSpline.points.remove() to remove given point.
were no properly updating when rendering animations.
The render engine was only updating the image user current frame on images used
by material textures. Now moved the function that updates all from the editors
to blenkernel level and do it on all frame changes.
Use center of currently visible frame part instead of
center of the whole frame for position of marker which
is adding from toolbox.
Used separate operator for this to keep operators more
atomic and not confuse with lots of conflicting properties.
* Use unified node sizes, as already was done with compositor nodes. Only Mapping node uses a custom size. This way we don't have too small nodes on creation anymore.
* Don't show Script Category for Blender Internal nodes.
Need to initialize FFmpeg for animation player.
This is a bit confusing, but the only way to do this
properly and clear is to call IMB_ffmpeg_init from
playback_mode command line callback.
This is because this callback is blocking and
"usual" FFmpeg initializetion (which happens after
command line parsing) was never called.
Could be switched to separate FFmpeg initializtion
and debug level set but let's keep simple for now.
of threads to the number of cores when the fluid is created. Rather it is now
set to 0 which means "use the number of threads specified for the scene".
This caused high resolution smoke to always regenerate new tile when domain was reinitialized, slowing down especially adaptive domain simulations. Now noise tile is saved in Blender temp directory instead.
There were two issues:
- Line visibility computations are very slow in the case of the provided .blend file, which gave
an impression that the rendering process got stuck. The slowness can be explained by the present
data structures used for the line visibility computations, together with the specific mesh distribution
of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system
to divide tris/quads into small groups in order to accelerate the line visibility computations.
On the other hand, the test scene is populated a big plane (made of one quad) and a moderately
detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to
about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the
tris concentrate in one grid cell, so essentially there is no performance gain from the grid data
structure optimized for speed. It looks like a better grid data structure (possibly based on
adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now
the progress bar of Blender is employed to better inform users of the amount of work done in the line
visibility computations.
- A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid
data structure are determined based on the average area of mesh faces in the given scene. When the big
plane in the test scene is excluded from the rendering, the average area is almost zero (on the order
of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very
large number, causing a fatal memory allocation error. The present revision has introduced a hard
upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
- creating faces was unnecessarily checking if they already existed.
- deleting a face did edge-lookups, when the edges are already available from the face-loops.
