Used the engine's RemoveScene (which ultimately calls the converter's RemoveScene) instead of the converter's RemoveScene when the converter free a blend file. This handles the scene removal in a safer fashion and solves the crash described in part 2 of the bug report. Part 1 no longer appears to cause a crash.
KX_BlenderSceneConverter's destructor freed the contents of several std::vectors without removing those contents from the vectors. Later these vectors are iterated through. Making sure the vectors get cleared solves this problem.
Was a missing NULL-pointer check. No idea why it took so long to figure
issue out -- apparently there was no crash in linux for me and msvc
didn't show any backtrace :S
Also corrected weirdo way of bit flag check which was:
!ma->mode & MA_FACETEXTURE
better do !(ma->mode & MA_FACETEXTURE) since ! is a logic NOT.
Root of the issue was fixed by Brecht in svn rev56441.
This change only prevents crash of files created in
blender before that fix, and also gives more useable
information about what's wrong (apparently, assert
here was doing nothing).
This bug was producing way more geometry than we need. Potentially
memory saver (or performance even) bugfix.
Bottomline is:
We need to initialize the UVs otherwise vertex comparison fails ...
Ideally MoTo should take care of initializing MT_Point2
(note in Windows that seems to be fine, but it's safer to not rely on that)
* Undoing the previous applyMovement() changes for characters. This was causing bugs for the Motion Actuator.
* Creating a Character Motion type for the Motion Actuator with specific controls for characters. This includes moving, rotating and jumping.
* Adding a KX_CharacterWrapper.walkDirection to set the character's direction and speed.
Note, this also resolves the following bugs:
[#33585] "Setting dLoc of motion actuator [0,0,0] via python won't stop object" reported by Manuel Bellersen (urfoex)
[#33503] "Character physics type won´t accept more than one motion anymore" reported by Mr Larodos
The object color option in the materials always worked, however the initial color of the object
was never passed to the game.
We are now passing it only, only when the object's mesh has a material that has ((shade_flags & OB_COLOR)).
There reason to not always set the object color is probably due to performance (the m_bUseObjectColor
flag in KX_GameObject). This patch still respect that.
Bug report from Mike Pan, as part of our book nitty-gritties review work.
Bugfix during Vancouver Global Game Jam :)
As of r53332, give_current_material() won't accept a 0 index and return NULL. CreateMaterialFromBlenderObject() was using index 0 to just grab the first material. Since this now returned NULL, it would use default settings. We'll just ask for index 1 now instead.
Note: this doesn't work yet for everything with latest stable bullet (2.81), need to look into why and likely apply some patches upstream.
However I managed to link blender by disabling some features, likely it can be made to work without too much trouble.
