As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading.
To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py).
There are a number of additional features that become possible with this implementation:
1) Node Toolbar can be populated!
The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible.
2) Each node item is a true operator call.
The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes.
3) Node Items support additional settings.
Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C.
4) Node items can be generated with a function.
A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image.
WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
* Fix precision overflow issue with overlay previews,
* Expose alpha mask mapping to UI (still not functional but coming soon).
* More overlay refactoring:
Overlay now does minimal checking for texture refresh.
Instead, we now have invalidation flags to set an aspect of the brush
overlay as invalid. This is necessary because this way we will be able to
separate and preview different brush attributes on the overlays, using
different textures:
These attributes/aspects are:
Primary texture (main texture for sculpt, vertex, imapaint)
Secondary texture (mask/alpha texture for imapaint)
Cursor texture (cursor texture. It involves brush strength and curves)
Modified the relevant RNA property update functions and C update callback
functions to call the relevant cursor invalidation functions instead
of checking every frame for multiple properties.
Properties that affect this are:
Image changes, if image is used by current brush,
Texture slot changes, similarly
Curve changes,
Object mode change invalidates the cursor
Paint tool change invalidates the cursor.
These changes give slightly more invalidation cases than simply
comparing the relevant properties each frame, but these do not occur in
performance critical moments and it's a much more elegant system than
adding more variables to check per frame each time we add something on
the system.
- Add and subtract effects will now affect on only RGB channels,
and alpha of first input is used as an alpha for the result.
Also solved creepyness with straight->premul->straight conversion
in byte versions of add/subtract.
- Solved issue with multiply modifier, which lead to white*white
not being white (was off by 1.0/255) due to wrong optimization
of division by 255 with shr by 8.
According to Ton this issue goes back to 2000!
This fixes#34811: Wrong result of add/subtract effects
- Nearest interpolation was always used when there's
no rotation for stabilization. Was a failure of
optimization heuristic.
- Made 2d stabilization frame acquiring threaded.
This function is only used for display and sequencer
which will only benefit of threads here.
- Fixed bug introduced in r48749 which lead to
re-making stable frame on every redraw.
Since we use the rigid body transform when transforming rigid bodies
things like parents and constraints add an offset because rigid body
transforms are in global space.
Now we just don't take rigid body transform into account on simulation
start frame so there are no problems when doing the initial setup.
The problem still exists when simulation is running of course.
To properly fix this we'd have to solve parenting and constratins while
taking rigid bodies into account before and after transform.
We'll have to see if it's really needed, would like to avoid it though.
This commit is the first part of a two-part merger of the soc-2008-mxcurioni
(Freestyle) branch. New 'freestyle' folders were added to the source/blender/
and release/script/ directories through a couple of svn copy operations
(instead of svn merge, due to broken svn:mergeinfo properties of the branch).
This made preview working but that broke internals
of tracking.
Namely, BlurredImageAndDerivativesChannels is giving
much more blurred image because it was assuming pixel
center is an integer position.
Guess other parts of libmv used to suffer because of
this issue.
Now pixel centering happens in blender side, and
libmv assumes integer position is a pixel center.
Deprecated Freestyle-specific elements were removed from the code base,
in order to address all comments from branch code reviews.
https://codereview.appspot.com/7416049/
Backward compatibility won't be maintained in the following components:
- Freestyle edge/face marks in old .blend files are ignored.
Old .blend files can be converted by loading and saving the files using
a Freestyle branch build between revision 55581 and 55842.
- External style modules are no longer supported.
Instead text datablocks must be used to keep style module files within
.blend files. A branch build between revision 55741 and 55842 is useful
for identifying the style module file names that need reconfiguring.
The removed code was necessary due to a logical bug in the use of CD_ORIGINDEX
layer entries. Previously the index values were used to refer to the edges/polys
of the derived mesh, assuming that the derived mesh edges/polys consisted of those
from the original mesh plus newly added edges/polys. This assumption was not
correct, although it worked well for several modifiers such as Mirror and Solidify.
Now the index values are specifically used to reference the edge/polys of the
original mesh.
modifiers with text/curve/surface objects.
This is because the code here did not yet support the distinction between
generating the tesselated mesh at viewport/render resolution and generating a
separate displist/derivedmesh for render that is not stored in the object but
created and freed on the fly.
- When changing clip in clip editor, remove all frames
from it's cache to free memory for new clip.
- When changing proxy render settings, free cache as well.
Made it an operator instead of automatic prefetching.
Filling the whole memory with frames is not always
desired behavior.
Now prefetching is available via P-key, or from Clip
panel in toolbox or from Clip menu.
Also enabled prefetching for non-proxied movies.
Suggested by Brecht Van Lommel and Campbell Barton through code review comments.
Previously style modules were external Python script files whose absolute paths
were kept in .blend files. Now style modules are stored in .blend files as text
datablocks.
Style modules are configured in three steps:
1. Open an external style module file (or create a new text datablock) in the
Text Editor in Blender.
2. Add a style module to the list of style modules (by pressing the "Add" button)
in the Render Layer properties window.
3. Click the name entry and select the style module from the drop-down menu.
The Scopes and Histogram (Image editor, Sequencer) were not updating on
changes in color or display settings.
- Missing notifiers for refreshing
- Missing code to draw correct for managed byte buffers.
Added a sanity check to the ED_node_link_insert function to ensure it exits gracefully if no suitable sockets can be found. This was the problem with custom pynodes, which don't define the 'type' DNA of old sockets. The operator will have to be generalized for future nodes, but for now just not crashing seems good enough.
Script node crashes in #34810 were caused by uninitialized 'type' integer as well. This is now done in the set_typeinfo function for sockets (like for trees and nodes too), to avoid any potential remaining issues of this kind. Note that new files need to be loaded and saved again once to be forward compatible again.
well as I would like, but it works, just add a subsurface scattering node and
you can use it like any other BSDF.
It is using fully raytraced sampling compatible with progressive rendering
and other more advanced rendering algorithms we might used in the future, and
it uses no extra memory so it's suitable for complex scenes.
Disadvantage is that it can be quite noisy and slow. Two limitations that will
be solved are that it does not work with bump mapping yet, and that the falloff
function used is a simple cubic function, it's not using the real BSSRDF
falloff function yet.
The node has a color input, along with a scattering radius for each RGB color
channel along with an overall scale factor for the radii.
There is also no GPU support yet, will test if I can get that working later.
Node Documentation:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF
Implementation notes:
http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
