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.
- Through pre-defined project structure
- Through start-up argument
- Through drag-drop
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.
May 9, 2009 at 14:33 |
I wonder how EDLs are supported and what kind of effect that has on importing.
Cheers
Blazej
May 9, 2009 at 14:41 |
At this point, it has no effect on importing. EDL only searches the clips already on the desktop for matching timecodes, currently the only way is to have TC in the filename. Full EDL support or even XML support will be a major feature to implement, it’s still early in functionality. One problem is that very few formats have embedded TC, it will probably have to be assign manually in some cases.
May 10, 2009 at 20:26 |
Hey Arvid, the original way seems to be the most appealing and project friendly… as long as the project is well organized. I thin it will be good if you take this one step further and implement the automatic creation of reels and desktops based on naming conventions and directory structure. For example:
I have three paths:
/job/shot_001/publish/images/2d/precomp/car_01/v0001/2048×1556/dpx/car_01.%04d.dpx
/job/shot_001/publish/images/3d/lighting/car_01/v0033/2048×1556/exr/car_01.%04d.exr
/job/shot_002/publish/images/io/plates/bg_01/v0001/2048×1556/dpx/car_01.%04d.dpx
From this structure we know that our assets will be always at a specific level in the folder structure and they can be easily parsed. This way should be fairly easy to import the images already organized… lets say one desktop per shot and one reel per task (in this case the task is defined right after the folder named ‘image’). So in this case we will have two desktops:
desktop 1 = shot_001
reel 1 = precomp (with version 1 of car_01 loaded)
reel 2 = lighting (with version 33 of the cg render of car_01)
desktop 2 – shot_002
reel 1 = plates (with the plates of bg_01 version 01 loaded)
in thi example there is also other information the can be usefull… resolution, version, image format etc. This way you can tell vfxdestop to load only lets say the last three version of all the images that are dpx and just the full resolution.
Another feature that could be interesting is something similar to what SCRATCH have for auto importing images coming from different software. Basically there is a folder that vfxdesktop can “watch” for XMLs containing information about images sequences and where they should be places in you desktop/reel. From inside any software… lets say nuke… the artist will select and image and will “send it” to vfxdesktop. This sending action is basically the creation of the XML based on either information the artist specify manually or where the images is placed in the directory structure. Then inside vfxdesktop you can hit an ‘update’ key and a new clip will be created in the right desktop/reel based on the XML info.
This is what I was thinking when I talked about pyhton integration, since this is all a peace of cake for pyhton to handle.
I hope this make sense. Please be aware that I think that your software seems to be very useful as it is. I think that the key for integration is flexibility for either doing simple manual imports of for autoimport clips with predefined tags in a deep folder structure… your app seem to go in that direction.
May 10, 2009 at 23:30 |
Very interesting thoughts! You gave me some new ideas! I could for instance extend my tagging syntax so you can define things like what you’re talking about, versions, resolutions and such things, perhaps even save multiple custom project definitions, say one definition that only loads 2K and another that loads all, or some other attribute. I should also have a saved desktop actually contain multiple desktop screens, I’m thinking something similar to tabs in FireFox.
The number of reels is unlimited so you can have tons of reels with one clip each and scroll through them, but that’s not too practical, users would probably rather flip through some preset desktops in a tabbed manner. Perhaps the nine quicksaves should be project-specific as well, so when you switch projects, you get 9 new ones.
Good stuff
Things like these will make this program unique enough to live on its own merit, and not what it was inspired from in the first place, like jean-luc said in the other comment thread, flame’s reel workflow is kind of out-dated, it can be improved upon, and no one owns that, yet! 
Oh, and currently you could set up a project structure that looks like this, for example:
ROOT=//fileserver/projects/
TOKEN=2048×1556
/shot_*/publish/images/2d/precomp/*/v*/$/dpx/
/shot_*/publish/images/3d/lighting/*/v*/$/exr/
/shot_*/publish/images/io/plates/*/v*/$/dpx/
This would bring in all versions of all shots, but only in full resolution, and would work in any project if your structures are consistent. If I extend my tagging syntax to have more custom variables you could define version numbers and stuff, and a useful feature would then be to have multiple definitions to choose from. You could have a preset definition called 2K_3D, and have that only bring in 3D of full res, or something along those lines. Just thinking out loud here..
Watchfolders is a good idea too. Perhaps I could make that another tagging feature. To me, the project-loading way of importing is quite useful, but loading by argument and D’n'D is great for previewing stuff, and especially when trying to locate a specific sequence in a huge heap of folders, just drop the whole thing into the desktop and find what you’re looking for visually, it becomes really useful to be able to parse x number of directories deep if someone’s been sloppy with naming and structure.
May 11, 2009 at 04:53 |
I’ll be more careful with my spelling this time…
Yes I realized that vfxdesktop could already do part of what I was talking about after I finish my last post and re-read yours. Thats awesome. The ability of having nested desktops inside desktops will make this software very robust. One thing dailies applications like framecycler, scratch and rv are lacking is a flexible way of organizing clips in a producer/vfx supervisor friendly way. Nested desktops will mean that you can have your whole project organized in sequences, shots, tasks, assets, components, versions, or whatever. Scratch (and now generation) are in my experience, the more flexible ones in this respect (specially with their ‘stack’ philosophy), but they fall short because of the limitation on how deep their project structure could be. However their ‘stack’ philosophy is actually the best way I have seen for going thru versions so far.
From the artist point view, proxies is a very valuable feature to have when you are running in a non disk array/low memory system.
Im afraid Im going too far ahead… Ill stop talking now.
May 11, 2009 at 13:57 |
Nah, keep it coming! I mean, wont be able to implement all this in a day, but I like planning ahead and seeing the bigger picture, and discussing ideas.