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().
Without const, I had the following error:
/home/i7deb64/blender-2.5-svn/__work__/freestyle/source/blender/freestyle/intern/python/BPy_ViewMap.cpp: In function ‘PyObject* ViewMap_scene_bbox_get(BPy_ViewMap*, void*)’:
/home/i7deb64/blender-2.5-svn/__work__/freestyle/source/blender/freestyle/intern/python/BPy_ViewMap.cpp:120:54: error: invalid initialization of non-const reference of type ‘BBox<VecMat::Vec3<double> >&’ from an rvalue of type ‘BBox<VecMat::Vec3<double> >’
In file included from /home/i7deb64/blender-2.5-svn/__work__/freestyle/source/blender/freestyle/intern/python/BPy_ViewMap.cpp:3:0:
/home/i7deb64/blender-2.5-svn/__work__/freestyle/source/blender/freestyle/intern/python/BPy_Convert.h:81:12: error: in passing argument 1 of ‘PyObject* BPy_BBox_from_BBox(BBox<VecMat::Vec3<double> >&)’
/home/i7deb64/blender-2.5-svn/__work__/freestyle/source/blender/freestyle/intern/python/BPy_ViewMap.cpp:121:1: warning: control reaches end of non-void function [-Wreturn-type]
make[2]: *** [source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/python/BPy_ViewMap.cpp.o] Erreur 1
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.
Major API updates were made to address code review comments.
This revision mostly focuses on Python wrappers of C++ 0D and 1D elements (i.e.,
Interface0D and Interface1D, as well as their subclasses).
* Most getter/setter methods were reimplemented as attributes using PyGetSetDef.
Vector attributes are now implemented based on mathutils callbacks. Boolean
attributes now only accept boolean values.
* The __getitem__ method was removed and the Sequence protocol was used instead.
* The naming of methods and attributes was fixed to follow the naming conventions
of the Blender Python API (i.e., lower case + underscores for methods and attributes,
and CamelCase for classes). Some naming inconsistency within the Freestyle Python
API was also addressed.
* The Freestyle API had a number of method names including prefix/suffix "A" and
"B", and their meanings were inconsistent (i.e., referring to different things
depending on the classes). The names with these two letters were replaced with
more straightforward names. Also some attribute names were changed so as to indicate
the type of the value (e.g., FEdge.next_fedge instead of FEdge.next_edge) in line
with other names explicitly indicating what the value is (e.g., SVertex.viewvertex).
* In addition, some code clean-up was done in both C++ and Python.
Notes:
In summary, the following irregular naming changes were made through this revision
(those resulting from regular changes of naming conventions are not listed):
- CurvePoint: {A,B} --> {first,second}_svertex
- FEdge: vertex{A,B} --> {first,second}_svertex
- FEdge: {next,previous}Edge --> {next,previous}_fedge
- FEdgeSharp: normal{A,B} --> normal_{right,left}
- FEdgeSharp: {a,b}FaceMark --> face_mark_{right,left}
- FEdgeSharp: {a,b}Material --> material_{right,left}
- FEdgeSharp: {a,b}MaterialIndex --> material_index_{right,left}
- FrsCurve: empty --> is_empty
- FrsCurve: nSegments --> segments_size
- TVertex: mate() --> get_mate()
- ViewEdge: fedge{A,B} --> {first,last}_fedge
- ViewEdge: setaShape, aShape --> occlude
- ViewEdge: {A,B} --> {first,last}_viewvertex
- ViewMap: getScene3dBBox --> scene_bbox
Now we do simple triangulation and calculate signed area of triangles to
account for concave polygons.
This only works correct for planar polygons but gives better results
overall.
finally last transform tool relying on alt has an alternative.
Sequencer slide which makes room for the placed strip by moving others - Pressing G a second time toggles this behavior.
Error since July 2005, when DerivedMesh was introduced.
Vertex and Face duplicators now work for all modifiers. (not only deformers).
For example mirror and array modifier didn't work.
ShrinkFatten operator now uses scale key to toggle 'Even thickness' option.
With the default keymap this is Alt+S,S.
Added functionality so the header print can get the key used for the modal keymap, some other operators should make use of this too.
- update man page for new additions since last release.
- note that --start-console argument is windows only.
- correct own assertion in own recent commit.
The way it works now is:
- Border select is using TWEAK, for which you need to hold LMB down
and move mouse. This prevents operators using RELEASE/CLICK events
from being fired.
- LMB select is using RELEASE event, this is no selection happens
before border if you do border select. And this prevents any
operator uses CLICK event from being fired.
- Delect all happens by CLICK, which would be fired only in case no
operators were handled with PRESS/RELEASE.
This is a bit cards-house, but this is how events currently works and
wouldn't want inventing something bigger now.
The do-version handling for Userdef is outside file reading, which makes
it needed to store the file version in UserDef, so it gets the correct
version to handle.
Thanks Antonis R. for pointing at the omission!
Also removed the mindboggling define. If you do such, then make it
like "MAIN_VERSION_OLDER_THAN() or so.
In general version hacking could be limited much better... ask me
before even thinking to add one, most optimal is to do it in a way
it's not depending on a version ever - forward/backward compatible.
This also revealed another bug, as you could not explicitely set default context to text_ctxt UI func parameter (None is not accpeted by RNA string props), so I had to change default context from py POV to "*" instead of None.
Anyway, that physics UI translation remains weak, as the trick used here (helper func) prevents message extractor script to directly find them. Currently it works because specified labels are also defined elsewhere, but it would be nice to have some kind of "translation markers" in py code too (similar to our N_/CTX_N_ C macros, unfortunately python does not have preprocessing ;) )...
automatically flip the unpinned faces to point down too, instead of trying to
unwrap them in the other direction and giving bad results.
If there's a mix of faces pinned up and down it will pick the direction with the
biggest area.
