image editor during slide like other operators, instant feedback can be nice but
is not so important here and we don't have notifiers fine grained enough to avoid
full redraws.
This is hopefully the ultimate solution against smoke blockiness near emitter.
Previously high resolution flow/emitter voxels were generated based on the low resolution ones. So if you had 32 resolution and 4 division high resolution, it still used smoke flow generated from those 32 resolution voxels. Now I introduced a new sampling method called "Full Sample" that generates full resolution flow for for high resolution domain as well.
Read more about it in my blog post: https://www.miikahweb.com/en/blog/2013/05/10/getting-rid-of-smoke-blockiness
Also changed "quick smoke" operator default voxel data interpolation mode to "Cubic B-Spline" to smoothen out it even more.
of leading zeros but otherwise the same would show in random order in the file
browser. Selecting an item would change the order of all the items.
Problem was that it was comparing by parsing the number into an int, which has
only limited precision and does not care about the number of leading zeros. Now
do the comparison directly on the string.
Problem was that due to group proxy node the anisotropic node did not detect
early enough that it needs generated texture coordinate data to generate the
tangent. Now the proxy nodes are removed earlier.
BL_BlenderShader was only sending over proper UV data if the current drawing mode was KX_TEXTURED. Now it also checks for (and sends data for) alpha shadows.
This check is actually redundant, because empty intrinsics
will have focal length of 1.0, which means original comment
about BundleIntrinsics was not truth.
It is possible that external user will send focal length of
zero to be refined, but blender prevents this from happening.
The BucketManager was assuming that all modified meshes were rendered when a render pass completed. However, materials that did not cast buffer shadows did not render during the shadow rendering step, and thus were never updated.
In cases keyframes are no so good, algebraic two frames construction
could produce result, for which more aggressive Ceres-based BA code
will fall to a solution for which points goes behind the camera,
which is not so nice.
Seems in newer Ceres returning false from cost functor wouldn't
abort solution, but will restrict solver from moving points behind
the camera.
Works fine in own tests, but requires more tests.
This is an alternative to using camera to scale the
scene and it's expected to be better solution because
scaling camera leads to issues with z-buffer.
Found the whole scaling thing a bit confusing,
especially for object tracking, but cleaning this up
is a bit different topic.
This means bundles' size is not affected by camera scale.
This way it's more useful to work with -- bundles never
becomes too small or too large (depending on reconstructed
scene scale).
Made it so reconstructed scene always scaled in a way
that variance of camera centers is unity.
This solves "issues" when different keyframes will
give the same reprojection error but will give scenes
with different.scale, which could easily have been
considered as a bad keyframe combination.
This change is essential for automatic keyframe
selection algorithm to work reliable for user.
