You’re finally ready to do a big gig, or a medium gig, or just a gig. After months of practicing and playing you’re feeling good about your creative work, and you’ve got a solid idea for the artwork in your installation. There is, however, one major catch. You have to calibrate a bunch of a projectors… five. When you started working with TouchDesigner you were initially excited about the artwork and interactivity, but now suddenly you’re facing the reality that you need to build out some tools (or at least modify some existing ones), put together a UI, and think through how you’re going to organize a project that goes beyond just experimentation and exploration.
Revel in this moment; it’s the start of a whole new set of challenges and considerations, and it’s also the beginning of a move away from tinkering to considered building.
In seriousness, where is this coming from? Recently I had the opportunity to help a team at a University that was putting together an installation in South America. Unfortunately, I didn’t have the time to do the whole project but I did have enough bandwidth to help get a calibration interface and pipeline set up so their creative developer could focus on the artwork and user interaction elements. Building calibration interfaces isn’t sexy on the face of it, but when calibration is working well it takes a tremendous amount of pressure off the creative end of the project. It also allows us to define some fixed elements in the project, establish some modular elements, and define an architecture.
“Sounds like lima beans to me Matt.”
That’s okay, but after you’ve found yourself working on a handful of large projects each time both trying to understand how to calibrate a system of multiple projectors and deliver interesting artwork you might feel differently. Before thinking about the cool art you’re going to make, you might well find yourself thinking carefully about an efficient calibration pipeline that has as little overhead as possible so you can make even cooler art.
The Setup
Equipment
- One Computer
- One Control Display (1920 x 1080)
- 5 Projectors (1280 x 800)
Lucky for us, we only have to work with one machine on this project. At some point I’ll talk more about using networked machines, but the nitty gritty of that calibrating process can be a bit dicey. It’s better for us in terms of examples, and also in terms of our sanity, to first be able to talk at a real world example where we get to use a single machine for this. Our architecture is also very straight forward this time around. The environment is designed as a five sided room with flat walls for an immersive installation. Our projection doesn’t require any edge blending (which is great), and instead we really only have to think about quad displacement.
On the face of it, this might sound boring. If you’re feeling that way, good. “Why is that good Matt?!” It’s good for us to feel like it’s boring because it limits the number of issues we need to take into consideration. By the end of this we’ll see that this is far from a simple problem, and that by first mastering a smaller set of challenges we’re better prepared for how to think about additional needs that arise with more complex architecture, and overlapping projection.
A Bird’s Eye View
Digging into a project like this it’s important to take the time to consider how various pieces are going to work together. After a few years and lots of big projects developed in TouchDesigner you’ll find that there are a handful of important considerations you’ll need to take into account when developing in this environment. Regardless of where you do your development you’re bound to find these oddities or tricksy peculiarities. That’s okay, in fact, it’s probably good. For all the grief these small nuances may cause you, the more you find them, the better you’ll become at understanding how to work around these issues, or exploit them. Most important in this project was first understanding what considerations needed to be made in order to ensure that we ended up with a high performing and stable underlying structure:
- the UI carried as little computational cost as possible
- the calibration could be saved and recovered regardless of the toe file
- the build was modular as constructed with support for the contributions of other developers
- the build, by it’s nature, was structured to take advantage of using git as a version control system
- the UI could be modified with additional components and panel elements from other developers
- the UI contained test patterns for fast and consistent calibration
- the UI allowed for previs from multiple vantage points when the projectors were not on
- the UI contained complete stand alone application features like a help button, and a button to close the application completely.
Having as complete a sense of what you can before starting the programming on a project is something I can not encourage enough. Scope creep, as it’s sometimes called, is when features are continually added to your project in that “wouldn’t it be nice” kind of fashion. In many cases, additional required features would in fact be nice additions, but should always come after the initial set of agreed on pieces are finished. It’s not always possible to do that when you’re first starting, and sometimes features legitimately get forgotten but to the best of your ability it’s important to take the time to identify what a given application needs to do as a bare minimum and to start there.
Finally, it’s important to realize that in a project like this one the operator isn’t the original programmer. So while it might be easy for me to make an adjustment or dive into the TouchDesigner network to fix a tricky issue, that kind of expectation would be a deal breaker for an untrained operator. My background in theatre is a tremendously powerful teacher in this respect, as I never worked on a show where my operator would be expected to figure out how my programming worked. The UI needs to be complete, finished, and the complexities of its operation should be hidden from the individual operating the controls. That might seem like a tall order in some respects, but it’s one worth aspiring to in all cases. Opening the network during a show, or working in the network during a live show (unless it’s planned) should always be avoided. In the work that I do, live programming during a gig unless I’ve already planned on this, might as well count as a failure. I say this because what it represents is an incomplete build of the system, and / or an incomplete understanding of the project. I strive to build complete projects that don’t require live editing, and even though it’s a difficult task I would encourage you to do the same.
Software Architecture
Big Ideas
Organization Matters
How you build a thing matters. Ask any architect, chef, crafts person, quilter, and on and on and on. The principles and ideas that drive how you’re building your network matter, and as a full disclaimer I am a misery to collaborate with when it comes to messy TouchDesigner networks and messy directories. “As long as it works, it doesn’t matter Matt!” Is the mantra I often hear as a push back to my requests for organized work. There’s a lot of truth in that, but if you ever have to work with another person (or work with your future self) then the organization of your work will matter. Cluttered, messy, or disorganized structures will make a world of misery for you and your collaborators. You can do whatever you want at the end of the day, but my strong recommendation is that you create some guiding principles for your organization structures, network layout, documentation, and pending todo items on a project.
Here are some of my simple suggestions:
Turn off node resizing for TOPs and COMPs, and don’t resize your nodes by hand:
What? Why? Those things might make perfect sense to you, and you might like them a lot – and that’s great. I hate them in my networks because they insert irregularities into the flow of the network that spoof importance. When I look at a network and there is a single node that’s larger, smaller, resized in anyway that’s different from the surrounding nodes it implies to me that it has some significance or importance. It might well be that you just needed a closer look for a second and then forgot to change it’s size again, but for the person looking at your code for the first time that it’s significant – even if it’s not. Time and again I’ve seen that kind of use of resizing throw off myself, and many of programmers that I respect.
If you need to use size as a defining characteristic in your networks, then use python to make nodes consistent sizes. It all goes back to being organized and consistent. Help your future self, or the other people you’re working with avoid as much confusion as possible… chances are the project is already confusing enough.
Align your ops:
I like the left bottom corner of my ops aligned with the network grid. I like to start new ops on new grid lines, and I like a full grid line of vertical space between ops. I also like to arrange ops (when possible) so that wires don’t cross unnecessarily. OCD much Matt? Sure, you can say that if you like. For me, the truth of the matter is that I like tidy networks where I can quickly see the flow of operations left to right. Too much space and things feel spread out all over creation, too little space and it can be difficult to see a network’s operation when you’re zoomed out too far. For me, this is the right kind of balance. It might well be different for you, and that’s wonderful. My only encouragement here is to be purposeful. Whatever you do, make sure it’s a choice you’re making not just the happenstance layout that emerged from the creative process. Be messy, be wild, place nodes every which way … but tidy up before you save and commit your work for the day.
Color code sparingly
I love me some color coding, but make sure it’s done purposefully and give yourself a key. This is another situation where color coding is often a great idea on the face of it, and then it quickly changes into something you can hardly keep track of. That’s okay, and my experience has taught me that less is better in this regard.
Leave those op names alone and only append after the op name
It took a lot to get me on board for this, but it’s now something that I’m whole wholeheartedly behind. Leaving the original operator name in place and only appending after is a tremendous help when it comes to quickly glancing at a network. It helps the viewer know quickly what an operator is doing without having to do any additional inspection.
“I don’t get it Matt.”
That’s okay. Let’s look at this example:
In 2 seconds or less can you tell if the first operator with the banana is a select or a moviefilein TOP? Can you tell if the composited image is a comp TOP or a multiply TOP? Can you tell if the TOP labeled “done” is a null or an out TOP?
Compare that with:
To be fair, the names aren’t nearly as exciting, but they do make it much easier to understand what’s happening at a glance.
Like it or not, you’re an engineer now
As much as we all might like to fancy ourselves Artists with capital letter As and a filigree flourish, the truth is that right now you’re an engineer. That’s not to say that you’re not an artist too, you are; but some problems don’t need artful solutions, they need thoughtfully engineered solutions based on a complex understanding of computation and computer science. The more you work in TouchDesigner, the more you’ll find that you’re as much engineer as you are artist – that’s not only okay, that’s an important realization to make about your own work. It can be a bifurcating moment to feel at conflict with the art, and the mechanics of a given network – “this approach is beautiful and it works but costs 20 milliseconds” is probably not a viable solution. It’s especially not a viable solution for something like a calibration pipeline that needs to have as little computational overhead as possible. The work that goes into an efficient process isn’t always glamorous, or much to show off; instead, it makes room for the art with a capital A to take more cycles and be more expressive.
Lucky for us, there’s room to be both engineer and artist in our work. Remember to embrace both of those roles, even when faced with the frustration of complex logic problems, or when faced with the questions of aesthetics.
Externalizing Files
So we should externalize files? Yes. For the love of god, yes. If you believe in a world where you don’t tear your hair out, yes. In case you still are wondering, the answer is yes – you should always look for ways to externalize files.
Why? That seems silly.
Once upon a time I didn’t externalize any components, and my projects lived as complete toe files and the world was beautiful. Then I crashed my project because I did something silly, and then it took me hours to track down where the problem was… even opening the crashautosave.toe left me slowly moving through networks in networks trying to figure out what I had done where to make everything crash. Worse yet, because it was just a single toe file there was no way to unit test any of the smaller modules. Open, change, save, open crash… repeat. If you haven’t had this experience yet, it’s only a matter of time.You too will crash one day, and mightily. You’ll wonder why you ever wanted to work with computers in the first place, and why you don’t just open up a bar in on a sandy beach somewhere.
Snark aside, externalizing components in your network has several benefits. For starters, it moves you away from having a single toe file black box that’s difficult to test or debug. Separating out smaller modules allows for more portability between the applications that you build, and it means that you can test just that module. It also means that you can update just that module and not your entire toe file.
Externalizing modules, extensions, and the like also lets you more easily compare files over time if you’re using a piece of version control software – don’t worry, we’ll talk about git in just a second. It also makes it easier to work with text files in something like sublime (my favorite) or Visual Studio Code. That might not seem like a big deal now, but the more you work with extensions and python, the more you’ll want robust text editing tools at your finger tips.
Externalizing files also reduces bloat in your toe file. If you’ve ever locked a texture in your toe file you know all to well that it your slim file size can quickly balloon. External files also makes it easier to save and try multiple configurations. We’re going to work on a building a calibration UI, we might want to be able to save a calibration configuration and then try another calibration. The same goes for configuration files. Rather than a configuration that’s locked into your toe file, an external file can make it easy to load lots of different configurations or other settings.
It might well seem like I’m belaboring this point, and I’m doing that on purpose. Working with external files is more work, takes more organization, takes better planning, and requires a more meticulous approach – but if you want to grow as a developer and programmer, you’ll wrestle with this challenge sooner or later. I’d encourage you to do that sooner rather than later.
git
What is git? Direct from the git website :
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
But what does that mean?! Unlike working with art where a tool like Dropbox would be helpful, when we’re developing software it’s often more helpful to be have some specific means of specifying when a file needs to be saved (probably with the same name), along with a message about what our changes have done. Let’s say we’re working on our calibration UI, we’ve made a change that now allows us to save out our calibration configuration. That’s great, but it’s come at the cost of changing a piece of how our UI works. We know for sure that the old way works 100% of the time, and we’re pretty sure that our new way works at least 80% of the time. Git allows us to check in the new version of our software, commit it to our working directory structure, and make a note of what we did.
We’re smart programmers, so we’ve also started to externalize our files. This means that we’ve separated out parts of our network responsible for different tasks. With git we’re now able to check in only the single tox that’s changed while we’ve been working. Better yet, we can even work with another person. Developer 1 might be working on one part of our project, while Developer 2 is working on another. Both developers are saving their respective tox files, and git allows us to track that progress and merge work seamlessly. If we do end up editing the same files, we end up with a merge conflict… which means what Matt? A merge conflict means just that, two files are competing for the same place in our directory, and we need to review them in order to decide which file to keep.
Git also allows us to work in multiple branches on our project.
Huh?
Let’s imagine that we find a bug, we might want to create a branch in our code to deal with resolving this bug.
Why?
Well, let us imagine a situation familiar to us all. We find a bug, squash it mightily. Only to discover that our fix has created another problem… maybe a much bigger problem. The little bug that we killed we could have worked with, but now we have a show stopper bug running a muck, that we don’t know how to stop, and the show starts in 45 minutes. Trouble shooting in another branch allows you to make fixes and then integrate them back into your project when you’re confident that they don’t create other problems.
Best of all, git creates a history that let’s us step back through each one of our commits. At any point we can return to a past state of our project. Taking advantage of modular design and externalized files makes this even more powerful because it means that with a little work we can resurrect ideas that might otherwise have been lost or discarded.
That’s a big commercial for git so far, but no cautionary tales – an cautionary tales there are plenty of. While git is a phenomenal tool, it can be a bit beastly to wrangle when you’re first starting – know that you’ll get frustrated, know that you’ll curse it, know that you’ll want to give up on using it, then count to 10 and give it another go. Like all things you’re unfamiliar with, take your time to get used to it as a tool set. You might choose to start by using a GUI tool, but at some point you should learn some of the commands to run directly from the command line. You’ll also want to avoid checking in any of your assets. These days I divide up my projects and separate my assets from my code. I have a few exceptions for this practice, but I try to keep them few and far between – only really allowing for template files, or grids. Essentially, I try to make sure that it’s only files that are going to change in frequently.
If you’re going to use git, you’ll probably also use something like github or bitbucket. These are great services and host your code online so you can get to it from anywhere. These services also come with some great tools for making action items, bug tracking, and maintaining documentation for your project. Take advantage of these tools.
learn more about git at https://git-scm.com/
start using git with github or bitbucket
See more comics from XKCD at https://xkcd.com/
Extensions Everywhere
I’ve talked plenty of about extensions, how to use them, and what they’re good for. I’ve had some spirited discussions about when to use Extensions vs. Modules, and there’s a healthy conversation to be had there for those who want to really get into the weeds of it all. The place I’ve finally landed is this – I use extensions anytime I want to extend the capabilities of a given component. Case to case the degree of extension varies – sometimes I take fuller advantage of using classes than others, and that’s okay. To me, it’s okay if I don’t always take complete advantage of the difference between Extensions and Modules. Sticking with extensions means choosing an approach that works for 99% of the use cases where I need more flexibility in my programming. For mean that means a little bit of stability from the Touch paradigm where there are almost always at least a handful of different ways to solve the same problem. You might like Modules better, and that’s okay. In this case study, however, we’ll see the use of Extensions.
We’ll also see a move away from fragmenting our code across our network. It’s often tempting to use a button deep down in a UI somewhere to perform a logical operation. The only catch is that now that script is buried deep down in your project somewhere, and should it ever give you problems, good luck finding it. For the most part, on large projects I aim to keep the lion share of my operations focused in an extension. This takes a little more time to write, but it means that things are more organized, easier to diff between check ins, that I can change my code in a single place, and that I’m writing functions that are callable from other parts of the network. In my experience so far, this little amount of extra work makes for a larger savings across the whole project.
More about Extensions
Python in TouchDesigner | Extensions
Understanding Extensions
documenting your code – what are docstrings?
I’m a broken record. I know, but really – leave yourself notes, voluminous ones. Better yet, when using extensions make sure to add some docstrings.
“What are docstrings?” you ask.
I’m so glad you did! Docstrings are a feature in several programming languages that allow you to embed comments or information into your code that can be inspected at run time. If you’re still scratching your head that’s okay. Let’s look at an example, this one is from the wikipedia page about docstrings:
""" Assuming this is file mymodule.py, then this string, being the first statement in the file, will become the "mymodule" module's docstring when the file is imported. """ class MyClass(object): """The class's docstring""" def my_method(self): """The method's docstring""" def my_function(): """The function's docstring"""
“Great. But why are these useful?”
There useful in lots of ways but for me they have some special importance. For starters, they help ensure that I’m documenting my code as I go. The more tips you leave yourself along the way, the happier you’ll be in the long run. It does make your code longer, and it does take more time. But, if you’re really invested in building something reusable that you can come back to and refine over time, these are solid investments to make that process smoother in the future.
You can get to these notes from anywhere. This internal documentation can be called from anywhere in the network, so if you’ve forgotten how many arguments your method takes, or what it is supposed to return you can get some quick answers without having to track down the extension. When you start to write lots of complex methods this can become a real help. It’s probably not something you need when you’re first working on the project, but if you’re collaborating with someone else or coming back to your project over time it’ll be well worth the time and effort.
Finally worth considering is that docstrings are a part of the larger Python style guide. Like it or not you’re an engineer, and at this point you’re turning into a budding Python programmer. Learning about the best practices of other programmers outside of the TouchDesigner silo helps broaden your perspective and exposes you to how other people work. For better or worse I spent a lot of time in the liberal arts, and one of the core tenants of the ideology that underpins the arts is that exposure to other ideas and perspectives is important in its own right. I’ve carried this with me through life, and I think even in the cases of programming languages it’s worth considering. The conventions and practices of any community teaches you about how they think of the world – how it’s organized, how it aught to work, how that group values the world, or what they don’t value. The Python community is one that we participate in, even if only mostly from our gray network of operators.
learn more about docstrings
see google’s python style guide for docstrings
Mapping out our Project
You know the saying – measure twice, cut once.
Before digging in to a new project make sure you ask a lot of questions, map out as many details as possible, and make a plan.
Okay, so what about our project?
For starters
- We know that we’ll have five projectors and one monitor that acts as a UI.
- We know the resolution of all of our displays.
- We know that we’ll externalize lots of files in our network.
- We know that we’re going to use git as our version control system.
- We know that we are going to work with other people.
- We know that we need to document our work.
- We know that we’ll need a way to control warping for the five different displays
- We know that we’ll need a few other controls – both for the mapping, and also to make space for the future UI elements to control playback.
- We know we need to previs the layout.
- We know that we’re looking to build out a complete application with all of the features that you might expect from that kind of build.
Whew! Okay, so where do we start? Before we start throwing down ops let’s think through a plan.
We’ll need a container that holds our UI, we’ll also need a container for each of our displays. We know that it’s best to just use a single perform window that spans multiple monitors, so we should make sure we plan for that when we’re developing our project.
We also need to think about how we’re going to set up rendering our scene so we can previs it without turning on all the projectors. That will mean a multi camera set up and some live rendering.
We should also think about how we might ingest video to display for calibration and test playback. On top of that we should also build out a test module to help the creative programmer understand the correct formatting for how to work in the framework we’ve created.
We should also plan to make some space in our build to house assets that are needed across our network, as well as a place to keep our calibration data. We’ll take advantage of the stoner, so we better make some time to pull that apart and better understand how it works.
We’ll use a few set of extensions, so we should also make sure that we know how that works before we dig in too deep.
Finally, we should make sure we know how git works, since we’re going to use that along the way.
We’re bound to run into some other things we need to suss out as we go, but this should give us a solid starting point in terms of understanding the project from a distance.
Next we’ll take a closer look at the stoner to make sure we understand this component we’re going to use, then we’ll dig in and start building.
Reusing Palette Components – The Stoner
As many of you have already found there’s a wealth of interesting examples and useful tools tucked away in the palette in touch designer. If you’re unfamiliar with this feature, it’s located on the left hand side of the interface when you open touch, and you can quickly summon it into existence with the small drawer and arrow icon:
Tucked away at the bottom of the tools list is the stoner. If you’ve never used the stoner it’s a killer tool for all your grid warping needs. It allows for key stoning and grid warping, with a healthy set of elements that make for fast and easy alterations to a given grid. You can bump points with the keyboard, you can use the mouse to scroll around, there are options for linear curves, bezier curves, persepective mapping, and bilinear mapping. It is an all around wonderful tool. The major catch is that using the tox as is runs you about 0.2 milliseconds when we’re not looking at the UI, and about 0.5 milliseconds when we are looking at the UI. That’s not bad, in fact that’s a downright snappy in the scheme of things, but it’s going to have limitations when it comes to scale, and using multiple stoners at the same time.
That’s slick. But what if there was a way to get almost the same results at a cost of 0 milliseconds for photos, and only 0.05 milliseconds when working with video? As it turns out, there’s a gem of a feature in the stoner that allows us to get just this kind of performance, and we’re going to take a look at how that works as well as how to take advantage of that feature.
Let’s start by taking a closer look at the stoner itself. We can see now that there’s a second outlet on our op. Let’s plug in a null to both outlets and see what we’re getting.
Well hello there, what is this all about?!
Our second output is a 32 bit texture made up of only red and green channels. Looking closer we can see that it’s a gradient of green in the top left corner, and red in the bottom right corner. If we pause here for a moment we can look at how we might generate a ramp like this with a GLSL Top.
If you’re following along at home, let’s start by adding a GLSL Top to our network. Next we’ll edit the pixel shader.
out vec4 fragColor;
void main()
{
fragColor = vec4( vUV.st , 0.0 , 1.0 );
}
So what do we have here exactly? For starters we have an explicit declaration of our out vec4 (in very simple terms – our texture that we want to pass out of the main loop); a main loop where we assign values to our output texture.
What’s a vec4?
In GLSL vectors are a data type. We use vectors for all sorts of operations, and as a datatype they’re very useful to us as we often want variable with several positions. Keeping in mind that GLSL is used in pixeltown (one of the largest burrows on your GPU), it’s helpful to be able to think of variables that carry multiple values – like say information about a red, green, blue, and alpha value for a given pixel. In fact, that’s just what our vec4 is doing for us here, it represents the RGBA values we want to associate with a given pixel.
vUV is an input variable that we can use to locate the texture coordinate of a pixel. This value changes for every pixel, which is part of the reason it’s so useful to us. So what is this whole vec4( vUV.st, 0.0, 1.0) business? In GL we can fill in the values of a vec4 with a vec2 – vUV.st is our uv coordinate as a vec2. In essence what we’ve done is say that we want to use the uv coordinates to stand in for our red and green values, blue will always be 0, and our alpha will always be 1. It’s okay if that’s a wonky to wrap your head around at the moment. If you’re still scratching your head you can read more at links below
Read about more GLSL Data Types
Read about writing your own GLSL TOP
Okay, so we’ve got this silly gradient, but what is it good for?!
Let’s move around our stoner a little bit to see what else changes here.
That’s still not very sexy – I know, but let’s hold on for just one second. We first need to pause for a moment and think about what this might be good for. In fact, there’s a lovely operator that this plays very nicely with. The remap TOP. Say what now? The remap top can be used to warp input1 based on a map in input2. Still scratching your head? That’s okay. Let’s plugin a few other ops so we can see this in action. We’re going to rearrange our ops here just a little and add a remap TOP to the mix.
Here we can see that the red / green map is used on the second input our our remap top, and our movie file is used on the first input.
Okay. But why is this anything exciting?
Richard Burns just recently wrote about remapping, and he very succinctly nails down exactly why this is so powerful:
It’s commonly used by people who use the stoner component as it means they can do their mapping using the stoners render pipeline and then simply remove the whole mapping tool from the system leaving only the remap texture in place.
If you haven’t read his post yet it’s well worth a read, and you can find it here.
Just like Richard mentions we can use this new feature to essentially completely remove or disable the stoner in our project once we’ve made maps for all of our texture warping. This is how we’ll get our cook time down to just 0.05 milliseconds.
Let’s look at how we can use the stoner to do just this.
For starters we need to add some empty bases to our network. To keep things simple for now I’m just going to add them to the same part of the network where my stoner lives. I’m going to call them base_calibration1 and base_calibration2.
Next we’re going to take a closer look at the stoner’s custom parameters. On the Stoner page we can see that there’s now a place to put a path for a project.
Let’s start by putting in the path to our base_calibration1 component. Once we hit enter we should see that our base_calibration1 has new set of inputs and outputs:
Let’s take a quick look inside our component to see what was added.
Ah ha! Here we’ve got a set of tables that will allow the stoner UI to update correctly, and we’ve got a locked remap texture!
So, what do we do with all of this?
Let’s push around the corners of our texture in the stoner and hook up a few nulls to see what’s happening here.
You may need to toggle the “always refresh” parameter on the stoner to get your destination project to update correctly. Later on we’ll look at how to work around this problem.
So far so good. Here we can see that our base_calibration1 has been updated with the changes we made to the stoner. What happens if we change the project path now to be base_calibration2? We should see that inputs and outputs are added to our base. We should also be able to make some changes to the stoner UI and see a two different calibrations.
Voila! That’s pretty slick. Better yet if we change the path in the stoner project parameter we’ll see that the UI updates to reflect the state we left our stoner in. In essence, this means that you can use a single stoner to calibrate multiple projectors without needing multiple stoners in your network. In fact, we can even bypass or delete the stoner from our project once we’re happy with the results.
There are, of course, a few things changes that we’ll make to integrate this into our project’s pipeline but understanding how this works will be instrumental in what we build next. Before we move ahead take some time to look through how this works, read through Richard’s post as well as some of the other documentation. Like Richard mentions, this approach to locking calibration data can be used in lots of different configurations and means that you can remove a huge chunk of overhead from your projects.
Next we’ll take the lessons we’ve learned here combined with the project requirements we laid out earlier to start building out our complete UI and calibration pipeline.
Putting it Together
Now that we have a fuller understanding of the project, how we’re going to organize it, and what existing tools we’re going to reuse, now we just have to put all the pieces together. That’s certainly no small feat, but it’s always easier to flesh out an outline for an essay, than to just write it off the top of your head. That might be an imperfect comparison, but the concept holds true. Once you’ve sorted out all the pieces and made a plan, it’s just about working your way down a punch list.
A small disclaimer for this post – As I’m writing I’ll be moving back and forth between doing some authoring in Windows 10, and on Mac OS. As such you’re likely to see small differences in the TouchDesigner UI. The public release of TouchDesigner on Mac is coming soon, and we’re already in the public beta stage of the process. I know many of you out there have been waiting for this moment, and it’s nearly here.
Matthew Ragan 