Matt Ebb

From time to time I get emails asking about voxel data/volume rendering capabilities in Blender for medical scan data (see this previous post). Today I got one asking for a simple example for using it in 2.5, so I thought I’d re-post it here. It’s using a 512 x 512 x 233 scan of a plastic skull, and the demo file is just loading it up as a density source in a simple scene with ground plane and light. To set it up from scratch, you should be able to follow the same instructions as any tutorial for rendering smoke or other volumes in blender, but change the density source.

Download the demo .blend file here.

Some extra notes:

• The main thing to remember is that volume rendering in blender is not really intended for solids, or even medical usage at all – it’s really just a nice side effect. The volume shader in blender is intended for gas/particles like clouds or smoke. Having said that, if you crank the density of the volume right up, you can approach something more solid looking. The above example is using a Density Scale of 50.
• This plastic skull example was quite easy because I didn’t have to isolate any kind of extra tissue etc. To do that normally you’d have to use the ramp option in the Texture’s Color panel. Here’s an example of a scan of my own head, using the ramp to isolate out the skull (right) from all the flesh (left).
• You may notice on a dense volume like this, the shading looks a bit blocky – this is due to the Light Cache, which speeds up rendering a lot, without too much visual quality loss on most cloud/smoke kinds of volumes. The artifacts do show a bit more clearly with very dense volumes though. You can remedy this by either increasing the Light Cache resolution (using more memory) or turning it off completely (using more CPU).

I’m currently here with several other Blender developers at Winter Camp 09, organised by the Institute of Network Cultures in Amsterdam.

We’re here to discuss and hopefully make some decisions and consensus on the work we’re doing for Blender 2.5, particularly regarding the user interface and new tool/event system. It’s been really promising so far, and we’re agreeing on a great number of things.

A few links:

• Some photos at the Blender Institute by Andy
• Live audio feed via skype
• ‘Winter Camp Warm Up’ video recorded at the Blender Institute

It’s basically using a modifier at the bottom of the stack to create geometry, which you could then just apply to edit the mesh directly, though that’s not always necessary. This is a bit similar to how Max and Cinema 4D work. When you add an object, you can still manipulate dimensions, resolution, other parameters as a whole. Then if you want to edit it manually, you convert it to an editable mesh with a click.

Above are some screencasts of what I did in Blender. Obviously it’s simple and rough, and if developed further, one could do things to clean it up like disable those generator modifiers from appearing in the menu, change the add object code to apply the generator modifiers automatically, prevent them from being moved up and down the stack, and perhaps add some code that upon pressing Tab, would give you the option to apply that modifier and just convert it to a mesh so you can edit it. In any case, this could serve as some kind of inspiration for something nice in the future…

• Floating panel window edge snapping; not an obvious headliner, but makes working with floating panels much nicer
• Video sequence editor visual redesign, following on from this old blog post with mockup. And it only took 2 years to get around to it! 🙂
• Nice lighting setup/checkerboard/hair in the buttons preview render
• Empty display types and size; right now there are only two styles, need ideas for more!
• Cut/Copy/Paste selected text in a button. Should have done it before, but was obviously too lazy
• Three simple composite nodes: Separate RGBA, Separate HSVA, Set Alpha. Lots of fun and I hope to do more. An early patch for Combine RGBA is in the tracker!
• Colour sampler (eyedropper) now in the colour picker popup. It lets you sample a colour from anywhere on the Blender window

There’s also been some fun with the news reports. Blender.org got hit hard by the news article on Digg that some sadistic person submitted there. Also, presumably after reading through the Elephants Dream blog after hearing about the Blender release, one of the many Slashdot Wikipedia ‘enthusiasts’ posted an article mentioning me and linking to my unfortunate experience putting the Elephants Dream DVD menus together. I feel so honoured to have my name up in lights while providing an opportunity for the self-important misanthropes in the Slashdot peanut gallery to delight in some more of their irrelevant ranting. Bravo.

All in all though, a good release. Here’s to the next one, of which I’ll try to keep you all informed of my work towards.

As Blender expands in its capabilities, less and less functionality is accessible directly with a single key press or button click. Keyboard space for new shortcut keys has run out, and most of the recent key additions are poorly structured, since it’s been a matter of finding a key that’s actually available, not one that’s ergonomic or meaningful.

There are ways to help this; customisable shortcut keys and customisable toolbars can help bring back direct access to tools, and an updated and re-thought keyboard layout can help prioritise what’s needed for working in the current age. Giving tools like texture space transformation (T) or split (Y) their own direct key presses worked fine in the 90s when there weren’t that many tools in competition, but these days we have much better tools (such as UV mapping) and more frequently used tools that should be brought to the fore. There is redundancy between popup menus (Ctrl E and K mesh editing menus) and they’re not optimised for ergonomics the same way that Blender’s other earlier hotkeys such as G, R and S are.

Ultimately, although a direct hotkey approach is great when possible and has worked well in the past, it has trouble scaling with an increase in complexity, which is happening in Blender more and more these days. Popup menus are evolving to be a new primary method of accessing tools – just about all of the excellent new mesh modelling tools in Blender 2.42 are found in the ‘Specials’ and ‘Edge Specials’ popup menus. It pays then, to take a look at making these menus as efficient as possible too.

Radial menus are a different method of presenting menu options to just a straight list. They’re more efficient to work with for a few reasons:

• The human ability for memorising an angle direction is much stronger than for remembering a linear distance
• Rather than needing an exact click on a button, one can select items in radial menus based on the angle of the mouse pointer from the start position. This makes the size of the selectable area segment much larger than that of a linear menu item, making it much faster to hit (see Fitt’s law)
• Radial menu items are an equal distance from the mouse pointer, so it doesn’t get successively harder to hit later items, as in a linear menu

Since radial menus rely so heavily on muscle memory, it’s not a good idea to change the position of menu items as new options are added. This can be a problem with auto-flowing radial menus that just divide the available 360A* by the number of available items. In an application like Blender, where new tools are often being developed and added, this would change the menu’s layout each time.

I have designed a layout and order of appearance to use for the first 8 radial menu items. It goes in a seemingly weird pattern, but it’s actually quite logical. It’s designed to be ‘upwards compatible’ for muscle memory so that the menu item locations are fixed and don’t move as new items are added to the menu later on. It also optimises efficiency – a radial menu is best kept symmetrical, with as large an angle between items as possible, so that the hittable areas are as large as possible, and gestural mouse movements can be fast and inexact.

It starts off with two opposite sides for the first two items then joined by the one below for the third (this way, even with three items, the menu seems to still be ‘in order’ reading left to right).

Then the fourth is added to complete the compass directions. From here, it’s just a matter of subdividing the rest of the angles for the last 4 items.

Although the radial menus are best with a maximum of eight items, they should be able to gracefully cope with more, if needed. I haven’t yet figured out the best way to do this, but I’ll probably try an approach of subdividing the 5/6/7/8 positions, or experiment with making a second ‘ring’ on the outside.

References:

• The Design and Evaluation of Marking Menus, Gordon Paul Kurtenbach
• A Comparative Analysis of Pie Menu Performance; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI’88 conference, Washington D.C.
• The Design and Implementation of Pie Menus; Don Hopkins; Dr. Dobb’s Journal, Dec. 1991.

The toolbar is stored in UserData, meaning it is saved in the default .B.blend file so it’s there when you start tuhopuu3 or load a new file. It is context-sensitive, so it contains different items depending on what mode you’re in. This useful, but also a technical constraint since you don’t want to be executing object mode tools while in edit mode, or vice versa.

Working with it is very simple, just right-click on a menu item in the menus system, or in the toolbar itself for a menu of choices. In the menus: Add to Toolbar adds the clicked-on menu item to the toolbar. In the toolbar, Remove from Toolbar removes the clicked-on item from the toolbar. Wow, who would have guessed! Move Up and Move Down let you re-order the items within the list, and Insert Separator inserts a separator after the clicked-on item. You can give the separator a name, as a nice way to group different tools like view tools, selection tools, interactive tools, whatever you like. Otherwise, you can just leave the name blank to use it as a spacer. And of course, the toolbar items align nicely in their rounded groups ;).

There are a few things that I’d like to try, which are on the todo list:

• Options for using icons, or abbreviated item titles like in Silo (i.e. Subdivide Fractal becomes “SF”)
• Option for horizontal layout, like a pseudo second header
• Putting these custom tools in a popup menu if you don’t want it on screen all the time

The back-end code behind it is probably not a good long term solution, and will likely be made redundant whenever Blender’s fabled internal events system refactoring happens. Perhaps you can consider this implementation a proof of concept, but I continued with this project and committed it for a few reasons:

• Regardless of whether a ‘real’ back-end is in place, we can still use this for user testing and experimenting with the interface and interaction design.
• Seeing this in action might ‘inspire’ whoever’s going to be working on a proper events refactor to get moving on it!
• Whether or not programmers consider the code good, or sustainable, this is working here and now and useful for users, so why not put it in tuhopuu anyway.

Notable features include: (excerpt from the CVS commit logs)

• Useful controls for start/end/current frame, and

  buttons to rewind, play and fast forward in the active time area.

  The area before the start frame and after the end is now tinted

  out slightly.

• The auto key recording is now actually useful 😉

  Rather than being a user preference, it’s now a toggle in the

  timeline (red record symbol) which can be flicked on and off

  quickly, which is really how this is meant to be used. The button

  currently works for both object and action keyframes, hopefully it can be extended to other Ipos such as materials in the future.

• Keyframes of the active object are shown as little lines in the

  timeline. Yellow lines represent object keys, blue lines represent

  action keys

• Markers! Markers are the little triangles you can see in the

  screenshot above. Video editors should be very familar with this,

  they’re used very often in editing to help time cuts etc, but I don’t

  know of any other 3D apps that have this, which is a little

  surprising.

  Basically, markers are used to mark spots on the timeline, that may

  mean something to you, so you can easily find that point later.

  They’re useful for timing animation, syncing animation to audio,

  and plenty of other things, I’m sure. You can drop a marker on the

  current frame by pressing M while the mouse is over the timeline,

  or also by pressing M during animation playback (Alt A, play

  button, whatever). You can remove a marker from the current frame

  with Alt M. There is currently a limit of 99 markers

• Support for naming markers. Ctrl M or Frame->Name Marker opens

  a text field where you can give a marker on the current frame a

  name, which displays next to the triangle icon.

• Previous / Next Keyframe buttons. These should be pretty self

  explanatory – clicking them brings the current frame to the previous

  or next keyframe visible on the timeline.

• Hotkeys (S and E) for setting the current frame as the start or

  end frame of the animation.

• Right mouse button now cancels animation playback, just like most

  other ‘temporary modes’ (same functionality as Esc).

• Timeline now initialises showing frame numbers by default

The problems I saw in the previous versions:

• They were too dependent on the little yellow center points – when I removed them in the previous experiment, the lamps became almost invisible.
• The ‘stems’ (the vertical dashed line connecting every lamp to the ground plane) created useless visual clutter (why on earth should it be a lamp’s job to tell me which is the Z axis?), and was a potential source of confusion, making normal omnidirectional lamps look the same as hemi or sun lamps pointed vertically downwards.
• There was inadequate visual distinction between lamp types in the 3D View – a hemi lamp looked identical to a sun lamp, and the visual design didn’t really say much about what each lamp did.
• There was inadequate visual communication of other subtle lamp information (only some, such as ‘Dist:’ or ‘Sphere’ settings).

So, I’ve tried to make some improvements:

• Each lamp now has a distinct visual appearance, that hopefully gives a better idea about how the lamp works, i.e. an omnidirectional lamp is represented as a point source, a sun lamp is shown with the typical sun rays, a hemi lamp is shown with arcs representing that the light is coming from a hemisphere direction, not just a single point. I think they all look nicer too 🙂
• More information is displayed – the size of the continuous line circle represents the energy value of the lamp, and a new circle inside the base of the spot lamp cone represents the SpotBlur falloff value (Note: this second circle is not entirely accurate to the rendered image, but it’s moderately close. Maybe someone with knowledge of how this works in the renderer could make it better, at least it’s a nice visual hint at a glance for now).
• The lamps now scale with the objects’ size, and with the view zoom. This means that when you zoom out, you don’t get a meaningless conglomerate of yellow dots at the same size, obscuring everything else. It’s also easy to tell where the lamps are in 3D space in perspective – lamps further away will look smaller. Of course if you do want them to look bigger though, you can just scale them up.
• I’m guessing because they’re drawn as lines, and not using glBitmap commands, these lamps are slightly faster to display on screen, too. On my Powerbook, according to Help->System->Benchmark, the scene shown in the video linked above displays at 284 fps on Blender 2.35 and 298 fps on my development version.
• I’d also like to rename the ‘lamp’ sub-type to ‘omni’ (short for omnidirectional). It’s rather dumb to have a ‘lamp’ sub-type of a ‘lamp’ object.

Now, if only we could modify lamp data (spotsize, spotblur, energy, etc.) directly with transformations in the 3D View, rather than having to use sliders for everything. *sigh*

Until recently, this hasn’t been a feasible change to make, since the centre points were the only indication of selected objects in solid or shaded display. However, with Ton Roosendaal’s addition to highlight the edges of selected objects, the centres are no longer as necessary. I’m convinced this is already an improvement in terms of getting rid of the clutter and allowing me to concentrate on my work, but the real value comes when modelling. The XYZ axis marker displays aligned with the object’s local co-ordinates, not global co-ordinates, which is extremely helpful when using axis-constrained transformation (move, rotate, scale). I already owe Martin ‘theeth’ Poirier a lifetime’s supply of free beers for the implementation of this wonderful feature, but one drawback has been that it can be difficult to work out which local axis to constrain to, since the local axes aren’t visually communicated in any way. With this addition, it’s very easy to see, for example, the direction that the red line is pointing in, and quickly hit the G, X, X key sequence to move an object or sub-object along the local X axis. Very fast modelling workflow that takes minimal thought after getting used to the X = Red, Y = Green, Z = Blue convention.

Another interesting side-effect is the extra visualisation of the object’s transformation. While the center dot only represented the object’s location in space, the axes visualise location, rotation and size. This may be increasingly useful information to see, with the addition of the new ‘Align’ mode for transforming object centers only, which will be in Blender 2.34.

On a vaguely related note, I hope you like my new ‘Light’ colour theme 🙂 I found the default was just too dark to be effective in the office I’m working in at the moment – right next to a very bright wall of windows. It also seems to fit in much more nicely with this Mac OS X desktop, too. Colours and themes are also another item ony my list for further investigation before 2.35. Actually, speaking of releases, this will be my fifth post here, with four of them about Blender UI. Yes, there is more to me than Blender, I guess it’s the general state of excitement leading up to what will be a very impressive 2.34 release!