Hey everyone, again I’m sorry about the lack of news, but that may be about to change, I’ve moved the blog over to its own domain, and I’ll be able to host stuff* there as well.
Keep an eye out, see you on the other side! 
* nudge nudge, know what I mean?
Due to a recent wave of visitors of this blog, I feel compelled to give signs of life! The software is moving forward, although still in ALPHA-phase, a lot has happened since the last post. I will write more regularly when it becomes more public – the next step is slightly wider testing group.
I love your comments on this blog! But they don’t always provide enougn information such as reply addresses, thus I’ve set up an e-mail address if there is any inquiries, you can contact the project using vfxdesktop at gmail dot com.
Cheers!
Please excuse a lengthy post, there is much to go through
A lot of things have happened since the version I first showed. A lot of it is under the hood, but there’s also a number of new features, and new modules, as well as enhancements on the previously existing modules.
I have a few new concepts to introduce. As I may have mentioned earlier, one of the main motivations for this application is to get rid of tedious folder browsing, and especially the kind you need to do over and over again. Therefore the pre-defined project structure is center stage. So what’s new?
Most of these are easiest to show in video form, so go ahead and click play!
(Visit http://www.vimeo.com/5677977 to see it in HD)
In more detail:
The project menu lists every folder under the specified project root path and treats it as a project. I talked about project definitions before, but now it’s a bit updated. In addition to relative folders and wildcards, you can assign tags to each line, when loading a project, you get to choose which tags to import, either inclusively or exclusively. First, let’s see what the tags look like, here’s the simplified project structure I used in the demo video:
ROOT=E:/DATA/Projects/
PROJECTS=/setups/*/*/
/3D/*/*/*/*/&3D&HD&SD
/source*/SD/*/&Source&SD
/source*/HD/*/&Source&HD
/render*/*/*/&Output&SD&HD
Each tag is preceeded by an ampersand (&), a tag can occur on any number of places, this way you can specify intuitive combinations of tags to import what you want. Exlusive import means all tags have to exist on a path for it to be imported, exclusive import with tags “Conform” and “HD” will not import the SD directory, on the other hand, inclusive import with the same tags will import everything that is listed under both Conform and HD. Choosing only one tag works similar to inclusive.
The folder tree is basically a node tree. It can have any number of root nodes, which are all saved at exit and reloaded on startup so you can find the folders where you left off. It works both as a folder picker, and as an import tool. It features a small overview window at the left bottom corner in case your root nodes are off screen. They can also be re-layouted with the L key. For minimum amount of cluttering, there’s an option to ignore empty folders which are common in project structures. You can also hide folders you’re not interested in, and create a new root node from any node in the tree and use it as a starting point which will give your tree a clean look. Once found, the “rootballs” stay where you want them.
The file wrangling menu, or tool menu, is a set of common tools for managing sequences of files, especially when you have edited your clips into something that only exist in the desktop. Commit lets you generate a new file sequence from a clip on the desktop, it’s very fast because it only copies files and names them into a new sequence. However, if you’ve mixed formats and resolutions this doesn’t really work. For this, use the Reformat options. It will rescale and convert the input sequence and output a new homogenous sequence which nobody could object to. Also useful for making proxies and previews. There’s also a sequence rename tool, an erase tool and a tool which pops up an Explorer window with the current image selected. All wrangling is run in threaded processes, which means the application doesn’t lock up while it’s processing.
Project file linking, is a way to quickly backtrack to the project file that created the clip you’re looking at, usually a render from a compositing application. When named the same, project files are linked up automatically when loaded though the project menu. There’s still improvements to be made here, but it’s a start. The other way is to manually link project files but dropping files from Explorer onto a clip. All supported program files can be dropped, so a single clip can hold links to 3D scenes, 3D tracking projects, compositing scripts etc.
Command line options are alos introduced here, initially there are just a few options, but they each serve a purpose.
Import and player are similar, both imports a clip to the desktop, but -player also opens it in the player right away. The accepted format is c:/path/file.%04d.ext,1,100 which is the same syntax as Nuke uses, plus start and end frame separated by commas. The zero is the padding character, and the 4 stands for four number padding, so frame 23 resolves to 0023. The -folder switch lets you import a folder, which can consist of wildcards, so -folder c:/path/*/*/ will import everyhing two levels below path. Size sets the size of the application window, default is maximized, and -help shows the list of available commands.
Other enhancements include:
I think that covers most of it, feedback highly apprecieated!
Credits:
-The flipbook script in Nuke is based on Diogo Girondi’s djv_this script, thanks
-The Vanilla Pudding material comes from the Shake demo material and originally from Wild Brain Inc.™
I’m currently working on a feature to link project files such as .aep, .shk and .nk to image clips so you can launch the script that created a particular clip, track its history so to speak. I’ve thought of a couple of ways how this should be paired, the first one would be name based, the second manual, ie drag-drop a project onto a clip, and the third one would involve parsing project files to find output names in fileOut-nodes and match those with clips on the desktop. I’m not sure how that would work with After Effects though, since its project files are binary.
To locate the actual project files I’ve added a tag in the project structure file which lets you point to where project files are stored relative to the current project. VfxDesktop is turning out to be quite project based, I think this opens up some doors for management and pipeline. Once a list of supported project files are found, it can be paired to existing clips. The first way I’m implmenting is by name, so that would be:
shot01_v01.shk would be paired to shot shot01_v01.#.tif, basically whatever’s before the first period. This will require strict naming when you’re working which is it’s not ideal. Having the application dig through the script files for outputs would probably be more automatic, but that is probably limited to those apps that have text-based project files.
I’m sure there are more sophisticated ways of dealing with such a link, if you have ideas, I’d love to hear them!
What’s the hold-up, you might ask? Well, one thing I’ve been struggling with for some time now is that the way SDL handles the OpenGL contexts is quite horrible. Resizing the application requires a reset of the SDL video mode, I guess it makes more sense if you’re making a game and switching between fullscreen and windowed mode, but even then it doesn’t make sense that the context would be destroyed, because the result of that is that all viewport setup, GL modes and most importantly the texture handles are destroyed in the current version. A complete reload of all textures isn’t acceptable.
Not even SDL 1.3 Beta has this fixed! However, I found a custom version of SDL which seems to solve this, so now the window happily resizes, while keeping mouse coordinates and textures intact! So, one issue down, several to go! If this solution doesn’t hold up on other platforms, I may be forced to convert to another library anyway, I’ll try this one out for (re)size.
The other issues are a few yet unexplained but repeatable crashes, some potiential memory leaks and an odd problem where the application gets extremely sluggish when creating new texture handles (I suspect), so far I’ve only had this with long sequences, 2000+ frames, and it only sets in after a while if you scrub violently! Debugging was never easier.. 
I’m currently trying out some changes in the GUI, trying to give it its own look and improve workflow, trying to innovate past the previous design. I’ll post another video soon for some feedback! Alpha is nearing…
I thought I’d tell you a bit how I deal with projects right now. One way of importing stuff is dropping into the UI as seen in the video, but there are currently three ways of importing material.
The first one is the original way. Pretty early in development I developed a simple tagging syntax which you enter in a file called “dirs.cfg” which lets you define a generic directory structure which the application will parse and then import everything it finds.
The only thing you really have to define is the project root directory, or fileserver. On start-up, all folders in that root will be saved in a list and considered to be a project, in the application you can step between these projects with Ctrl+Arrows, then simply hit Enter to load that project.
All disk access is handled through Boost’s filesystem lib, so all paths are cross-platform, supports relative paths and it’s ignorant to forward- Vs. backslash paths. I’ve created my own wildcard feature as well, so your project can for example have multiple shot-folders or 3D databases changing from project to project without redefining the structure. The last feature is a custom token, which behaves like a string variable, all occurances of $ will be replaced by the token. Lines with leading double-slashes will be considered a global path, single-slash will be relative to ROOT.
#Example dirs.cfg:
ROOT=//fileserver/projects/
TOKEN=shot
/3d/xsi_*/Render_Pictures/$*/
/3d/maya_*/Renders/$*/
/3d/Assets/*/*/*/
/Material/Confom/*/*/*/
/Comp/Renders/$*/*/
//workstation/C/project/stock/*
If you have a structure configured like this you simply press Enter in the application to load all footage in the project. Then you can start sorting and sifting and organize stuff into different desktops. The idea is that if you don’t know where a specific image or seqence ended up in a project you can always hit enter to get a full overview. The loading process will sort each matching directory with images into a new reel. The initial load may take a while because the first cache need to be generated, the next load will be much, much faster as the application always consults its local cache before actually reading any files from the source. Tagged on to each cached jpeg is a filedate and its original resolution, when filedates differs from the original, it’s recached automatically.
So, the second way of importing is pretty straight forward, you pass any file or directory as an argument. The easy way to do this is to drop something on a shortcut to the application. The good news is that argument loading also supports wildcards, so you can edit your shortcut to say something like:
vfxdesktop.exe \*\*\*\
This will make the desktop load your dropped folder plus three levels deep under it. That way you can drop your “Render_Pictures” folder and have each subsequent shot-folder load in a separate reel.
The drag-drop is straight forward as demonstrated in the video. Dropping folders is recommended, dropping a single file will import only that file and not the sequence it may be a part of, but that feature is on the list.
Wow, fantastic response from the community!
I’ve been reading all of your comments with delight, both here and on Vimeo and in a couple of forums. I’ll try to answer some questions here!
Mr Rotobastard among others had some good points, number 1 is sort of already in place, I have a system for defining a project structure and bring in all material in the whole project. You just need to supply your root project folder and you can step between projects, I’ll show this in a post soon. Nothing specific for versioning yet though!
Command port sounds good! I’ll have to investigate how that works.
I intend to look into gamma preview sliders and such in the player, and also black bars and flip/flop and other transformations, it’s all realtime in OpenGL anyway. A LUT would of course be the next step there.
Export is definitely on the list, basically a commit to disk-feature for your edits, also multi renaming and moving of files. One of the mantras I’ve had in my head while developing this application is “The end of browsing!” For each feature I add, I make sure to stick to this basic idea, hopefully you’ll never find (or need) a browse dialogue in vfxDesktop, however you may have to manually type in your root project directory/file server the first time you run it!
How does the glue to the apps work? Will, I’ve taken a look at each application to see how to interface with it, and some apps only allow one instance, and can take files as arguments, those are the easy ones! Photoshop for instance. For After Effects it’s similar, but I needed to generate an AE script to import, but it allows importing in an existing instance of the application so it works smoothly. Boujou and Mocha is very simple, they only need a frame passed as an argument. For Shake and Nuke I decided the easiest way is to generate scripts which you simply paste into the respective applications to get Filein nodes.
Some of this stuff is Windows-native code, such as drag-dropping into the app window and using the clipboard-buffer for pasting, but it’s separated in the code for the day I venture into Linux-land. My libraries should be cross platform, all filesystem interaction and threading is written using Boost, and the whole UI is written using OpenGL, so the core stuff should definitely work.
Then there’s been a lot of questions about beta/licensing/open source and such. I definitely want to get it out there for you all to try! I’ll do my best to whip up a version which is suitable for an early alpha-preview. At this point, there are some features which are half-complete, and I suspect that you all will find problems which I could never anticipate! I also have a feeling that this application might change shape slightly to avoid stepping on some obvious toes. I call for your ideas on this, it will help making it public!
Keep posting your suggestions, thanks everyone!
First post!
On this weblog I intend to talk about the development of a piece of software that I’ve been writing on and off for the last 10 months or so. The purpose of this application is to fill a void, I can’t seem to find an existing program that does what I want it to do, so I’ve been brushing off the old OpenGL and C++ knowledge that I have to try and create it.
So what is it?
I call it the vfxDesktop, its main purpose is help anyone working with images and especially image sequences to get a good overview, to be able to play and scrub their clips, and also to make basic editing to watch a sequence of clips together. The other big purpose is to serve as a springboard to help importing these clips into other applications, such as Shake, Nuke, Boujou, After Effects among others. So overview, preview editing and importing.
I’m especially interested in innovative user interfaces, so I take influence from everything existing that I like and try to improve it. I’ve choosen to write the whole GUI in OpenGL to have full control over how interaction works, plus it’s well established and works across many platforms. At this point, there are no ports, only a Windows version, but I’ve tried my best to keep the code portable. One day I guess we’ll see if I succeeded in that.
If you’re working in visual effects in a desktop environment (ie. software based on regular PC’s), maybe you’ll find this interesting, I will show the interface and show you how it’s meant to work soon.
