copy system with rigidbody constraint will link new constraints to new objects (instead of old)
fps from blender will be used when baking (left shift/ctrl/alt + P)
- GEdon't crash when attempting to add constraint on game objects without physics controller
- GEimproved some physics -> graphics synchronization issues
- small experiment with game engine timing to smooth framerate/reduce tearing
Although we will delay the main Rigid Body user interface after 2.43 release early 2007, I need some constraint data/UI to make progress with COLLADA Physics.
Added RigidBody constraint UI
LR_ALTKEY+LR_CTRLKEY+LR_SHIFTKEY+ P will bake rigidbody
Contribution by RCRuiz, Ramon Carlos.
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
remove constraint fixed,
Bullet timestep now subdivides Blender game engine timestep, so it runs 60 hertz,
SphereShape reverted to old style, so no support for non-uniform scaled spheres for now,
Armatures are back
Split screen
Double sided lightning
Ambient lighting
Alpha test
Material IPO support (one per object atm)
Blender materials
GLSL shaders - Python access
Up to three texture samplers from the material panel ( 2D & Cube map )
Python access to a second set of uv coordinates
See http://www.elysiun.com/forum/viewtopic.php?t=58057
including implementation. hope it works, and doesn't break to much.
it bakes physics objects transform into ipo, every frame of the running gameengine.
When you disable and run the game again, it clears the ipo's again. just for physics objects at the moment.
(perhaps some better UI in the future?)
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.
Depth sorting for Transparent polygons. Use ZTransp in Material buttons to enable.
This will cause an object's polygons to be sorted (back to front for alpha polygons, front to back for solid polygons.)
Consider:
gameobj->getClientInfo()->m_auxilary_info = (matname ? (void*)(matname+2) : NULL);
It works if matname is "MAblah", but not if matname is "".
2. Added constructor for struct RAS_CameraData.
3. Added initializers to the struct KX_ClientObjectInfo constructor
4. Collision sensors won't detect near sensors.
5. A stack of minor tweaks, adjusting whitespace, using ++it for stl stuff.
[SCons] Build with Solid as default when enabling the gameengine in the build process
[SCons] Build solid and qhull from the extern directory and link statically against them
That was about it.
There are a few things that needs double checking:
* Makefiles
* Projectfiles
* All the other systems than Linux and Windows on which the build (with scons) has been successfully tested.
(MVert,MFace,etc) off into DNA_meshdata_types.h, to isolate areas
of source that actually edit mesh *data* vs. areas that just edit
mesh object information.
