So for the past few months I’ve been putting together a bit of a realtime MediaServer System called Mara. As this is more of a personal project than a work project (our workflow is d3 with touchdesigner capturing in) I went in all guns blazing, no planning and building it as I went along. Every time I saw something I didn’t like with the system I’d simply rebuild the whole thing and because of this process it’s taken a bit longer but is much much neater than if I’d just kept adding and adding to it.
More recently I’ve finally completed most of my system and am now in Optimisation mode.
So here are some of the common tricks that people use when optimising, whether all of them are really beneficial is up for discussion but I’ve been implementing them anyways.
Get rid of references
This is not something I discovered myself but having lots and lots of expressions and references in parameters is not as efficient as exporting to or scripting to those parameters.
I decided to do a bit of a test on this and couldn’t really prove it to be true I tried out Idzs test on the TouchDesigner help group, it’s 100x more efficient. Unless you have a huge system you probably needn’t bother with this. Nonetheless I’d be foolish to not just get on and have it in the system. It’s also nice to keep things “stateless” too whereby any op can set a value on any other op quickly. For sliders this isn’t advisable as running a script every frame can get quite heavy.
The 2×2 trick
Back in the olden days when VJ’ing on my macbook pro with 256mb of gpu memory or whatever it had the only thing that would ever be quick was the rate at which your fps dropped as you loaded lots of generative effects. Movies are fine as they can be preloaded and unloaded at your hearts desire however this unfortunately doesn’t seem to be the case for generator TOPs. The solution is fairly simple. If we aren’t using a generator TOP we set its resolution to 2×2 or something very low and suddenly we get all our GPU memory back. There is one caveat to this though, the stutter when loading your entire network into memory is very ugly and can cause problems, so on more modern cards it’s probably advisable to just leave your generative bits and bobs loaded into memory if you can. You can also split things across a couple of TouchDesigner instances and this will certainly help out a bit too.
All those overs, multiplies and composite TOPs are never doing you any good really. A very elegant solution to this would be to check out
Keith Lostracco’s Archo-Ps? GLSL composite which uses one op for all your compositing needs. My own method is pretty much the same as that example but I’m generating my GLSL TOP from a bunch of table values, basically python writes the GLSL shader for me. The GLSL TOP scales with the system then and it’s much more manageable.
Keep your UI separate
I’d always suggest keeping the UI on another machine or in a seperate instance. It’s handier and much more scaleable if you need to fork out to other machines. It forces you to be a bit more disciplined and helps you when you need to start putting previz tools etc in. I’ve been very careful to take care of the little details in the ui too such as making sure TOPs scale with the UI (but not using expressions) and making sure that CHOPs are kept to a minimum. Only one type of UI element really needs a CHOP and that’s a slider, sometimes even they don’t need them.
One window to rule them all
Multiple windows are slower than having one big window. The general method most people seem to use is to have their containers and set their positions to wherever they need them in the window. For Mara I’m just throwing in a d3 style feed mapper so you can throw things wherever you want and split them up nicely.
TOP colour channel trick
Got a black and white movie? Then head to the common page and set your pixel format to 8bit fixed (R) and you’ve just removed everything except the one channel you need. This wont work with transparency but is really useful for fast UI elements.
Keep away from SOP transforms and materials
Why transform in a SOP when you can transform in a Geometry COMP? The reason for this being that transforms on the COMP supposedly happen on the GPU whereas transforms on the SOP level happen on the CPU. (or so I’ve been told) I’m actually very guilty of using transform SOPs because I’m a lazy noodler but it’s definitely one worth noting.
Applying a material to a COMP is much faster than to a SOP too.
SOP to DAT is also apparently slower than a SOP to CHOP so for SOP deformations etc too you’re better off using a CHOP than a DAT.
General Rendering Efficiency
Got more than one camera on one scene? Then use render selects rather than having 5 render TOPs. They’re much more efficient.
Projecting your project onto a building? Set your anti-aliasing to 2x rather than 4x and you’ll pretty much half your memory load.
Transparency seems to be a wee bit heavier than you’d like. Try and keep away from it
Use instancing in the Geometry COMP rather than the copy SOP.
Only cook what you need to. there’s no point in cooking more than required so if you have a level thats cooking and it can go further up the chain so it no longer needs to cook then put it further up the chain.
Anything I missed?
This article is kind of a work in progress so if there’s anything I missed you’d like to share let me know and I’ll add it in.