Using custom setfuncs to avoid increase/decrease of usercount.
That way nothing stops you from removing a material that is used by a
sensor, or a mesh, an action ... (this is how 2.49 works too)
* also some general code cleaning/fix (adding static casts, replacing libaddr_us by lib_addr for dome text (I had no idea how user count worked back then)
this is also done in the 2 others places in the code which get the parent.
In our case the crash was caused by a group not containing the parent object.
- own mistake in scene help text.
- rename properties to have users as the prefix for better ordering.
- use fixed height for stamp, gives better aligned text.
* Disable openmp for dot product, this gives different results each
time due to non-commutative floating point add.
* Disable openmp with few vertices, the extra thread overhead only
slows things down then.
* Replace the hack that would divide stepsPerFrame and then set it
back, now it simply uses the timescale in the collision function.
This was incorrect because stepsPerFrame is an int, but we don't
want this to be rounded.
* Extra out of bounds check for hair velocity smoothing grid.
This fix the problem of not being able to play animations created with Blender 2.5 in BGE. Patch reviewed by Benoit
Added also other parent to modifier conversions as requested by Joshua (aligorith). I didn't bump subversion here, but the patch should work still. If not I'm increasing subversion sooner anyways (tomorrow or by the middle of the week I hope).
I was waiting to commit this one together with the Logic Editor datablock patch (converting material_name DNA properties to struct Material *). However my patch is getting too big and it's better if it's alone (easier to analyze later, eventual fixes, ...)
Mitchell, this commit adds a function that can help hardware skinning - HasArmatureDeformer()
- uses same thumbnail system as image browser
- blend files show thumbnails in ubuntu/gnome (freedesktop spec)
- 128x128 images are embedded into the blend file header, a simple loader avoids reading the entire blend file to extract it when generating thumbnails in the file selector.
When the image browser reads a directory it loads images and creates thumbnails, blend files embedded images are treated just like loading an image.
- the thumbnail is created from the camera view in solid mode. (no camera == no thumbnal).
- readfile/writefile.c: had to use the 'TEST' code name to save thumbnails, anything else would segfault older blender versions on load. (its not used elsewhere).
Adding documentation strings in argument data.
--help is auto generated (options not manually categorized end up in the "others" section at the bottom)
- fix implicit decloration of DAG_scene_sort()
- same fix for tiff as made in renderbranch
- rename 'combined peak' --> 'peak' for shorter messages while rendering.
* Keyboard Sensor entry keys (key, modifier 1 and 2) can actually be any key
- (you can use Shift as main key, and D as modifier if you want). It's
- strange in my opinion, but it's 2.49 way of doing it.
* Copy Game Property (operator found in SPACE menu)
- reorganized it so the properties appear as submenu items.
- a "little lot" of work for such a small eye-candie but well I hope more
- people like it as well :)
Matt, I had to recreate the dynamic_enum to make it work. I'm count on you
for a real fix for this ;)
- swapped meanting of -y/-Y to enable/disable automatic python execution (matches window border -w/-W).
- removed '-B', no reason to have this.
- renamed -fpe to --debug-fpe and added to --help
When enabled the context's 3D view will be used for rendering.
When disabled a camera view with solid draw mode will be used.
(Needed for batch rendering out animation previews without having to worry about an existing 3D view, its local layer locking and draw type)
Animators were having trouble selecting keyframes and their handles when zoomed in extremely. This commit seems to fix these issues, which appear to have resulted from some overflowing ints, which gave out-of-view handles priority quite often.
This works by tricking the depsgraph into giving us a smaller list of objects to evaluate, with all the necessary objects + their dependencies at the start of the list.
On any complicated setup where non-object parameters need to be referred to (i.e. by drivers) to affect an object's transform, these optimisations will fail and the old (slower) method is still the best way (modify the ifdef and comment out the optimise depsgraph call to do so). However, we'll assume that these aren't too common in real productions, so things should be fine with these fixes. If there really is a need for both, then global options to control these things could follow.
* Removed dynamic linking libTIFF code and change it to static linking
(built into the blender executable). Dynamic linking made things a
fair bit more complicated and wasn't working at all before on OS X -
the dylib didn't exist and wasn't being copied. Since TIFF is more heavily
depended upon now in Blender, it makes sense to make it less 'optional'
and more in line with other libraries.
I've updated both CMake and scons, and CMake on OS X/64bit works fine.
It's now up to other platform/build system maintainers to enable this for
their respective platforms (Campbell will check it for linux). For windows,
and non-64bit osx, we need static libtiff libraries in /lib.
I've added options WITH_TIFF for CMake and WITH_BF_TIFF for scons,
so if blender won't build because of this, you should be able to disable
these options until your build system has been updated.
* Bonus feature: while doing this, I added support for loading 16bit and 32bit
per channel TIFFs - they get converted to Blender's float buffers. Handy for
zbrush displacement maps!
- #22155: keyframe dots not shown on path for bone keyframes that aren't in a group with a matching name. Since this situation is going to become more common in 2.5, I've added an option which will alternatively just search the entire action to find all F-Curves associated with bones. The old option is still the default though for the general cases.
- When keyframe drawing is enabled, the current frame will also be indicated on the path now as a (bigger) green dot, as requested by William. This makes it easier to see the position on the path on the current frame.
