It was lag of optimization logic, which always retuns object's derivedMesh
if one of of boolean operation's meshes has got no faces.
Actually, result depends on operation and which mesh has got no faces.
Added small utility function to handle this.
Do not indent if there's any non-space character after colon.
This only makes life a bit easier, but it's still not 100% correct indentation
strategy. For example when colon is inside non-closed string or so.
Also there's not indentation for { and un-indentation for }.
Handling such cases would require much smarter strategy..
This was caused because a small part of sculpt's radial control code did not make it into the new version. The old code would set a new object-space size by scaling it proportional to how much the new screen-space size was changed.
The solution I implement here is to do the same scaling inside the RNA callbacks. This way, users of those properties do not have to worry about inconsistency.
I added a comment warning that brush_set_size, brush_set_unified_size, brush_unprojected_radius, and brush_set_unprojected_radius do not guarantee consistency because it is not always possible to precisely know what the new unprojected radius is in all contexts where you might set the size.
I would implement the consistency check at the lower level (in those listed functions) but at this time I think it needs to be looked at to make sure that won't cause problems. In addition, I am not sure that scaling by the ratio of change is strictly correct in all cases.
In any case, this at least fixes the immediate problem.
[the problem also affected OSX]
PhysicsId are Long, not ints (see PyObject* KX_GameObject::PyGetPhysicsId() )
There is a reference in the code to use PyCapsule instead of int. I'm not sure
about that. This patch at least stops the crashes
(update: I talked with Campbell and he repeated that PyCapsule are better, but if long is working it's fine for now).
Revert of "SVN commit: /data/svn/bf-blender [36957]
trunk/blender/source/gameengine/ VideoTexture/VideoFFmpeg.cpp: fix for
ffmpeg linking in BGE ( patch by Jens Verwiebe (jensverwiebe) over IRC)"
Sorry folks, that patch breaks current ffmpeg GIT version.
Good news: it's all handled now automagically by ffmpeg_compat.h in
intern/ffmpeg
so: everything should be fine and dandy for very old and very new versions.
Added central compatibility header file, which enables blender to compile
against very old ffmpeg versions as well as very new versions using the
*NEW* API. (Old API functions are simulated using macros and inline functions)
Added a whole lot of additional checks, tested against 6 different versions
down the timeline, hopefully, now finally all is well.
fixed frame colors for letterbox drawing (happens when in camera view).
Cause is unclear, seems some sort of strange graphics driver thing on 32 bit.
Changes are a fix for the incorrect usage of glViewport, and avoiding the extra
clear if it's not needed.
* Windows installer not working for non-admin users and multiple users
* Addon scripts not installing next to user configuration
* Portable install not being taken into account in all places
The main problem was the windows installer was installing system scripts in
AppData next to the user configuration directory, which is not shared between
users. Now these are installed in ProgramFiles, and only addon scripts added
by the users go to AppData.
On all platforms, addon scripts were sometimes getting installed between
system scripts, because the scripts folder in the executable directory was
given precedence over the user configuration folder, that is no longer done
now. So addons now behave like user configuration, they are preserved even
if you download a newer build of the same blender version.
If you have an installation of 2.57 on windows, the addon install location
will not change until we do the version bump to 2.58, to avoid conflicts with
the existing the installed 2.57 version.
The old behavior of giving precedence to the local folder was done to support
portable install, where all configuration is written to the local folder. This
is now implemented differently: if and only if a "config" folder exists in the
local folder, portable install will be assumed, and files will only be written
to that local folder.
Added some API compatibility code again, since some API-changes weren't even documented
(they even didn't do a proper version-bump, arghh!)
If it breaks again, please tell!
* removed a lot of old cruft code for ancient ffmpeg versions
* made it compile again against latest ffmpeg / libav GIT
(also shouldn't break distro ffmpegs, since those API changes
have been introduced over a year ago. If it nevertheless breaks,
please send me an email)
In the case of this bug e.g. material.new became MATERiAL_OT_new, due to
different capitalization of "i" in Turkish. Fixed by not using the locale
dependent toupper/tolower functions.
