| Age | Commit message (Collapse) | Author |
|---|
|
|
|
had a typo too.
|
|
|
|
functions with a macro.
|
|
|
|
/ classes.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
* BL_DeformableGameObject is no longer responsible for handling keys, BL_ShapeDeformer is
* BL_ShapeDeformer also creates a copy of the key on construction and puts it back on the mesh when destructed. This avoids us permanently modifying Blender data.
* I'm not too fond of clearing out the key every frame, but this works and I can't think of another alternative at the moment (something may be possible with some key juggling)
|
|
anything, only contained a hash map and functions to pass command line args
to the game engine. Moved those to container and BlenderRoutines modules.
|
|
gameplayer, ketsji
|
|
running a shape actuator on a softbody would crash because it assumed the deformer was a BL_MeshDeformer.
Added TODO note, since it would be nice if softbody would work with shape keys too.
|
|
- ignore MSVC warnings when FREE_WINDOWS is defined to quiet warnings.
- the CMake flags were not being set correctly making blender have weirdo colors (no -funsigned-char).
|
|
- CMake building without python or fluidsim working again (broke in recent commit)
- remove BLI_short_filename(), it wasnt used anywhere.
|
|
|
|
MEM_mallocN for better tracking memory usage.
* off by default.
* new/delete are at the bottom of each class
* python BGE objects have the new/delete in the Py_Header macro.
|
|
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD
Notes:
* Game and sequencer RNA, and sequencer header are now out of date
a bit after changes in trunk.
* I didn't know how to port these bugfixes, most likely they are
not needed anymore.
* Fix "duplicate strip" always increase the user count for ipo.
* IPO pinning on sequencer strips was lost during Undo.
|
|
Added SetDeformer/GetDeformer() to KX_GameObject.
Store mapping between graphics/soft body vertices (work-in-progress)
Real-time soft body integration is still very premature, but
for a quick preview, see this testfile:
http://bulletphysics.com/ftp/pub/test/index.php?dir=blender/&file=soft_test.blend
|
|
generalize protection against object deletion for all actuators that point to objects.
Certain actuators hold a pointer to an objects: Property,
SceneCamera, AddObject, Camera, Parent, TractTo. When a
group is duplicated, the actuators that point to objects
within the group will be relinked to point to the
replicated objects and not to the original objects.
This helps to setup self-contained group with a camera
following a character for example.
This feature also works when adding a single object
(and all its children) with the AddObject actuator.
The second part of the patch extends the protection
against object deletion to all the actuators of the above
list (previously, only the TrackTo, AddObject and
Property actuators were protected). In case the target
object of these actuators is deleted, the BGE won't
crash.
|
|
Shape Action are now supported in the BGE. A new type of actuator "Shape Action" is available on mesh objects. It can be combined with Action actuator on parent armature. Only relative keys are supported. All the usual action options are available: type, blending, priority, Python API. Only actions with shape channels should be specified of course, otherwise the actuator has no effect. Shape action will still work after a mesh replacement provided that the new mesh has compatible shape keys.
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
replacement call.
from brian hayward (bthayward)
Detailed description:
Currently, when an armature deformed object's mesh is replaced by the ReplaceMesh actuator, the new mesh fails to deform to the armature's movement.
My patch fixes this by properly replacing the deform controller along with the mesh (when appropriete).
For instance, if one had an animated character using any of the standard deformation techniques (armature, ipo, RVK, or AVK), that character's mesh would currently be prevented from changing mid-game. It could be replaced, but the new mesh would lack the controller which tells it how to deform. If one wanted to dynamiclly add a hat on top of the character's head, it would require storing a secondary prebuilt character (mesh, armature, logic, ect...) on another layer FOR EACH HAT the character could possibly wear, then swapping out the whole character when the hat change was desired. So if you had 4 possible hat/character combos, you would have 4 character meshes, 4 armatures, 4 sets of logic, and so on. I find this lack of flexibility to be unresonable.
With my patch, one could accomplish the same thing mearly by making one version of the character in the main layer, and adding an invisible object atop the character's head (which is parented to the head bone). Then whenever it becomes desirable, one can replace the invisible object's mesh with the desirable hat's mesh, then make it visible. With my patch, the hat object would then continue to deform to the character's head regardless of which hat was currently being worn.
*note 1*
for armature/mesh deformations, the new mesh must have properly assigned vertex groups which match one or more of the bones of the target armature before the replaceMesh call is made. Otherwise the vertices won't react to the armature because they won't know how. (not sure if vertices can be scripted to change groups after the game has started)
*note 2*
The added processing time involved with replacing the object's deform controller is negligible.
|
|
So we should be all set now :)
Kent
--
mein@cs.umn.edu
|
|
(adding)
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
also the Makefile.in's were from previous patch adding
the system depend stuff to configure.ac
Kent
--
mein@cs.umn.edu
|
|
|
