The “Frame” node has been in trunk for a few months now, but it is still in a somewhat unfinished state. So i’ve made a few additions that will make this node a lot more useful for organizing node layout. Thanks to Sebastian König for feedback and testing!
The general idea is that the Frame node can complement the already present Group nodes. Node groups are in fact separate data blocks, linked into a node tree by the node group (so the term “group” is a bit misleading: the internal nodes are completely separate from the surrounding nodes). The frame nodes on the other hand are really just a way of grouping nodes inside the same tree, without the need for additional interfaces.

Oh, and btw: We should change the name of this thing! “Frame” usually has a different meaning in Blender, but i still don’t have a convincing alternative … Time to get creative!

NOTE: I will upload the patch to the codereview tool soon, for now here is a simple pasteall.org link if you want to try it out:

http://www.pasteall.org/31531/diff

NOTE 2: The patch is now submitted to the code review tool:

http://codereview.appspot.com/6200062/

Potential changes before trunk merge will be uploaded there as well.

Frame Node Bounding Boxes

Frame nodes now behave as Bounding Boxes around the attached nodes. When moving a child node of a frame, the size will update automatically to make sure it is big enough for all children.

Shrinking bounding box

Frame nodes have an optional Shrink setting (accessible in the sidebar), which ensures that the bounding box is of minimal size. If disabled the frame will not change size when children are moved closer together.

Shrinking disabled

Improved Node Resizing

Resizing nodes now has immediate visual feedback in the form of changing mouse cursors. When hovering the mouse over the border of a node, the cursor changes to indicate the possible directions in which a node border can be dragged.

Previously node borders could only be grabbed at the lower right corner. This was in fact restricted to resizing the node width, so having the resize widget in the corner is misleading (indicating a possible resize of height too). Any change of height is in fact purely automatic (for regular nodes), caused by resizing the preview with constant aspect ratio. Node borders can now be grabbed at both the left and right size instead for horizontal resizing.

New resize behavior

Manual resizing of frame nodes only works if the Shrink option is disabled. Otherwise the frame size is determined fully automatic by the placement of child nodes. Unlike regular nodes, frame nodes can then also be resized in the vertical direction from both top and bottom border.

Manually resizing a frame

New Operators for Managing Frame Nodes

The frame node basically implements a parent/child relationship similar to that found in objects: The frame acts as the parent node for all attached children (including other frames). When moving the parent, the children move with it (transform hierarchy).

For changing this hierarchy a number operators and tools have been implemented:

Similar to object parenting, nodes can be attached and released from frames with directly operators:

• CTRL+p attaches a node to the active frame. The last selected (=active) node has to be a frame node.
• ALT+p releases a node from it’s current parent.

Attach to frame by dragging onto it

In addition, nodes can also be attached and released more conveniently using mouse dragging:

• Moving any number of nodes onto a frame (i.e. mouse cursor is over the frame when confirming) attaches them to the frame.
• ALT+f releases a node from it’s parent (like ALT+p) and immediately starts the modal transform operator
  Note: We tried implementing a grabbing variant for this (grab+modifier key), but there is just no unused working combination left in the keymap …

Similar to Node Groups there are also ways to create new frames around a selection of nodes:

• ALT+j creates a new frame around the selected nodes (like ALT+g for creating a group)
• “ungrouping” can be done by simply deleting a frame node. All immediate child nodes are then released.

Theme Colors for Node Selection

Previously the active node and selected nodes were indicated using the “Text Highlight” theme color for both. Now this has been replaced by dedicated theme colors for the active node and for selection respectively, to allow better visual distinction of the selection state.

Funky theme colors (just for show)

Custom Node Colors

Nodes can now have an optional custom color displayed on their “body” part (that is, the node background except the header bar and the outline). This is meant to be used primarily in combination with frame nodes, as a way to visually separate different sections of a node tree.

The colors have a preset system, like the one already in place for tracks in the clip editor. Colors can be stored as presets and can be applied to all selected nodes using the Copy Color button next to the preset menu.

Custom color for frames, Screenshot by Sebastian König

Hello, everyone.

Blender is becoming more and more big, developers who used to be active were kidnapped by their real life and they can not spend much time on Blender development anymore, which lead to some orphaned areas which are not currently maintained or in which help with maintaining is needed. I went through our bug tracker and source code to collect a list of such areas. Maybe somebody will become interested in improving some of this areas? It’ll help us a lot!

So, here’s a list of areas where help woudl be really welcome:

• Tablets and other non-standard input devices. In fact it’s pretty fun and not so difficult area to work in, the only real difficult here is that some bugs can be reproduced using only specific hardware.
• Transformation module.This module needs a bit more love. Some of issues here are caused by some design assumptions and some re-thinking might be needed here. There’s also couple of bugs there and think Martin Poirier (maintainer of this area) wouldn’t mind having help fixing them.
• Volumetric materials. This kind of materials were implemented a while ago and weren’t actually improved further last year or so. But they still have got some unresolved design issues like having volumetrics on different layers and so.
• Keymaps. We have an additional Maya keymap in default Blender’s configuration, but it weren’t improving further, sometimes it doesn’t actually match Maya.
• Sequencer. It’s kind of complicated area with some internal design limitations and not actually clear architecture. There are plenty of things which might be improved here, but there’s no developer-time currently for this.
• Particles. Currently there’s only Janne Karhu who’s working in this area and he doesn’t have much time for bigger improvements / fixes. Would be nice to have somebody else who’ll be familiar with this code to help improve / resolve issues there.
• Simulations. All simulations like cloth, physics, softbody, fluid are kind of orphaned at this moment. There’s Daniel Genrich who’s currently trying to improve this areas, but for sure one developer can not cover all this areas and having more developers here would be  really helpful.
• Metaballs. It’s also fun area which basically works, but it was designed a while ago and there’s some internal limitations there like they are not thread safe. Nice project for evening entertainment to play with
• Game engine. Well, it’s not actually orphaned, we’ve got some active developers there, but BGE is quite large project and few developers can not cover it all. And can think about couple of ways to improve this area a lot.

Hope this will help attract more attention to areas where help is needed. Connect with us via the webpage here.

-sergey-

(Image shared from http://www.flickr.com/photos/purrfectly_kittenish/901104856/)

General remarks on node groups

Problems with editing node groups

1. Only a single level of node group depth

2. Only a single node group can be edited at a time

3. Input/Output columns in display

Complex Cycles node tree for a snowy mountain shader

Moving nodes around also moves the tree sockets

Stupid long links getting in the way, i didn't want to insert that there

Solutions

Make a usable “frame” node

There is a new node type called “Frame” in the Layout category that provides functionality expected from node groups (the naming should be changed as well, one suggestion was “Tray”). The current implementation is still experimental, but with a little bit of work it can be a great feature.

The basic idea is to use this as a kind of local grouping helper. Any node (including other “frame” nodes, groups, etc.) can be attached to it, much like object’s parent/child attachment. Moving a frame node also moves all attached nodes. They can be linked to nodes outside the frame. Hierarchies of frame nodes can be created as well.

Unlike “real” node groups these frames can not be instantiated (shared), but they could allow simple duplication of all attached nodes. Since this is a very common use case for group nodes they seem to be a good replacement for local grouping of nodes.

Here’s a list of proposed additional features:

1. Clear indication of attachment (currently not visible)
2. Beside explicit operators for attaching/detaching nodes to frames: Moving nodes outside of a frame detaches them.
3. Moving nodes into a frame while pressing a modifier key attaches them to the frame (currently always attaches automatically).
4. Frames can be locked, i.e. no attached nodes can be moved, all buttons are inaccessible, no linking, etc. This way the frame can be handled as a fixed, local group and makes editing easier.
5. Frames can be collapsed, to free space in the layout. This has some design challenges though, like how to deal with links to/from the attached nodes.
6. Standard operators for duplication and deleting work both for a selected frame node alone as well as the frame plus all attached nodes (using a modifier key)
7. New operator for “make frame around nodes”, similar to current “make group from selected nodes”. Ungrouping simply means deleting the frame node (see above).

Not included here are all sorts of UI display improvements, such as easier resizeable borders, custom color schemes and so on.

Frame node hierarchy, active node highlights parent frames

Edit node groups as separate trees

Reusable, standalone node groups would be edited just like any standard node tree would be. When “opening” a node group the editor display will switch to the internal node tree, instead of pretending to display a specific instance of that group in its parent tree (which is in fact just the shared node tree). This way the editing of nested node groups works in a consistent way across all possible levels.

No more nodetree/edittree distinction in the node space struct is required, there’s just a single active nodetree. The node editor window can keep a history of node paths in order to allow a web-browser-like behavior:

• Opening a node group pushes a node path onto the history stack, before switching the node tree over to the group internals. (“Follow a link” in web browsing terms)
• Closing the node group means popping a node path from the history and go back to the previous tree.

This behavior may not be quite as immediate as the tab-tab edit mode currently possible, but it seems that this a tradeoff between flexibility and simplicity. For simple grouping the frame node type described above would be used instead. Node groups on the other hand will become the choice for long-term reusable node assets.

It may be a good idea to actually implement these nodes as a completely new node type “Asset”, instead of remodeling the existing Group node type. This way the usability can be tested and if successful the Group node type can be removed at some later date.

Detach interface sockets from columns

Current way of linking sockets to the input/output columns

Proposed input/output interface nodes

• How to set up the order of inputs/outputs?
  The column stacks make this quite intuitive, so i suggest to keep socket display there, but just display names. Changing the ordering there should use drag&drop instead of buttons (much easier + also saves space).
• Only one node for each input/output, having multiple nodes for the same socket would be too confusing. Using the same input in different places can still lead to long links, but it’s much more controllable then and is at least not worse than the current system.
• It would be nice to still have some visual indication of which tree socket in the column associates to which internal node. This is not as important as it may seem at first, since there is no real functional connection between the order of sockets in the columns and their nodes. However, some sort of highlighting indicator when selecting the node or the column item would make it easier to recognize them quickly.

Generating top-level interfaces from node trees

This feature is not actually a cure for an urgent problem, but will help increase usability for node assets. The idea is that any top-level node tree used as part of a material or texture or (later) modifiers and particles would be more usable with a compact interface (in buttons window) with just the important changeable settings.

As an example, consider a node tree setup for Cycles. Every material in Cycles consists of nodes, there is no hardcoded, non-node material system any longer – the node tree essentially is the material. Now, when using an existing material node tree there are usually a plethora of possible input parameters to consider: any unconnected node input in the tree must be considered by the user. There has been some effort by Brecht to implement a more “classic” list-style view of the nodes in the material buttons panel, but imho this is not of much help for large and complex node trees.

What i want to propose is to use the existing options for group node sockets as a means of creating an “outer” interface for such node trees. Basically what we are doing in node groups is defining an interface out of all the possible parameters used by internal nodes. Until now the only place where this interface is presented to the user are the group node instances: all exposed inputs and outputs of the group tree are translated to simple sockets on the group nodes linking to it. It would be quite simple to use the same system for displaying such an interface as buttons in the button space. Not only does this reduce the vast amount of possible input parameters to a sensible necessary subset (which can be extended when needed), but it also allows us to use meaningful names for parameters.

The snow shader example with current node tree list view

With just a few input nodes the interface can be reduced to meaningful parameters

UPDATE

After implementing the first two of the features mentioned above (interface proxy nodes and browser-like tree editing), i’ve made a little video tour to show them in action:

Node Groups Editor Tour

Now that Cycles is in a Blender release, the next step is to extend it further and improve performance. Remember that Cycles is intended to be a render engine for individuals / small studios, aimed primarily at rendering animations, and this goal is what we evaluate priorities of features by.

For the next few months, the main priorities are:

• Render layers, passes, full sample, compositing layer, ..
• Performance improvements / noise reduction for typical two bounce animation scenes
• Some smaller things for completeness (blender integration stuff, ramps, multi GPU, ..)

After that, we should get to some more exciting features, which ones are a bit unclear, but this will be influenced by project Mango. Volume rendering and motion blur seem like good candidates, but we’ll see. Performance work will be ongoing during Mango of course, and we see that quite broadly, it’s about low level performance tuning, better algorithms and better user control.

Beyond that, there is a feature list which contains roughly what we’d like to see added over the next 2 years.

Contributing

If you’re a developer and would like to help out, you can look in these places:

• Feature ToDo
• Known Issues
• Bug Tracker

If you need more details about how features should work, how to implement things or just to announce that you’re working on something, contact the bf-cycles mailing list. Another way to help is to improve our documentation in the manual.

Not Priorities

There are some things obviously missing that people would like to see added. Bidirectional path tracing, photon mapping, MLT and similar algorithm are not a priority for me, since we do not believe they are the main possible performance improvements for animation frames. Shading language support, resumable rendering, is another one that we do not think should get very high priority.

GPU Rendering

Lastly, GPU rendering can be somewhat of a bottleneck to development. It seems that with older cards and current OpenCL support in the drivers, we’d have to considerably complicate the code to get Cycles working fully, to the point where it would be too hard to add new features. This also means we’re dependent on improving driver implementations or language features. We’ll keep track of this, but also can’t justify spending too much time on this, to try to work around issues with every possible card / driver combination.

The dual-contouring remesh modifier is now in trunk. This modifier is based of code contributed to Blender by Tao Ju back in March. It implements the algorithm described in his paper “Dual Contouring of Hermite Data”.

The general purpose of the modifier is to generate a new surface that follows the same shape as the input, but with more regular topology. The output of the modifier is all quads, and they are “nice” in the sense of not getting too skinny or irregular density, which should be useful for sculpting. The modifier also has some other interesting effects, such as removing small disconnected pieces, filling holes in the mesh, and outputting blocky remeshes (as with the purple and blue Suzannes in this post.)

Big thanks to Tao Ju for his contribution!

Thanks also to users who come up with designs for the modifier’s icon, and in particular to Zafio, whose icon is now the remesh icon. And another thanks to Sergey for reviewing the code. (Blender at its best: everyone else does the hard work and I just push the big red commit button.)

Documentation and examples are on the Blender wiki, check out in particular nice example videos from Roberto Roch.

I’m old enough to vividly remember floppy discs – and Blender fitting on it! That was Blender 2.04, in 2000. For fun here’s a graph showing the growth of 32 bit download zips (the release binaries). It’s a graph growing nicely with Moore’s Law. Roughly double size every 2 years. Expect a 100 MB Windows installer in 2015.

Thanks Dan ‘troubled’ for the graph work!

Hi all,

Past couple months I’ve been working on implementing dynamic-topology sculpting for Blender. The implementation is based off the paper Freestyle: Sculpting meshes with self-adaptive topology by Lucian Stãnculescua, Raphaëlle Chainea, and Marie-Paule Canic. It’s getting stable enough to where people might find it fun to play with, so I thought I’d talk a bit about the tool and its current status.

Quick demonstration videos: http://www.youtube.com/watch?v=GFFtR8wBtZ8, http://www.youtube.com/watch?v=F0X51O4RgWs

High-level Overview

The dynamic topology tool allows sculpt mode to change the topology of the mesh as you sculpt. It operates on triangles, so you have to convert quads to triangles before using it. The mesh is updated as you sculpt (during the stroke, not just at the end of a stroke.) The tool places restrictions on the lengths of triangle edges to ensure that the topology stays “nice” for sculpting (no long skinny triangles.) The triangle density is constant across the mesh; there’s no way currently to make the tool give more triangles in a particular area.

The paper uses three basic operations to update the mesh: collapsing long edges, subdividing short edges, and merging close vertices. All three of these operations are implemented, but vertex-merge is currently disabled, as it’s too crashy to use right now. These operations require adjacency data that is not normally present in Blender’s mesh representation. The paper recommends storing the three triangles adjacent to each triangle, as well as a single adjacent face for each vertex. This is enough to quickly calculate the 1-ring for vertices as needed. To make adding and removing vertices/faces easy, they’re stored in linked lists rather than the usual mesh arrays.

Implementation Notes

Most of the code lives in blenlib/dyntopo.c and blenlib/pbvh.c.

The linked-list representation is a bit similar to EditMesh, but smaller, simpler, and easier to integrate with the PBVH. The PBVH is the spatial data structure used in sculpt mode for making fast searches for which vertices to update and partial redraw. Ordinarily the PBVH contains arrays of mesh-element indices; these arrays are built just once when you enter sculpt mode. For dynamic topology sculpt, list bases for the vertices and faces were added to the PBVH nodes. At the end of each stroke, any modified nodes are checked to see if the number of faces they contain has grown too large, and if so they are split. (Empty nodes should also be collapsed, but I haven’t gotten around to that yet.)

Testing

Code is available from Gitorious, in the “adaptive” branch:

https://gitorious.org/~nicholasbishop/blenderprojects/nicholasbishop-blender

git clone git://gitorious.org/~nicholasbishop/blenderprojects/nicholasbishop-blender.git
git checkout adaptive

Only CMake build system has been updated, but you could easily update scons too if you prefer that.

Usage is pretty simple: create a mesh, convert to all-triangles, enter sculpt mode, and click the “Dynamic Topology” button. Note that only the “simple” brushes work right now. Fancy things like smooth and grab will crash. Sculpting on a non-dynamic topology mesh will crash. Undo is disabled. Lots of other things I’ve forgotten about will also probably crash. Have fun!

Open letter to everyone involved with managing/using COLLADA as proposed open 3d exchange format:

This is a follow-up on the discussion I had with Khronos at Siggraph, especially on getting COLLADA supported better. In some ways things – on Blender side – improve steadily. But I also get disappointed reactions of professional users expecting things to work much better than we can provide still.

From the Blender side I think we’re quite well equipped and supported now. There’s a small but active team of 4 people working on it.

In order to keep momentum I have two suggestions for Khronos or the Collada team:

1) A call among Khronos members to support the OpenCollada(*) project in one way or another. It would be much advised if companies take ‘ownership’ on this project too, getting officially involved. The OpenCollada website is now anonymous with a donation button without any visible projects or people running it. People in our team who submit bug reports to OpenCollada also wait far too long to get responses (> 6 months).

2) The character animation im/export pipeline is still the most difficult and wanted target. I would bring together the stakeholders for this to define a ‘Character’ badge, based on the minimal & feasible specs related to that. That’s on one side the people who work on tools like Maya/Max/XSI/Houdini/C4D/Blender etc and the other side ‘users’ such as Unity3D.

I know the Khronos group itself won’t allocate budgets to software development itself. Maybe the above two suggestions would fit in actions or organizational support Khronos members can provide somehow?

My own 2 cents on COLLADA: the advanced flexibility of the spec is both its strength as its weakness. In practice it means that you can align the definitions in files quite nice to how your own architecture works, forcing other programs to do conversion magic to own internal architecture again on reading that COLLADA file.
Also the way how the conformance tests work now is very elaborate and complex (no companies or end-user tools have been listed to conform yet even!).

I realize that narrowing down the COLLADA spec is not going to happen easily, so I would suggest to reorganize (or refocus) the conformance testing system in a way both users as developers get predictable results quicker. That could be achieved by defining a sub-set for the Baseline badge which only validates;

- Baseline Model Badge: tria/quad models with UV coords and texture links and basic material definitions or references. Result should be efficient but minimal 3d model exchange.
- Baseline Character Badge: Model as previous + deform groups, basic per-group and baked (per frame) motion matrices. Result should be efficient minimal 3d character export to game engines, and for animation film the motion of control-rigs only (assuming the character rigs themselves remain native).

For these badges I would not look at general API conformance, but simply bring together actual COLLADA users to provide the smallest & simplest use cases – using minimal & clear specs – and only validate this subset to confirm the badge.

This level is also what we currently support for FBX now, which is successfully used for the Blender-Unity pipeline now. It’s quite remarkable that we can get this work for this closed format well, and still struggle to achieve anything useful on that level with COLLADA instead.

I have only been involved indirectly with our Blender-COLLADA efforts, but I do know there’s been a whole lot of development time invested in it already in the past 4 years. The fact things still only work in a very basic way is quite disturbing. It shouldn’t be that difficult really. If something as basic like Model/Character I/O can’t be achieved among the main 3D tools in a short term, we might better conclude that COLLADA is not going to work for this ever…

Regards,

-Ton-

(* There’s also PyCollada http://pycollada.github.com/ and efforts in irc #blendercollada going on for a smaller and better maintained version of opencollada)

For the 2.60 release I like to get our blender.org feature pages updated, and provide (new) users a great collection of .blend files to play with. A selection of the .blend files then can also go to the the “Demo Loop”, a python script that loads files in a sequence and shows anims or renders. The Demo Loop has been used successfully at shows, and by vendors such as HP’s workstation division (sponsored us for Siggraph with systems!). You can try the Add-on “Demo mode” for it, but be warned… it had a bug which only got fixed today.

Update: the spam filter here blocked posts with many urls, we do our best manually approving it now!

Call for screenshots:

• Use CTRL+F3 in Blender to save, preferably as png file.
• Use full monitor size windows, 1920×1080 or 1920×1200 pixels would be great.
• Screenshots with different themes, fonts, languages etc. are welcome too.

Call for demo files:

• Make sure it runs fine in 2.59 release from blender.org
  (Cycles demos are great too, we can spread that separately for now)
• Files should either have a short animation (turn table anim for objects, character anims, etc) or be interesting to render/composite (F12), or have a cool GE experience (Pkey).
• Make sure you pack in all texture maps in the .blend
• Physics sim files: put in directory below .blend, use relative paths, and zip it all.
• Best render demos are when it doesn’t take long, 20-30 seconds or so.
• Files will be shown using the default theme colors.
• Keep files a bit small… no limit here, but we can only include a few 50-100 MB files for download.

License as Creative Commons 3.0 Attribution

• Default attribution would be:
  (CC-by) Blender, www.blender.org
• You can optionally add your name and/or URL to the attribution.
• Purpose is to (also) ensure everyone will be forced to credit Blender well!

Upload to web!

• You can use your own website or dropboxes of course
• Or use our anonymous ftp:
  - ftp to ftp.blender.org
  - username: anonymous
  - cd to directory incoming/ and upload the file(s)
  Files will appear in public at url http://download.blender.org/ftp/incoming/
• Post here the url of the file(s) and your attribution options.

Thanks!

-Ton-

Hello, Blender Community. Last week I was working together with Xiangquan Xiao to finish his Google Summer of Code project related on improving internationalization and localization in Blender.

Localization was changed a bit since Blender 2.49. Now you can translate visible interface (labels, buttons, menus) and/or tooltips. In comparison with 2.49 there’s no option to separate translation of buttons and menus. It is because of internal changes of Blender itself — mostly related on RNA (which is actually getting translated and it’s quite difficult to predict if operator name would be used for button or menu).

Usage

Usage of localization is pretty simple. Go to User Preferences, System tab and in the right bottom you’ll see Use International Fonts checkbox. If you enable it, you’ll see Language used for translation and two check boxes: translate interface and translate tooltips. Interface will be translated as soon as you set language and enable translation of interface/tooltips.

Known issues

Unfortunately, there are some known issues:

• Translations aren’t full. It was more a project to bring up “platform” which will allow making translation easy. We need translators to translate all remained messages in .po files. I think details how this can be done would be published separately.
• If you’re running Linux, make sure locale for your language is generated. If locale isn’t generated, you’ll have a message in terminal when try to switch translation on. To define new locale you can use this command: sudo localedef -i ru_RU -f UTF-8 ru_RU.UTF-8
• I’ve noticed really slow startup time and memory usage up to 800-900Mb on my laptop. Spent plenty of time to figure problem out and i found, that it’s video driver issue. My laptop has got some of Intel HD graphics (integrated into processor). Upgrading driver from Intel’s driver download center solved this issue.

This project should be really easy to use, so let’s keep this post clear. Thanks for your time

-Sergey-