libmv still requires optimization switched off because
of some incompatibility of SSBA and MSVC optimizer which
makes bundle adjustment work just wrong.
This shall not be an issue for Ceres and no need to
disable optimization for extern_ceres
Calculate dependent area based on distortion model rather than
using 15% of image resolution for this.
Some assumptions here:
- We're assuming real-life camera calibration is used here
- Maximal undistortion delta would be achieved on frame boundary
- Distortion fully goes inside frame
This makes it possible to approximate margin for distortion by
checking undistortion delta across frame boundary and use it
for dependent area of interest.
We do not use any formula-based equation here because we're likely
support other distortion models and in that case it'll be stupid
to try detecting formula here.
This fixes a bug in sequencer cut tool:
* if you cut two strips of the same name class (MVI_XXXX.MOV and MVI_XXXX.001)
the two new generated strips will end up with the same name.
(easy test case: add a MOV file with it's accompanying audio track to the
timeline and then cut both strips at once into two pieces)
* visible problem: your animation data will get messed up on the way, since
the animation system doesn't know, which strip it should assign the
animation.
Problem was caused by generating a new list of sequences within the
cut_seq_list() function:
Since dupli_seq() can't see the members of the new list of sequences, it
won't be able to assign unique names in all cases.
The RNA path interpretor code was using a function to get the portion between quotes,
this function was not even checking if there *are* quotes at all! Causing bad
memory allocs or crashes.
Also enhanced the ugly py ast parsing code, so that it now can handle (up to some extent) "name" function nodes, and add bpy.app.translations.pgettext func familly to extracted ones...
This ast py parsing becomes more and more ugly, should probably try to refactor it a bit. :/
When restoring coordinates in sculpt mode (used for several brushes
including anchor brush), can use sculpt_undo_get_node() for
non-dyntopo sculpting instead of sculpt_undo_push_node().
This should bring speed of anchor brush back to 2.65 level for regular
mesh/multires sculpting.
Fixes projects.blender.org/tracker/?func=detail&atid=498&aid=34208&group_id=9
* added area of interest based on a radius around the input tile.
If someone can implement a correct formula (based on K1, K2 and K3) and send it to me, I will be happy to apply it!
- At Mind -
Justa cluster did not have enough memory to handle all Mango 4k scenes.
Option is default disabled and can be enabled in the performance panel.
- At Mind -
Copying scenes didn't handle rigid body worlds previously.
Since we use groups to keep track of objecs in the rigid body sim it's
tricky to do the right thing here since groups aren't duplicated.
One option would be to create new groups and add the duplicated objects
into those but that has other drawbacks.
So the rigid body world isn't copied for now.
TODO find a better way of handling this.
Since rigid bodies need their world to be be updated correctly we now
pass it alongside the parent scene in scene_update_tagged_recursive().
Add BKE_object_handle_update_ex() as well as other object functions
that take a RigidBodyWorld for this.
Ideally this shouldn't be needed but we'd have to restructure scene
handling for that. It's not a small taks however and definitely not
something that can be done before release.
Thanks to Campbell for review.
Blender's triangulator has been rescued :)
This commit fixes errors with concave holes inside polygons.
Simple explanation:
Blender "ScanFill" works by sorting vertices from top-left to bottom-right, and connecting
these vertices with a sorted list of edges they have.
The inner loop then goes over every vertex, its edges, and tries to make triangles by
checking vertices that are next in the list.
- if the triangle has points inside: it creates an edge to this vertex, and continues
- else: add new triangle.
Very simple, fast and efficient. But it needed one more check for the first step: it should
check every vertex inside the triangle, and pick the best vertex for an edge based on forming
the sharpest angle with the tested edge. That solves the case for concave holes.
Blender ScanFill was coded 20 years ago, and is an own invention. I wanted a triangulator that
just fills any collection of polygons, including with holes.
No idea if this was ever published in a paper!
This was caused by multiple instantiations of the same basic problem. The
rigidbody handling code often assumed that "scene" pointers referred to the
scene where an object participating in the sim resided (and where the rigidbody
world for that sim lived). However, when dealing with background sets, "scene"
often only refers to the active scene, and not the set that the object actually
came from. Hence, the rigidbody code would often (wrongly) conclude that there
was nothing to do.
For example, we may have the following backgound set/scene chaining scenario:
"active" <-- ... <-- set i (rigidbody objects live here) <-- ... <-- set n
The fix here is a multi-part fix:
1) Moved sim-world calculation from BKE_scene_update_newframe() to
scene_update_tagged_recursive()
+ This is currently the only way that rigidbody sims in background sets will
get calculated, as part of the recursion
- These checks will get run on each update. <--- FIXME!!!
2) Tweaked depsgraph code so that when checking if there are any time-dependent
features on objects to tag for updating, the checking is done relative to the
scene that the object actually resides in (and not the active scene). Otherwise,
even if we recalculate the sim, the affected objects won't get tagged for
updating. This tagging is needed to actually flush the transforms out of the
RigidBodyObject structs (written by the sim/cache) and into the Object
transforms (obmat's)
3) Removed the requirement for rigidbody world to actually exist before we can
flush rigidbody transforms. In many cases, it should be sufficient to assume
that because the object with rigidbody data attached has been tagged for
updates, it should have updates to perform. Of course, we still check on this
data if we've got it, but that's only if the sim is in the active scene.
- TODO: if we have further problems, we should investigate passing the
"actual" scene down alongside the "active" scene for BKE_object_handle_update().
Yes, again.
There's some t within which reset is not allowed. This is so no reset happens
too often for performance issues. If camera changes too often, some reset could
be missed because of this timeout.
For now tag engine for update, which will update viewport from blender side.
Proper solution could be to detect such a changes from blender side and tag
cycles for refresh instead of trying to detect changes form cycles, but that's
for later.
