Fix for 2.66a
Some editors in Blender (Like Graph) have "maxzoom" set to 0, which caused the
MMB zoom sensitivity to be minimal. That used to be much more responsive, restored
it to how it worked before.
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.
Main purpose of this is to be more compatible with older
versions of blender (before alpha cleanup) where sequencer
used to display premultiplied image on an straight opengl
viewport.
Now sequencer preview would behave closer to image editor
However adding Alpha and R|G|B displays is not so simple
because sequencer is using 2D textures. Would be nice to
implement this options as well, but this is not so much
important IMO.
This hall fix
- #34453: VSE: Subtract function does not work properly
TODO: Make RGBA display default for our startup.blend
- linking groups into a scene now uses the objects original layers (some users have the layers set to useful values, so overwriting isnt so nice).
- dropping objects into the 3d view would make them active but not selected, a valid but confusing state, since most tools activate and select now objects.
This fixes the placement code of new files added to the sequencer timeline.
The old code tried to guess the strip position from the current mouse
pointer position.
Annoying effect: if you add a new strip using the menu, especially if the
file editor pops up, the strip ends up in nowheres land (most likely around
track 40, frame -200).
New behaviour: strips are always placed at cfra, which is the
sequencer equivalent to the 3D cursor (and that's where new objects in
3D editing end up).
Bonus feature: we try our best to guess the right track by finding the
nearest strip by type.
The patch was inspired by
[#32766] VSE: Add Strip on Current Frame
Thanks to venomgfx for the idea!
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.
in fact the keymap editor was missing other keymaps so added these too,
also updated keymap checker to make sure there is no mismatch with region/space types.
code is still unused, but the intention is to use this to solve the double sided
lighting problem on NVidia, and to make the materials work on OpenGL ES 2.0
eventually.
The code works and matches the fixed function lighting pretty much exactly, but
still needs optimizations. The actual integration in object draw will be
committed later when more fixing & testing, there's lots of different combinations
and unclear OpenGL state here.
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
