I also did some small tweaks. removed ifdef's for pluginapi
didn't need them there.
Fixed it so the filesel shows jp2 as image files.
(I'm going to do makefiles next)
Kent
The multi-thread cache service is activated only on multi-core processors.
It consists in loading, decoding and caching the video frames in a
separate thread. The cache size is 5 decoded frames and 30 raw frames.
Note that the opening of video file/stream/camera is not multi-thread:
you will still experience a delay at the VideoFFmpeg object creation.
Processing of the video frame (resize, loading to texture) is still done
in the main thread. Caching is automatically enabled for video file,
video streaming and video camera.
Video streaming now works correctly: the videos frames are loaded
at the correct rate. Network delays and frequency drifts are automatically
compensated.
Note: an http video source is always treated as a streaming source,
even though the http protocol allows seeking. For the user it means that
he cannot define start/stop range and cannot restart the video except
by reopening the source. Pause/play is however possible.
Video camera is now correctly handled on Linux: it will not slow down the BGE.
A video camera is treated as a streaming source.
In particular, the Bullet vehicle seems broken, and some soft-body demos don't work.
No new features or benefits are added yet, but a few improvements are planned before Blender 2.49 release.
Please update the build systems, and add those 3 files:
extern/bullet2/src/BulletCollision/CollisionDispatch/btActivatingCollisionAlgorithm.cpp
extern/bullet2/src/BulletCollision/CollisionDispatch/btGhostObject.cpp
extern/bullet2/src/BulletCollision/CollisionShapes/btConvexPointCloudShape.cpp
I'll watch the Blender mailing list, in case this commit causes some issues.
btPoint3 has been deprecated, it was already a typedef to btVector3
replace std::vector by btAlignedObjectArray when storing Bullet objects, because MSVC STL implementation has some bugs, preventing to contain aligned objects
(btVector3 is 16-byte aligned, to allow SIMD)
Python dir(ob) for game types now includes attributes names,
* Use "__dict__" rather then "__methods__" attribute to be Python 3.0 compatible
* Added _getattr_dict() for getting the method and attribute names from a PyObject, rather then building it in the macro.
* Added place holder *::Attribute array, needed for the _getattr_up macro.
Removed a check in Python API touch.setProperty() for the property name on the sensor owner before allowing the name to be set - it makes no sense and isnt checked when creating the sensor.
- SCA_DelaySensor.py indent error making epydoc fail.
Previously only the first collision would trigger an event (no collisions a negative event ofcourse)
With the Pulse option enabled, any change to the set of colliding objects will trigger an event.
Added this because there was no way to count how many sheep were on a platform in YoFrankie without running a script periodically.
Changes in collision are detected by comparing the number of objects colliding with the last event, as well as a hash made from the object pointers.
Also changed the touch sensors internal list of colliding objects to only contain objects that match the property or material.
- pulse isnt a great name, could change this.
* Where possible use vec.setValue(x,y,z) to assign values to a vector instead of vec= MT_Vector3(x,y,z), for MT_Point and MT_Matrix types too.
* Comparing TexVerts was creating 10 MT_Vector types - instead compare as floats.
* Added SG_Spatial::SetWorldFromLocalTransform() since the local transform is use for world transform in some cases.
* removed some unneeded vars from UpdateChildCoordinates functions
* Py API - Mouse, Ray, Radar sensors - use PyObjectFrom(vec) rather then filling the lists in each function. Use METH_NOARGS for get*() functions.
- variables that shadow vers declared earlier
- Py_Fatal print an error to the stderr
- gcc was complaining about the order of initialized vars (for classes)
- const return values for ints and bools didnt do anything.
- braces for ambiguous if statements
This was committed in revision 2832 but never accounted for existing object name hashes which existed since revision 2.
Its possible to update the names elsewhere but unlikely anyone ever used this successfully so removing.
* Made GameLogic.addActiveActuator(actu, bool) to raise an error if the actuator is not in the list. Before it would allow any value as the actuator and fail silently (makes debugging scripts more difficult).
* Allow the actuator to be a string which is convenient if you dont want to change the settings of the actuator.
* Added activate/deactivate functions to the controller, this is more logical since the GameLogic.addActiveActuator() function is running through the controller anyway.
GameLogic.addActiveActuator(controller.getActuator("SomeAct"), True)
...can be replaced with...
controller.activate("SomeAct")
* fixed segfaults in CListValue.index(val) and CListValue.count(val) when the pyTypes could not be converted into a CValue.
* added scene.objects to replace scene.getObjectList()
* added function names to PyArg_ParseTuple() so errors will include the function names
* removed cases of PyArg_ParseTuple(args,"O",&pyobj) where METH_O ensures a single argument.
* Made PyObjectFrom use ugly python api rather then Py_BuildValue(), approx %40 speedup for functions that return Python vector and matrix types like ob.orientation.
* I accidently broke the scons bit by chopping the node libs into pieces. I forgot that trunk hasn't had the nice scons cleanout I did in Blender 2.5 branch. Now everything should compile again.
It took a while because I tried to quickly do the same cleanup, but src/ is just not cooperating, neither is stock mingw (no @commands.txt tempfilemunge goodies)
particleInstanceModifier_applyModifier uses getVertCo,which is not implemented by ccgDM.
getVertCo was used to simply perform a min/max, so it was fixed to use the apropriate min/max
dm->getMinMax(dm, min_r, max_r);
Maybe the fact ccgDM doesn't implements getVertCo/getVertNo is a bug, since it implements every
other DM function and its strange those are left out.
Without thread locking the function that allocates new threads, black dots appear in renders.
This wont affect composite nodes,
Ton/Brecht - this is possibly too many lock/unlocks but I timed the render from the bug report and it didn't make a noticeable difference.
