New versions of flame 2008 and smoke 2008 were at IBC this weekend. The most striking thing is that the UI has been adjusted to fully take advantage of the 16:9 screen. Yes…time to give that muscle memory a bit of a shock. The smoke release has a totally reworked DVE module, inspired by the Action module, as it provides compatibility with the effects app. Read why you’ll want them….
In fxguidetv episode 14 we speak with Philippe Soerio, product designer for flame and smoke, about the new releases. The apps are scheduled for release in the autumn (north america), which is perfect timing for our new term at our sister site fxphd.com. We’ll be offering new classes at fxphd in both flame and smoke during the term — with the smoke class getting people up to speed on the new DVE and layout.
The flame and smoke releases have numerous new features…here are some of the highlights.
16:9 UI: It’ll be time to give your muscle memory a bit of a massage as you relearn where all the buttons have been moved. The good news is that the position of “universal” buttons such as exit, play, process, and animation-related ones has been unified as much as possible to be consistent. Numerous sub menus have been removed so that adjustments can be made more easily. The more accurately named Action Media menu (formerly Layers) has direct input for crop and crops softness. There are new tabbed menus in Action, which provide direct access to to adjustments for Axis and Object data (such as image parameters) in a single menu. I’ve grown to really like the new layout as it really helps working with the app. But do we really need direct access to the number of reels on the desktop?
Action/DVE: The Action UI has probably seen the biggest changes, with new node bins and a tabbed axis/object UI. The new “action-inspired” smoke DVE as it was called at IBC (we prefer to call it “Action Light”), is effectively Action with a few less available nodes (Deform, Particles, and more). Since the modules in flame and smoke do actually have different functionality, it admittedly makes sense to name them different. But at first glance, it certainly appears to be Action. The newly reworked modules will give editors access to tools such as instancing and fully-featured source nodes. Expressions are now available in the DVE, providing both easy linking and complex relations between objects.
The new DVE object is intended to make smoke users feel at home in the DVE and Action modules. This node does a good job of recreating the functionality of DVE layers in previous versions of Smoke. When selecting this node, users have direct access to adjusting the front, matte, shadow, and offset positions. What is happening behind the scenes is that Front and Matte sources are being automatically created for the media. This can be seen by expanding the DVE object….it actually expands into several additional axes and source nodes. A word of warning — once you expand the DVE object, you can return it to its individual state via Undo. But if you don’t do it immediately, once this operation scrolls off the undo buffer, you’re outta luck to collapse the nodes back into a DVE object.
Objects in Action such as axes, images, and textures are now easily accessible in the main UI at all times. Double clicking or dragging nodes from the bin to the schematic or even result view adds them to the scene. One common trip up to new users is discovering how to add an image, as an image icon is not visible in the bin. The node bin area contains a media preview of the selected media, and clicking or dragging from this region will add an image to the Action setup. Users also have a new option of “Auto Add Image” or “Auto Add DVE Object” in the Action setup. Setting either of these options will add an image or DVE object to the setup whenever you add new Media to the setup. You can also run in old school, mode which is “Auto Add Off”.
There is a new Duplicate node which allows you to duplicate all parameters (except for blending modes) from one object to another. How does this differ from linking with expressions? First, motion paths and shape channels are supported so that you don’t need to rely on explicit points. This can be a great time saver for linking Bilinears/Bicubics and Cameras under source nodes. Secondly, when you use Duplicate by dragging from one object to another, the source object parameters are mirrored in the destination. However, if you make a change in the destination object, it is also reflected in the source object. Consider it a two way street after the initial link is made.
FBX support has been tremendously improved — in other words, it works. You now have the option of exporting axes in an action setup along with the camera data, which can be incredibly useful. You can also export the camera and the point cloud from the 3D Auto Tracker. Round-tripping from Maya and 3dsMax maintain data integrity without any workarounds.
Motion Vector/Motion Blur: Batch has three new nodes for motion estimation, including the ability to create motion blur based upon motion vectors. The Motion Blur node can do motion estimation timewarps as well as add image-based motion blur to a scene. The Motion Analysis node will accept an image and output forward and backward motion vector passes which can then be applied to another image to create either a timewarp or motion blur effect. This can can be useful for applying blur to cgi rendered elements, for example. As a time saver, the Analysis node outputs a 16-bit vector image which can then be stored on the framestore for later use so that you don’t need to analyze again. The Motion Blur node can also accept a 16-bit float image as its input and output the processed result in 16-bit. Effectively, this means that 16-bit float images can be stored natively on the framestore.
OpenEXR/16-bit float support: Consider this the first baby steps (we hope) to implementing full 16-bit float processing throughout the application. As noted earlier, 16-bit float can now be saved on the framestore. You can therefore import an OpenEXR file and save it in the library for later use. With the LUT that is available for every clip in batch, you can then use the new OpenEXR LUT editor to adjust exposure, gamma, and more before converting to 12-bit or lower for use in a batch setup.
There are very few modules which can process in 16-bit. Apart from the Motion Blur node, most are formatting and edit operations (Pulldown, Deal, Deinterlace, etc.). Timeline operations such as Cut, Dissolve, Repeat, Timewarp, Resize, and Blend are also supported. The spark API allows for 16-bit processing, yet no sparks that fxguide knows of can be processed in 16-bit. It is a bit disappointing that more 16-bit modules are not available — especially color grading and keying — but it is apparent that the move is on to create support for higher bit depth imagery in flame and smoke.
Clip Compatibility Between Smoke and Flame: There is “100%” compatibility in clips and setups between the two flagship apps. What does this mean in reality? It means you can load clips from both apps and keep clip metadata intact — moving the clip between the two apps without losing information. This includes loading DVE setups in flame and Action setups in smoke. However, effects and objects which are not available in smoke (Particles, Deform, etc) can be rendered but not modified. The same applies to clips created when History is turned on.
Flame’s timeline now supports multiple video tracks and layers since the timeline in batch is essentially the smoke timeline with several limitations. Can you say “Smoke inspired?” You also have the possibility of using up to 32 audio channels in a flame timeline, but our guess is that very few flame artists would actually use this. The bottom line is that you no longer need to select which video layer you want to grab from a smoke timeline and, if you need to, you can actually mix stereo music with other audio elements in a single timeline.
The timeline replaces the Edit Reel in the player — the venerable Edit Reel has found its righteous place alongside the 3DEffects module. While I miss this a bit, the responsiveness of gestural operations is much better than before. At first glance, the multitude of buttons and settings can be a bit intimidating. But by simply turning on the Trim and Ripple buttons, the familiar trimming tools are available for use. For slipping operations, you’ll need to learn the CTRL-/ hotkey. Once you learn these and how to load in an audio track, there’s really no need to dive any deeper if you don’t want to.
You can now also process unrendered SegmentFX directly on the desktop and in the Library as well as Process to Burn segments in the batch timeline. Within a Segment FX in the Batch timeline you can set a context view back up to the level above or the main level. Gone now is also the restriction of having to have all clips locked to the batch timeline — no need to work around slip values to edit a clip into a timeline.
This first compatibility release, however, does have limitations. The only Soft Effects which are available in the flame timeline are Resize, Blend, and Timewarp. The other effects are visible as “LED” indicators without buttons (see image), allowing them to be enabled and disabled on a scene by scene basis. While you cannot edit these soft effects, you *can* use the CTRL-drag to copy soft effects from one clip to another. There is support for containers, allowing you to have a matte and fill combined and then layered as a key in a timeline. However, without access to the Axis soft effect you cannot move or animate the container, limiting its usefulness.
Regardless of the limitations — the consistent improvement in compatibility between smoke and flame is great to see. Moving forward, full support of soft effects in batch and the desktop player would be the next logical steps. A critical next step would be access to batch SegmentFX directly from the Player — so one could view a clip from the desktop, enter the Timeline, select a segment and then enter batch directly. To have to take a clip into batch first and then enter SegmentFX is an unnecessary additional step which breaks a potentially simple workflow. There may be technical limitations to doing so at this point — and it may be difficult to implement — but as I like to say: “Work is Hard”. While working on adding 16-bit support to more modules, Autodesk should add this to the list as the benefits would be huge.
The overhead of Clip History also needs to be reduced moving forward, enabling more and more users to take advantage of it. I’ve been using History since day one and am fully aware of the bugs and problems of the early days. At this point, most of the bugs have been fixed so that critical data won’t be corrupted and lost. However, there continues to be a tremendous processing overhead in saving timelines with numerous setups (especially Action) as SegmentFX. Anything that can be done to reduce this overhead will remove the last excuses to using History and SegmentFX.
Batch Paint: Actually, a more proper title for this would be “Usable Batch Paint”. For the first time, I’ll definitely be using the module. For performance reasons, gone is the multi-layered approach and is instead a single layer paint with multiple sources. The UI can be a bit confusing at first if you’ve used the previous Batch Paint implementation. There appears to be a layers menu, but instead it is a listing of sources which you can use to reveal onto the single layer paint. Once you understand the architecture, it makes complete sense and is easy to use. How does the module work?
Add a front and optionally a matte to the Paint node. You can then Paint on this single layer in a very similar way to the Desktop paint module….the UI and brushes are . You can also use clone on this layer, not only offsetting the image but also rotating and scaling the source image. Onion skinning is available, as are hotkeys to easily reposition the image for cloning. Next, you can add sources to the paint node in a way similar to before. But instead of layers, you select these layers and use them as reveal sources. Functionality is the same as cloning — but the distinction is that you reveal layers and clone the front input. While painting you can not only rotate the sources, but also rotate the overall canvas to more easily paint on an angle. After painting, you can add nodes before the paint module or replace the source — and the result of the paint module with the new revealed/cloned images is updated. It is effectively remembering the strokes and reapplying them.
In addition to being much faster and more responsive than its predecessor, one of the great things is that the _Paint library is a thing of the past. No need to make sure the library is saved….the module works without relying on this semi-hidden library. Since the operations are performed on a single layer, along with other caching improvements, the paint modules is much more responsive than the past. Don’t let the caching term scare you away…it seems to be very robust as opposed to the normal batch caching mechanisms.
Distort: One of the issues with the Distort module has been the inability to restrict the impact of a spline on the image. In the new version, this has been improved in comparison to the current version, with the ability to restrict how far away from the original spline that the warping occurs. For those of us who don’t use distort very often based upon our past experiences….it seems time to revisit the node.
Standard Filesytem Support: Don’t like the stone tax (which admittedly has been reduced in recent years)? Standard Filesystem support means that facilities can create “framestores” on any standard UNIX-compatible filesystem. To the end user, these volumes are transparent and appear identical to other libraries. Performance is, of course, limited by the hardware and filesystem but this is something that can be addressed by the facility.
Files on this file system can be stored in any of the standard file formats supported by flame or smoke, such as DPX. The file type is determined on a volume by volume basis. Both stonefs and standardfs filesytems can reside on the same system and be mounted at the same time. Multiple systems can connect this system as well — though the obvious permissions and file change concerns need to be considered when setting up such a workflow.
In addition to using this as your main storage volume, one interesting use could be to use a Standard FS as a nearline backup or temporary storage area. Without archiving, you could transfer the material to the other framestore to create room on your local framestore. If you actually needed to make a change in the project you could do so using the alternate Standard FS as opposed to having to reload the archive.
Access to Remote Framestores and Projects: This has actually been an undocumented feature in recent releases — you could change the name of the stonefs keyword to include the host name and gain access to another flame/smoke. In the 2008 releases, this is included as part of the startup. When the app is loaded, you can choose a remote system project to open (or create a project on a remote system). Regrettably, you still should not have two systems simultaneously working on the same project as desktops and _exit setup files can easily be overwritten. It seems to be time to include the host name in these files so that multiple users can share the same project at the same time.
Wrap-Up
There are a lot of other new features and improvements as well, including 12-bit support in Flint HD and Smoke HD. I would have liked to see additional — aka new — creative features in the current release as well as 16-bit float support in more modules, especially color grading and keying related ones. Access to smoke soft effects in the flame timeline should be standard and will hopefully be quickly added. As would access to some kind of batch within smoke, now that the compatibility issues have begun to be addressed.
It would be good to see the new effects available in Toxik brought to flagship applications of flame and smoke. While we understand some of the architectural limitations, the grain tool in Toxik is an example of a tool which could be brought into flame. The fact that they are in the sub $4,000 product and not the high end products is, quite frankly, a bit odd. Especially since Autodesk has noted several times they have gone to great efforts to create an image science group which creates tools that can easily be developed for all products.
That being said, as listed in this rundown, there a lot of improved (and new) features in this release flame which will hopefully lay the foundation for improvements to be addressed in the future. The subscription option is quickly becoming a popular option for facilities — they are able to budget upgrades and have predictable spending. The key to this option being successful is that Autodesk needs to consistently develop new features and make them available to end users on a timely basis.
While the 16:9 layout is an esthetic change it is one that has been requested by users, it does hopefully provide development benefits. Unifying layouts between modules and the apps could possibly lead to shorter development cycles as the changes can be easily propagated between the products. Development seems to quickening, but it is critical that the pace continues and we see implementation of high end features sooner rather than later. The gap between flame/smoke and desktop capabilities continues to quickly narrow, so Autodesk needs to make sure that improvements keep on track so that the price justifies the software.