Issue happened for scene. movie clip and mask strips, which contains
pointers to datablocks which are freeing on loading new file.
Also, scene strip would crash when pasted from clipboard after scene
was unlinked from file.
Such kind of image sequences wouldn't be displayed still
and supporting them would take some additional time, but
for now it'll be no memory leak on attempt opening such
images.
Several major things are done in this commit:
- First of all, logic of modal solver was changed.
We do not rely on only minimizer to take care of
guessing rotation for frame, but we're using
analytical rotation computation for point clouds
to obtain initial rotation.
Then this rotation is being refined using Ceres
minimizer and now instead of minimizing average
distance between points of point of two clouds,
minimization of reprojection error of point
cloud onto frame happens.
This gives quite a bit of precision improvement.
- Second bigger improvement here is using bundle
adjustment for a result of first step when we're
only estimating rotation between neighbor images
and reprojecting markers.
This averages error across the image sequence
avoiding error accumulation. Also, this will
tweak bundles themselves a bit for better match.
- And last bigger improvement here is support of
camera intrinsics refirenment.
This allowed to significantly improve solution
for real-life footage and results after such
refining are much more usable than it were before.
Thanks to Keir for the help and code review.
in the UI
This is the second part of the fixes for [#32492], making it easier to identify
which part of a driver (i.e. which of its targets) is causing problems
A number of additional/related changes needed to be made:
* Red-alert status for layouts is now propagated down to child layouts when they
are created. This is needed as otherwise some of the templates used in the Graph
Editor driver settings won't actually get the red-alert status flushed down to
them. Also, note that this status needs to be set before any widgets are added
to the layout, or else the settings aren't applied when the relevant widgets get
created.
* "Single Property" RNA-Paths resulting in out of bounds array access will now
trigger an error status and appropriate warnings
TODO:
* The error tagging doesn't get applied immediately after variables are created,
or their types changed
* There was also some other weirdness involved when a higher-value flag (1<<10)
was used for this setting, which needs further attention
Two example files that crashed texture nodes.
- On delete texture nodes, it should free the exec cache (because this cache
stores the node pointer.
- On redo, nodes can exist can exist without typeinfo set. Exec (free) code
was not checking for that. Don't ask me why this happens... tex nodes are weird.
This commits adds extra refirenment entry in the menu which is
"K1, K2" and which will apparently refine only this distortion
coefficients.
This would be useful in cases when you know for sure focal length
(which could be obtained from lens, EXIF and so) but not sure
about how good you manual calibration is.
Be careful tho, there're no internal constraints on this
coefficients so distortion model could just screw up into insane
values.
While it's not a good idea to create convex hull shapes from objects
with no volume, this makes them behave a little nicer.
Fixes [#34410] Planes with Rigid Body always keep distance to colliding objects
- Fill in image dimension for camera intrinsics used for
solution refirement.
- Retrieve K3 from camera intrinsics after refining.
Shall be no functional changes, just makes things clear
and robust for further improvements.
structure instead of passing all the parameters to every function.
Makes it much easier to tweak distortion model.
---
svn merge -r52854:52855 ^/branches/soc-2011-tomato
- Moved keyframes and refirement flags into reconstruction options structure
- Moved distortion coefficients and other camera intrinsics into own structure
- Cleaned up reconstruction functions in libmv c-api
---
svn merge -r52853:52854 ^/branches/soc-2011-tomato
Was incorrectly testing for a vertex in a set with BLI_ghash_lookup
rather than BLI_ghash_haskey; the key in this case is always null so
the test failed.
This could leave the PBVH in an inconsistent state, since the
top-level map of BMesh vertices to PBVH nodes would indicate the
vertex was in a node, but that node wouldn't actually have any faces
using the vertex. That inconsistent state would eventually lead to a
crash in pbvh_bmesh_vert_remove().
Fixes
http://projects.blender.org/tracker/?func=detail&atid=498&aid=34370&group_id=9
For the simulation to work properly the limited update the motion paths
calculation did wasn't enough so you got different results for for
motion paths than for the actual simulation.
Now do full frame update if rigid body sim is active.
TODO investigate if we can still limit this.
It's implemented as a separate constraint instead of adding properties
to the existing constraints.
Motors only apply linear and angular impulses and don't limit the
movement of rigid bodies, so it's best to use them in conjunction with
other constraints to limit the degrees of freedom.
Thanks to Markus Kasten (markus111) for the initial patch.
from Lawrence D'Oliveiro (ldo)
notes from tracker:
use bool for return type from BLI_remlink_safe, necessitating including BLI_utildefines.h in BLI_listbase.h
get rid of duplicate BLI_insertlink, use BLI_insertlinkafter instead.
A few places which were using BLI_insertlinkafter (actually BLI_insertlink), when it would be simpler to use BLI_insertlinkbefore instead.
Most nodes use the default size now and don't need explicit function calls. Most remaining nodes can also use the preset variant instead of explicit size values, these are only needed for a few special nodes.
Thanks to Sebastian König for suggesting this and doing the monkey work of changing node definitions.
Highlight background depending on number of tracks existing on frame.
This is not so much mathematically accurate displaying where things
shall be improved, but it's nice feedback about which frames better
be reviewed.
Bad frames are tracks < 8, highlighted with red.
OK-ish frame are 8 <= tracks < 16, highlighted with yellow.
Could be some artifacts with color region start/end, this is a bit
unclear what exactly expected to be highlighted -- frames are
displayed as dots, but in fact they're quite noticeable segments.
---
svn merge -r54572:54573 ^/branches/soc-2011-tomato
notes:
- vertices with zero weights are considered the same as vertices outside of a group.
- currently these show black but this can be made a theme color.
- multi-paint overrides this option (noted in description)
besides performance in some cases.
* DAG_scene_sort is now removed and replaced by DAG_relations_tag_update in
most cases. This will clear the dependency graph, and only rebuild it right
before it's needed again when the scene is re-evaluated.
This is done because DAG_scene_sort is slow when called many times from
python operators. Further the scene argument is not needed because most
operations can potentially affect more than the current scene.
* DAG_scene_relations_update will now rebuild the dependency graph if it's not
there yet, and DAG_scene_relations_rebuild will force a rebuild for the rare
cases that need it.
* Remove various places where ob->recalc was set manually. This should go
through DAG_id_tag_update() in nearly all cases instead since this is now
a fast operation. Also removed DAG_ids_flush_update that goes along with
such manual tagging of ob->recalc.
Now modifier takes a segments parameter.
Bevel edge weights will multiply the overall amount.
For vertex-only, you can give a vertex group name,
and the weights in that will multiply the overall amount.
This is a pretty rare case that can be triggered by switching rigid body
and constraint groups before simulation was validated.
Code checked for existing physics objects but was missing else block.
In rare cases this would allow the simulation to run before being
initialized (if cache is baked and reading cache fails after undo or
loading a file).
Before this change only old flag "Premultiply" was used to
detect alpha mode, which is not enough actually.
Now the logic here is:
- If "Premultiply" was enabled it is likely float image with
straight alpha, which shall be premultiplied before usage.
In this case image/sequence Alpha Mode is set to Straight.
- Otherwise use default alpha mode for image format based on
an extension. This could fail in some cases like TIFF, but
this wasn't handled fully correct in older blender anyway.
Initial discovered issue was that EXR images saved in older
Blender versions were set to Straight alpha mode, which is
obviously a straight way to lots of headache.
This was caused by a floating point precision error. During collision detection, Newton-Raphson iteration is used to find the exact time of the collision. But when using subframes, the initial Newton step was too small. Now the initial step is given in absolute units. When subframes = 0, this should behave almost the same as before.
Thanks to Janne Karhu, Lukas Toenne and Ton Roosendaal for their help with this patch, and to AutoCRC for funding.
alpha was used for them which doesn't work for cleaned footage stored
in EXR file format.
Perhaps we need to support configurable alpha mode for clips, but
that's for later (maybe even after release),
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.
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.