Note that users should not be doing this anyway (and to some degree, I wish that they have to learn this the hard way - i.e. a crash as was before) since it is always bound to cause troubles of various sorts.
Having said this, the old tracking code was previously crashing if this sort of setup was created since a stack overflow would happen while bouncing between each object being recursively recalculated. I've fixed this by commenting out that recursive recalculation (solving the cyclic problems for n >= 2, while n=1 should still be fine without this pre-depsgraph hack), and also removing such cyclic dependencies in the n=2 case.
(PS: Perhaps this is just a good opportunity to just remove this old feature instead ;)
Render resolution set to 0 is correct in both of U and V cases
(if render resolution is set to 0 values from resolution_* will
be used while rendering)
Flatten handles option was an ugly mix of snap to nearest integer values and set the handles to have the same values as the key. Removed the nearest integer snapping from this, since it doesn't seem that useful in retrospect. It could be restored later if there's any demand for it.
* Added operator (Ctrl Shift Alt I) to show menu for changing the active Keying Set in the 3D view (todo item from last commit)
* KeyingSetInfo (i.e. the Builtin Keying Set classes) can now be accessed from Keying Set instances with ks.type_info
* Added ks.remove_all_paths() function to remove all the paths for a Keying Set.
---
These two changes mean that builtin Keying Sets could be refreshed in response to context changes by doing:
<code>
ks = bpy.context.scene.active_keying_set
if ks.absolute==False and ks.type_info:
ksi = ks.type_info
# remove existing paths to fill with new
ks.remove_all_paths()
# check if Keying Set can be used in current context
if ksi.poll(bpy.context):
# call iterator() which calls generate() and re-populates paths list
ksi.iterator(bpy.context, ks)
</code>
And then, once this has been done, the paths that the Keying Set will operate on can be accessed as
<code>
paths = bpy.context.scene.active_keying_set.paths
</code>
This commit restores fluid sim baking functionality in 2.5, it's been on the todo for
a while, and was previously almost completely non-functional. The old
code was quite complicated and specific to the 2.4 animation system, so I've
pretty much rewritten most of it.
This includes:
* Animated variables work again - just key them in the UI. Non-animateable values
should be already set non-animateable in RNA, hopefully I got them all.
Available are: Domain Gravity / Domain Viscosity / Object loc/rot/scale /
Object initial velocity / Deforming meshes / Fluid control Attract strength /
Fluid control Attract radius / Fluid control Velocity strength /
Fluid control Velocity radius / Object Active status (checkbox next to fluid type)
The Domain time scale is still not yet implemented.
* Fluid sim now use global scene units data by default - when enabled, the
scene's global gravity value is used and when units are set (metric/imperial)
the simulation real world size is taken from the object's actual measurements.
* The baking process is now done in the background, using the nifty threaded
Jobs system. It's non-blocking and your domain object will show the simulated
fluid as it becomes available for that frame.
A nice extra thing for the future would be to improve the visualisation of the
object's state while baking, and also the jobs system/ui could do with some
touchups - currently it has to share a bit from the 'render' job, and appears as
'Render' in the header. Progress bars for jobs in the header would be great too.
* Added 'id_name' property, which is used as the "typeinfo_name" by Keying Set instances. This is simply the name of the relevant KeyingSetInfo classes.
* Renamed the 'array_index' arg for ks.add_path() to 'index'. Also removed the 'entire array' toggle arg in favour of just passing -1 to index. However, Keying Sets in general still maintain their 'entire array' toggle flags for now, it's just that the API function does conversion between the two.
- was overwriting the selection flag
- also fixed mismatching prototype (own eek!)
Also added small update of MSVC 9 projectfiles (blendkernel/image_gen.c)
C functions and python used different argument order, this relied on mapping non-keyword arguments to 'REQUIRED' arguments but meant that you could not have an optional, non-keyword argument.
next commit will make order of arguments consistant (currently only changed order that rna wrapped).
(commit 27674 and 27683 by Campbell from render25 branch)
C functions and python used different argument order, this relied on mapping non-keyword arguments to 'REQUIRED' arguments but meant that you could not have an optional, non-keyword argument.
next commit will make order of arguments consistant (currently only changed order that rna wrapped).
(commit 27674 by Campbell from render25 branch)
Only source/blender/editors/ dir, should not give errors on different platforms
Only removing: UI_*.h, ED_*.h, WM_*.h, DNA_*.h, IMB_*.h, RNA_*.h, PIL_*.h
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
