Cortex: Introduction
Why
The VFX industry is fairly unique in the software development world: we're constantly doing cutting edge work and so require a lot custom software, and many of the people involved are highly migratory - moving between companies (and even countries) with each project. This leads to a massive duplication of efforts from one project to the next and between companies. Also, most of our development is unplanned (or at least under-planned) and often under pretty extreme deadlines, so the end result is of course a lower level of code quality. By getting together to work on these basic building blocks, and instituting some pretty rigorous quality controls on the published code, a lot of this can be improved without too much effort.
We're not trying to convince anyone to publish cutting edge technology for their competitors to use, but just to get people working together on the really common, mundane stuff, so that we're all free to work on the more exciting proprietary stuff (which one day may in turn become mundane). If widely used it also facilitates increased interoperability between all the different software we use, and between facilities - once an application can talk to Cortex, it can then talk to any other package that Cortex talks to. By writing your custom tools to use Cortex's base library of 2D/3D/math primitives and operations, it means it should be easily portable, rather than being coupled to a particular package's SDK or an in-house library that cannot be published.
Some of the potential benefits:
- Efficiency: No more 'reinventing the wheel' for common components
- Speed: Development times should drastically reduce by plugging these high-level components together
- Reliability: You can rely on and build upon this code, rather than just hoping it will work, or rewriting it because it is a mess or undocumented
- Interoperability: if anyone using Cortex has written some code to go to and from an app, then everyone will benefit. Soon everything will be able to talk to everything.
- De-coupling: if you code your new plugin to use Cortex's base classes rather than the host application's SDK classes, then it should be pretty easy to port to a different app
Here's a quick example of the kind of high-level functionality that the library aims to provide. Below is a RIB archive viewer I've been working on to prototype some of these ideas, implemented as a Python script (the C++ version would be almost identical):
import cortex
scene = cortex.getScene()
mainWindow = cortex.MainWindow(800,600)
viewWindow = cortex.View3DPanel()
mainWindow.addChild(0, viewWindow)
mainWindow.addChild(1, cortex.TimeLinePanel())
mainWindow.SplitVertical(80,20)
ribSequence = cortex.FileSequence("/tmp/turntable.1-60@.rib")
ribSeqNode = cortex.MeshSequenceNode(ribSequence)
scene.addNode(ribSeqNode)
viewWindow.frameAll()
scene.play()
By taking a handful of completely generic components and plumbing them together you suddenly have a very useful little tool for checking animated RIB archives that you've baked out. A full tumbling 3D view (mimicking Maya's controls), and animation playback with a timeline.
How
A small group of developers will drive the project and have write access to the source code repository. They will review and accept submissions from other developers, and discuss and take input from a everyone on the mailing list as to what needs to be done.
We understand that the high standard of cleanup/documentation/testing is going to deter a lot of submissions, so as well as accepting submissions directly into the library, we will also be providing a 'dump' area, where people can upload code in any kind of state. Code in that area will not be supported or compiled into the main library, but can be used by itself, and will hopefully be cleaned up and moved into the library at a later date. We're hoping this two phase process will work well, with some people creating code modules and others re-using them and knocking them into shape.
Also, don't worry too much about the Python bindings, boost::python takes care of most of the heavy lifting, it is pretty easy to get most things scriptable if they're well encapsulated.
If you're interested in being involved, please see the Developers page.
