* Horrors from the ancient world of deprecated code: object animation offset can't really work correctly with particles unless point cache takes full control of particle system timing.
* Disabled the non-working offset control from effecting particles so that for now particles will work consistently and the offset is only applied to the object.
didn't perform updates
* This problem was caused by a typo when adapting old code
* Fixed crash where keyframes-update was being called in Grease Pencil
transforms too
Todo:
Outliner/Datablocks Viewer doesn't update that nicely when these
keyframes get modified. Outside of gdb, I managed to get a few non-
repeatable crashes here; while debugging though, there was only some
lagging oddness if panning before the tree updated.
===== Situation before this patch =====
in the current situation inside the node editor there is a properties panel (press 'n'-key). This pabel displays some information about the node, backdrop and grease pencil. The UI of the property panel is typically vertical oriented. Nodes in the other hand are not oriented in a direction. Both area's are draw via the same draw function.
With some nodes this will create not user-friendly UI. Try the color-balance for instance). The 3 color circles are drawn next to each other, it would be better to draw them below each other.
When creating more complex nodes you don't want to display all handles in the node-panel and in the properties panel. For instance fine-tuning handles you only want to appear in the property panel to reduce place in the node itself.
===== Situation after this patch =====
This patch separates the draw functions of the property panel and the node panel.
When no special draw function is created for the property panel, the draw function of the node will be used as 'fallback'
===== Impact =====
==== BKE_node.h ====
add a new uifunc (called uifuncbut) to the bNodeType struct. The definition is the same as the uifunc.
==== node_buttons.c ====
if the uifuncbut is set, call it. currently calls the uifunc method
==== drawnode.c ====
static void node_composit_set_butfunc(bNodeType *ntype). set the uifuncbut function where needed. When at the end of the method uifuncbut is still empty, set uifuncbut to the uifunc.
===== Final note =====
! PS. this is not limited to the compositor it also works for Materials and Textures !
! PPS. For other branching creating their own node-tree. Please make sure that your uifuncbut is set NULL or a valid draw function !
A mesh can consist out of multiple material. Take a character with clothing's. the skin can be a different material as the different clothing's. During compositing it is a common use-case to only do a part of the composit on only a specific material. Currently this can not be done.
In blender movies this feature is known to be implemented, but until now it never got integrated into trunk.
Proposal
With material index the Blender internal renderer will be capable of creating a buffer containing the material indexes of the first pixel-hit. This will be implemented in the same manner as the object index.
In the compositor the ID Mask node can be used to extract the information out of the Render pass.
Impact
User interface
On the properties-space the next changes will be done
Scene⇒Render layer⇒Passes⇒Material index will be added
Material⇒Options⇒Pass index will be added
DNA
Material struct will get an new field called “index”. this will be a short-type.
Material struct the field pad will be removed.
A new Render-layer pass will be added (bit 1«18)
RNA
Material RNA is updated (based on “pass index” from object)
Render layer RNA is updated (based on IndexOB)
Blender internal renderer
The Blender internal renderer will process the render pass as a copy of the Object index.
Blender compositor
The render layer input will get a new output socket called “IndexMA”
Usage
An example on how to use material index can be found at:
https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/compositing/composite_materialindex.blend
This is also example of a commit message longer than the commit itself :)
The manipulator was always using vertex selection flags, but those are only
valid in vertex mode, as selection flag flushing only happens in the direction
vertex -> edge -> face. Now use edge/face selection flags when needed.
Original patch by Jan Diederich, adapted by Pelle Johnsen. Review assistance by Daniel Tavares.
This patch adds an option to export only the selection.
It is now possible to create "scripted expression" drivers by simply
clicking on some property, and typing some short Python expression
prefixed with a '#'. This will result in a scripted expression driver,
with the typed-in text being created.
For example, you can click on X-Location of the default cube, and
type:
#sin(frame)
and a new driver will be created for the x-location of the cube. This
will use the current frame value, and modulate this with a sine wave.
Do note though, that the current frame is a special case here. In the
current implementation, a special "frame" driver variable, which
references the current scene frame is created automatically, so that
this simple and (assumed) common case will work straight out of the
box.
Future improvements:
- Explore possibilities of semi-automated extraction of variables from
such expressions, resulting in automated variable extraction. (Doing
away with variables completely is definitely 100% off the agenda
though)
- Look into some ways of defining some shorthands for referencing
local data (possibly related to variable extraction?)
* macro ABS has no effect with uintptr_t anyway and was throwing warning (promoted to error) -> commented out and marked with TODO
* removed two unused variables trhowing warning also promoted to error when compiling.
Objects with drivers are now treated as needing updates when the
current frame changes. This assumption has been documented in the
code, and should at least mean that users who try to use drivers for
creating simple time-based expressions that this should work.
Note:
- It is still recommended to create a "cfra" driver variable instead
of actually inlining bpy.context.scene.frame_current into the
expressions. Not only does the latter look rather nasty to type/have
in the expression, but it is also less future-proof for when I get
around to actually working on a beefed-up depsgraph (nothing official
on that front yet...)
