Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2012-05-06style cleanup: blenkernelCampbell Barton
2012-05-06code cleanup: naming - BKE_mesh_*Campbell Barton
2012-05-05code cleanup: BKE_ naming, also make bpy.data.images.load() always load a ↵Campbell Barton
new image. (not use existing one)
2012-05-05code cleanup: BKE_scene api naming.Campbell Barton
also stop numpy from being found in /usr/include with cmake.
2012-05-05code cleanup: function naming, use BKE_*type* prefix.Campbell Barton
2012-05-01Motion Paths GUI CleanupJoshua Leung
This commit refactors the way that the Motion Paths GUI works. The key problems this tries to address are: 1) Mode error - Confusion about whether we're dealing with the Object or Pose level Motion Paths panel 2) Display settings vs Baking Settings In line with the original design intentions for the 2.5/6 Properties Editor, I've now split out the actual baking-related settings away from the Properties Editor: * Now, when clicking "Calculate Paths" from the toolbar, you'll be prompted with a dialog to select the start/end frames (and for bones, whether to bake from heads or tails). This is less confusing than relying on firstly setting the range via the display range settings (and baking using that), since many people apparently only used the "around current" mode, and were confused why things weren't working * Added a display of the frame ranges of the current baked Motion Path on the active Object/Bone. This makes it clearer/easier to debug if the path suddenly starts disappearing after a certain frame. * Replaced Calculate/Clear Paths in the panels with a single "Update" button if there's already a baked Motion Path. Hopefully these changes (in combination with some of the other bugfixes) will make it more obvious how everything works.
2012-05-01Bugfix [#30097] Motion paths range not correct - Part B (Recalculating existingJoshua Leung
paths with new ranges) If an object/bone already had a motion path, it was not possible to recalculate it over a different frame range without firstly clearing these paths. This was both a confusing and troublesome workflow, and has since been removed.
2012-04-29style cleanup: whitespace / commasCampbell Barton
2012-04-28Code and style cleanup in own modules in BKE and also mball moduleSergey Sharybin
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks) - Make functions which are used by mball.c only static and remove their prototypes from public header file. Further cleanup is coming.
2012-04-28style cleanup: changes to brace placement / newlines - for/while/if/switchCampbell Barton
2012-04-21style cleanupCampbell Barton
2012-04-20Fix for particle dupli group relative offsets. The relative transforms of ↵Lukas Toenne
objects in the instanced group were not scaled according to the particle size, which would be expected when rendering as 'Whole Group'. Requested by Francesco Siddi (fsiddi) over IRC.
2012-04-09use 'const float[3]' for derived mesh callback args.Campbell Barton
2012-03-24style cleanup: follow style guide for formatting of if/for/while loops, and ↵Campbell Barton
else if's
2012-03-24style cleanup: mainly for mesh code, also some WM function use.Campbell Barton
2012-03-04style cleanup / comment formatting for bli/bke/bmeshCampbell Barton
2012-03-03style cleanup - spelling corrections & update some incorrect comments.Campbell Barton
2012-03-02style cleanupCampbell Barton
- spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-01Spelling CleanupCampbell Barton
2012-02-27style cleanup (mostly whitespace)Campbell Barton
2012-02-20- remove some unused editmesh functions.Campbell Barton
- copy & rename EditMesh stricts for use with scanfill (remove unused members)
2012-02-01svn merge ^/trunk/blender -r43751:43819, need to look into changes made to ↵Campbell Barton
editmesh_loop.c from this range still
2012-02-01minor cleanup made while looking into bug report (having vector size in ↵Campbell Barton
comments is silly, may as well have in declaration)
2011-12-17use 2d copy functions with UV's in more places.Campbell Barton
2011-12-17svn merge ^/trunk/blender -r42669:42670Campbell Barton
2011-12-16Math lib: matrix multiplication order fix for two functions that wereBrecht Van Lommel
inconsistent with similar functions & math notation: mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B) mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B) For branch maintainers, it should be relatively simple to fix things manually, it's also possible run this script after merging to do automatic replacement: http://www.pasteall.org/27459/python
2011-11-30svn merge ^/trunk/blender -r42261:42290Campbell Barton
2011-11-30fix for parenting bug introduced by own commit r42273, adding dummy object ↵Campbell Barton
didnt initialize delta vectors. also remove redundant NULL initializers, where the value is initialized immediately after.
2011-11-29More DM func renames, this one includes renames of the function pointer ↵Andrew Wiggin
members of the DerivedMesh struct
2011-11-29svn merge ^/trunk/blender -r42221:42245Campbell Barton
2011-11-29avoid allocating verts & faces for dupliface + editmode.Campbell Barton
2011-11-29fix for duplifaces with quads/ngons, bmesh was using triangulated faces so ↵Campbell Barton
each quad would result in 2 duplis.
2011-11-15svn merge -r41751:41779 ^/trunk/blenderCampbell Barton
2011-11-12Bugfix [#29125] Motion paths odd behaviourJoshua Leung
* Made it impossible to try to calculate/create new motion paths lasting 0 frames (i.e. 250 to 250) since we cannot allocate a zero-length array for these. Start frame can now be at most end-frame - 1, and end frame at least start frame + 1 * If an invalid configuration does occur, warnings/reports will now be issued in response to this instead of silently failing (as per this bugreport).
2011-11-06svn merge ^/trunk/blender -r41503:41575Campbell Barton
2011-11-06Removed old "bsystem_time()" function, which by now is just aJoshua Leung
duplicate of BKE_curframe() which just takes two extra args. For the few calls in the physics engine where CFRA+1 instead of CFRA was being used, I've added a new BKE_nextframe() call, which will calculate for CFRA+1 instead of CFRA in much the same way that bsystem_time() would end up doing things (which means including subframe steps).
2011-11-04Bugfix [#28515] Dupliframes start/end animation broken since 2.56AJoshua Leung
Due to changes with the way that dupliframes were being evaluated (one of those being that the animation for the object being animated would get reevaluated for every frame sample for dupliframes) to get them working properly again sometime during the 2.5 series, the dupliframe- sampling loop would be prematurely terminated on the first frame in this example. That is because after the first step of the loop, the ob->dupend property would have changed its value as it was being animated, leading to the loop terminating, and only the a single dupli getting added.
2011-10-28svn merge -r41329:41335 ^/trunk/blenderCampbell Barton
2011-10-28replace VECCOPY and QUATCOPY with inline funcs.Campbell Barton
2011-10-24svn merge ^/trunk/blender -r41226:41227 .Campbell Barton
2011-10-23remove $Id: tags after discussion on the mailign list: ↵Campbell Barton
http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-17svn merge ^/trunk/blender -r41005:41075Campbell Barton
2011-10-16Particle dupliobject rotation changes:Janne Karhu
There has been quite a bit of fuss about particle dupliobject rotation in 2.59, so here are some changes to make things work a bit more consistently and predictably in 2.60. Much of the confusion has been about what the "Initial rotation" for particles actually means. Simply put it's just a vector that that the particles (and the dupliobjects) are aligned to and around which they can be rotated with the phase controls. I've now renamed these controls under a label "Rotation axis". In 2.59 and previous versions the dupliobject's global x-axis was aligned to the particle rotation axis for non-hair particles. This meant that the object's own rotation (in addition to the particle rotation) could effect the dupliobjects' rotations. This old behavior can still be used with the "Rotation" option in the particle render panel when object/group is set as the visualization. This option is also activated automatically for old files to maintain backwards compatibility. Now the default dupliobject rotations ignore the object's own rotation completely and align the object's tracking axis to the particle rotation axis. The tracking axis can be found under the Object tab -> Animation Hacks panel. In 2.58 the way of calculating the rotation for hair didn't work as intended and enabled many non-functional combinations of options. For this reason I removed most of the rotation options for hair in 2.59. Now the options have been reimplemented better and the dupliobject's tracking axis is aligned to the hair direction by default (Rotation axis = Velocity / Hair). All the other axis options work too along with the phase controls.
2011-10-14svn merge ^/trunk/blender -r40890:40950Campbell Barton
2011-10-10fix bad svn ID tagsCampbell Barton
2011-10-10header cleanup (no functional changes)Campbell Barton
2011-10-09svn merge ^/trunk/blender -r40720:40872Campbell Barton
2011-10-08fix [#28846] Relative paths on linked scene failsCampbell Barton
2011-09-17svn merge -r40166:40279 ^/trunk/blenderCampbell Barton
2011-09-16replace macros with math lib functionsCampbell Barton