Category: <span>Software</span>

Published January 30, 2011 by

FXDesktop

I’ve always been disappointed with the lack of a decent desktop user interface for media management in visual effects software. Only Discreet/Autodesk’s Flame software has ever come close to perfection when it came to managing media, although it has stagnated over recent years with lack of true innovation.

I undertook the task of creating a “desktop environment” for media management with the single goal of proving to myself that I could do it. My FXDesktop was that application. Since it was merely a proof of concept I didn’t make it very robust–but it also taught me a lot about media management in the process.

Unlimited libraries, desktops, clips, reels, frames of multiple file formats, scrollable clips and reels, lots of fun trying to duplicate the Flame’s user experience. I designed it as a dotnet component, making it drag & drop-able into any dotnet application.

As a side-effect, I also now had a nice clip-viewing component that I have used in several other applications.

I never had any intention of taking it to market or implementing it in real world use. I basically tried to duplicate the functionality of the Flame desktop and I give all credit for the original design to the kids at Discreet that wrote the original implementation.

FXDesktop

Published January 23, 2011 by

IDEa

While writing the firmware for the circuitry in my SubSpace Pod, I learned to dislike the Inegrated Developer Environment, or IDE for the Parallax Basic Stamp. The Stamp seemed to have a large following but very little third-party support for programmers. I thought perhaps I could write a better IDE for their line of programmable microcontroller chips and possibly market it. It would involve writing some very complex code and low-level drivers for programming the microcontrollers (all seven of them) and would also give me an excuse to learn to build web sites.

The toughest thing was writing the low-level communications between my application and the stamp’s microcontrollers. This took about a month. Lots of critical timing involved in those little buggers and their serial interfaces. I built some hardware so that I could program and test five different basic stamps at the same time via the IDE.

This made troubleshooting the code much easier. I based the IDE (which I called IDEa) on a multiple-document interface. It allowed dockable windows, customizable user layouts, a complete solution/project manager that added the ability to create header/#include files, multiple source files, syntax highlighting & code folding, inline syntax help, code snippets, intellisense code, bookmarking, progamming multiple stamps at once. None of these features was available to basic stamp programmers until this point.

It worked great. Fast, full featured and far more user-friendly than the default IDE included with the Stamps. This is one of my cleanest pieces of code and I’m mighty proud of it.

IDEa for Basic Stamps

Published January 23, 2011 by

SubSpace 3D Digitizing Modeler

While at GTN our 3D/CGI department began to encounter a need to digitize cars and trucks for computer modeling. Like most things in our business, the first mention of something is usually within days of actually needing it. We quickly reviewed a couple of digitizing arms and scanners that were available but nothing had software that was optimized for the work we do. A couple of my coworkers suggested an application that they had used previously but it appeared that the software (originally called Hyperspace) was no longer produced and we were unable to contact the author. We discussed with a commercial developer having a custom plugin written to allow digitizing in Autodesk Maya but the cost was outrageous, and I frankly thought it would be more limiting to have the application dedicated to the Maya infrastructure.

I had designed and built two types of contact-based digitizing arms about 15 years previously; a project I had intended to market but lost interest in when confronted with the high costs of patenting and copyrighting. My interest in digitizing was reignited with our need for an optimized application for digitizing and I began to visualize how I would write such an application.

My coworkers and I discussed the basic needs on a Friday and I whipped together a prototype of the application over the weekend. Within two weeks we had a functional application and began adding features. SubSpace had been born and would evolve over the next few years as we did more and more digitizing jobs around the world.

SubSpace was written in VB.Net. Like all my current applications uses my SkeletonFramework plus some custom 3D code from a 3D Modeler I had written in 1991 called Vertex for the Amiga platform. I continued developing SubSpace steadily on my own for several years and continue to maintain it.

I recently refactored the entire program to neaten it up a bit and upgrade it to the newest OpenGL libraries for Windows. I quadrupled the speed of the application and added a bunch of new features in this, version 7.x. I’m really proud of how this program turned out and have yet to see anything even close to this efficient.

 

SubSpaceAll

 

 

The main UI consists of a Tools form that permits access to all main functions, and access to secondary forms with other functions. Bookmarks let you jump quickly between saved models or parts being digitized. Multiple Views let you see the parts being digitized from stored camera angles. A History form records everything you do for unlimited undo/redo capabilities. Stored Layouts let you configure the screen layout of the windows and recall those settings at any time. Presets allow customization of the buttons and keys of the digitizer and keyboard. The viewer is (with v7.x) a full OpenGL viewer and displayed the work being digitize with options for fog (helpful when trying to view distances) and simple lighting.

 

 

ToolBar

 

The main ToolForm with all it’s functions.

 

Main

 

The OpenGL Viewer. Text information is now full configurable and has drop shadows!

 

Prefs

Every app I write has tons of preferences so the user can customize everything to his or her needs. These are stored and can be quickly swapped with other prefs settings.

 

While using our digitizing arms (two Faro models) I thought it might be nice to have some type of wireless control of SubSpace for myself–rather than having to reach over to a laptop for control. I came up with an idea for a SubSpace Pod (or Pendant), a wireless controller for the application. I’d never done built or programmed any wireless hardware like this so I was immediately intrigued by the challenge.

I prototyped the whole thing using a Parallax Basic Stamp, some Bluetooth wireless circuitry, a twenty key matrix keyboard and a small LCD screen for feedback. I wrote the basic stamp code/firmware and created a two-way link between the SubSpace application on the laptop and the Pod. This allowed the LCD screen to display lots of useful info as well as allow user-feedback of selected function on the keyboard all without having to touch the laptop.

In the end, I rewired and miniaturized the whole thing into into a 4×5″ case and got the power requirements down to 9 volts–enough to make it portable and light. It works really well and was one of my favorite hardware projects.

SubSpace

Published January 23, 2011 by

Miranda Render Controller Suite

Miranda is a Render Controller Suite that I wrote. It began life when I worked at Traveling Pictures around 1999. We had the beginnings of a render farm, as series of computers designed to “divide and conquer” large computer graphics projects and were attempting some of the first photoreal 3D/CG cars. We used Houdini and Lightwave for our 3D work at the time and the render controllers at the time were either too limited or too expensive.

Having written a lot of code over the years I took it upon myself to write a render controller in my spare time. Since it was mainly for the Houdini renderer I called it “Harry”. Harry used a simple watch folder system for frames at first–anything placed into a folder named “waiting to render” would render. As I spent more and time on it, it evolved into a more capable system with priority/precedence based queues. About a year later we began utilize renderers other than Houdini’s so I changed the name of the system to “Miranda”.

What makes Miranda different from the other render controllers (there are about 12 out there as of this writing) is that it is designed with an overview of all jobs in the system at once. All other render controllers are “job-centric”–meaning that they can show you lots of info on any single job. Miranda show the status of every frame in every job all at once (provided you have enough screen real estate) giving you an overview of the entire facility. Miranda manages up to 400 machines and about 100 jobs very well–she was designed to give maximum control to multiple people in a medium-sized facility and works very well. It’s interface, a Timeline showing every job and frame in those jobs is still unique among the field. It is my longest running personal project and remain in constant use on two render farms at RingSide Creative and is always under continuous review for new features.

Miranda