- check that an object has been created before setting the physics environment
- check that there is an active camera before using it
- when a camera is deleted, remove it from m_cameras list
rayCastTo(other,dist,prop)
Look towards another point/KX_GameObject and return first object hit within dist with a property that match prop, None if no object found or if it does not match prop.
Parameters:
other = 3-tuple (xyz coordinates) or object reference (target=center of object)
(type = list [x,y,z] or object reference)
dist = max distance of detection (can be negative => look behind)
If 0 or omitted => detect up to other
(type=float)
prop = property name that object must have
If empty or omitted => detect any object
(type=string)
This adds fractional FPS support to blender and should finally
make NTSC work correctly.
NTSC has an FPS of 30.0/1.001 which is approximately 29.97 FPS.
Therefore, it is not enough to simply make frs_sec a float, since
you can't represent this accurately enough.
I added a seperate variable frs_sec_base and FPS is now
frs_sec / frs_sec_base.
I changed all the places, where frs_sec was used to my best knowledge.
For convenience sake, I added several macros, that should make life
easier in the future:
FRA2TIME(a) : convert frame number to a double precision time in seconds
TIME2FRA(a) : the same in the opposite direction
FPS : return current FPS as a double precision number
(last resort)
This closes bug #6715
Standard framerates not supported / breaks sync -- 23.967 29.967 etc.
https://projects.blender.org/tracker/?func=detail&aid=6715&group_id=9&atid=125
Please give this heavy testing with NTSC files, quicktime in/export
and the python interface.
Errors are most probably only spotted on longer timelines, so that is
also important.
The patch was tested by Troy Sobotka and me, so it most probably should
work out of the box, but wider testing is important, since errors are
very subtle.
Enjoy!
using mface->flag for both.
Also found that the cdDM_drawMappedFaces and cdDM_drawFacesTex_common could get normals mixed up when rendering hidden faces. because hidden/invisible faces used continue without advancing to the next normal.
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.
