Bug #17599:
Summary: Python constraints, good in 2.46 not working anymore in 2.47
http://projects.blender.org/tracker/?func=detail&atid=125&aid=17599&group_id=9
Improved my old hack to avoid frame changed scriptlinks from running when rendering stills, should fix this bug. It also causes REDRAW scriptlinks to be executed during renders, but that conforms to how FRAMECHANGED ones work.
BTW: this can still be improved. The current system meant to disable all Python functionality at once needs imo to be replaced by one that allows to enable / disable per feature (scriptlinks, pyconstraints, pynodes, etc.). A better way to inform scriptlinks about what is going on (render, anim, render anim, etc.) would also help. Will discuss with others.
QUATERNION
B_BONE_REST
INVERT_VERTGROUP
MULTIMODIFIER
to the bpy armature modifier API.
It also fixes a significant problem - In the docs, it refers to
the 'VERTGROUP' field as being a string value, shared
by lattice, armature, etc, referring to the 'VGroup' field in the
armature modifier that defines a vertex group 'mask'
which the armature's effect is restricted to.
However, previously, for some very mistaken reason, in processing
the getters/setters for the armature modifier, the
VERTGROUP field was pointing to the quite different 'Vert. Groups'
toggle in the armature modifier, that enables or
disables using vertex groups for deformation (as opposed to
envelopes).
I've fixed this, so VERTGROUP points to the VGroup string, as is
already defined in the docs and consistent with other
modifiers like Lattice. A new field: 'VGROUPS' has been added,
which is the analog to the 'Vert Groups' toggle.
- This feature had been removed from the code! So this is how things work now:
For normal (non-child) hair particles the length vgroup is used if we're not in particle edit mode and if there are no child particles. So for example checking "Parents" in the visualization panel when children are in use will result in full length parent strands, this is a feature so that you can see how the parent's go to predict child behavior better, not a bug :)
Outliner option 'unlink group' didn't remove its members, in case the
group members were local in file, a confusing situation happened. Now
it removes members.
* Changed hotkey to Alt-I. As a result, Remove IK is now Ctrl-Alt-I, though that shouldn't affect many people at all as it appears that hardly anyone uses it.
* Added menu entries for Delete Keyframe
but don't have an action got the pose of already added armatures, even
though they're not related. This also fixes an issue where the armature
in Blender would end up in the pose from the game after ESC, removes
unneeded copies made during armature evaluation, and also solves the
constraint copying hack.
Tighten test for excluding objects as snap target.
Now exclude all object that are themselves moving (that includes childs of selected objects) as well as objects with moving geometry (like hooked meshes).
The previous situation would cause unfrequent bugs, but especially present in alignment cases (those concerned will understand).
- The cause was indeed corrupted particle settings which should have caused a deletion of the whole particle system. However the particle modifier was still left and that led to the crash.
- A "fix" because there's really no way of knowing what caused the corruption of the particle settings. If anyone else gets this and can recreate I'd love to get a .blend. Now that there shouldn't be a crash anymore the symptom will be a missing particle system after file load in an object that had a particle system before.
I reversed the order of attaching shader objects for linking to solve an
issue in the driver before, but now it appears it needs to be the other
way around again? I don't know if these are the same cards that now want
it different again due to changes in the glsl code, but I found another
workaround for the first bug in a forum post (leaving out parameter names
in the declarations), so with some luck both cases work?
http://developer.nvidia.com/forums/index.php?showtopic=596
The Physics button controls the creation of a physics representation
of the object when starting the game. If the button is not selected,
the object is a pure graphical object with no physics representation
and all the other physics buttons are hidden.
Selecting this button gives access to the usual physics buttons.
The physics button is enabled by default to match previous Blender
behavior.
The margin parameter allows to control the collision margin from
the UI. Previously, this parameter was only accessible through
Python. By default, the collision margin is set to 0.0 on static
objects and 0.06 on dynamic objects.
To maintain compatibility with older games, the collision margin
is set to 0.06 on all objects when loading older blend file.
Note about the collision algorithms in Bullet 2.71
--------------------------------------------------
Bullet 2.71 handles the collision margin differently than Bullet 2.53
(the previous Bullet version in Blender). The collision margin is
now kept "inside" the object for box, sphere and cylinder bound
shapes. This means that two objects bound to any of these shape will
come in close contact when colliding.
The static mesh, convex hull and cone shapes still have their
collision margin "outside" the object, which leaves a space of 1
or 2 times the collision margin between objects.
The situation with Bullet 2.53 was more complicated, generally
leading to more space between objects, except for box-box collisions.
This means that running a old game under Bullet 2.71 may cause
visual problems, especially if the objects are small. You can fix
these problems by changing some visual aspect of the objects:
center, shape, size, position of children, etc.
The 'opposite' of the "Insert Key" tool.
- Use the hotkey Ctrl-Alt-IKEY to activate.
- Only available in 3d-view and buttons window
I've added an extra var to verify_ipo and verify_ipocurve to save having to make another duplicate of that code. Hopefully the gameengine compiles ok with this.
* Moved all keyframing functions to their own file (keyframing.c)
* Merged all the different keyframing options (needed, visual, fast) into a single API call. The direct benefit of this is that it allows them to be used in conjunction with each other. Also, this means that when using the IKEY, autokeying settings for these are respected too.
* Implemented 'keyingsets' system (instead of directly calling insertkey on relevant channels), which is easier to maintain and cleaner. A keyingset basically defines all the channels that can be keyframed together. This paves the way for custom keyingsets sometime down the track (and also for quick-insert keyframes for previously used keyingset).
Menus for choosing the keying set to use are generated automatically from the definitions.
work in the game player, now the IK lib is linked into the player.
Makefiles/Scons/CMake buildsystems have been updated.
Fix materials nodes to work in the game player.
* Fix issue with add transparency mode with blender materials.
* Possible fix at frontface flip in the game engine.
* Fix color buffering clearing for multiple viewports, it used
to clear as if there was one.
* Fix for zoom level in user defined viewports, it was based on
the full window before, now it is based on the viewport itself.
* For user defined viewports, always use Expose instead of
Letterbox with bars, the latter doesn't make sense then.
- Particle now use the deflector objects collision modifier data to collide with deflectors and as a result can now use the velocity of the colliding object for more realistic collisions.
- Dynamic rotations are also quite a bit more realistic and are related to the friction setting of the deflector (to get any dynamic rotations there has to be some friction). This is largely due to the separate handling of rolling friction (approximated to be 1% of normal sliding friction).
- Collisions should be a bit faster on complex deflectors due to the tree structure used by the collision modifier.
- Collision should also generally be a bit more accurate.
To be noted: Only the average velocity of individual deflector faces is used, so collisions with rotating or deforming objects can't be handled accurately - this would require much more complex calculations. Subdividing the deflector object surface to smaller faces can help with this as the individual face velocities become more linear.
working with relative paths. Still doesn't work optimal, since
paths are relative to game.blend which is in the app bundle
under Contents/Resources, so other files need to be moved there
manually at the moment.
