Show with multiple scenes

I have a show put together with multiple scenes for different visual looks. Currently they are all contained within containers and I switch between them with a script that is used to turn on and off cooking depending on which scene I call.

Since touch is 32bit, this means I can only take advantage of a certain amount of ram even though my machine has over 10gigs.

Would it be worth while to look into running each of my scenes in a separate instance of touch designer and using a master instance to do the final compositing and switching between each of the scenes? It seems like this would allow me to take advantage of more CPU cores and RAM.

Are there any concerns with reliability in doing things this way?

Are the Touch IN and Touch OUT TOPs 100% reliable and considered show worthy?

Are there any other methods I might look into?

Thanks!

Do you need a seamless transition between each scene or can there be a pause?

About multiple instances, if you do it, you should use shared memory and not socket based data sharing.

But you can only bind touch to a certain gpu with quadro cards. With GeForce cards, you should not launch multiple instances at the same, as it will cause the driver to slow things down . Hmmm, if you auxiliary instances are not displayed and only render to shared memory, it might work. Not sure, better see what Malcolm has to say.

Thanks Achim,

Yes, I am using Quadro cards so that’s not a problem. A slight pause between scenes is fine. No longer than 10sec would be preferred though.

-Matt

I thought touch could run as 64 bit? I obviously haven’t pushed my stuff far enough lately. :slight_smile:
rod.

Then you could use gpu affinity and shared memory …

But if a pause is ok, then just save your scenes out as tox files, and use a script to replace the currently loaded tox/scene with the next …

How much CPU memory are you actually using? If your not crashing Touch by using to much ram then I don’t think you’ll see any performance difference by having the containers loaded or not in the same instance. The only time I ever had a problem with using to much ram was once when I had hundreds of moviein’s in a project and I would cycle through all of them. I got around that by using the unloadmovie command when each movie was no longer being played. The only other thing that I can think of that would take up a lot CPU ram could be models with a high number of points, I don’t know if you can unload them.

If you want better performance whether it is a GPU or CPU bottleneck using two instances of TD can increase performance if you were to split your heavy comps between the two instances. In the project I’m working on now I’m using two instances (maybe three at one point). The first one generates my scenes where I have multiple containers with different scenes. It runs at anywhere from 30 to 60 fps depending on the scene. The second instance gets the output of the first instance via sharedmem TOP which then does more 2D processing on the stream for final output. It runs at 60 fps and I can’t really add any more processes to the signal with losing speed. If I were to combine both into one project I would get less than 30 fps on even the light scenes.

Ah nice! This is some very useful information.
So if i have one project running a “media server” sending the output to another show running a “tripplehead cropper” (using 3 special vertical monitors), i could gain some performance?

You wont get any benefit in that case, the GPU is still doing all the work. Splitting processes helps you with CPU performance and stalls mainly.

I should have been more clear. I actually meant running two instances on two different graphics cards using GPU affinity. In that case I’ve definitely seen performance improvements with GPU bottlenecks but there is also a performance hit with the sharedmem TOP.

Ah yes, with GPU affinity you’ll can get gains, but you’ll want to be doing some heafty work to make it worthwhile. Cropping is a super inexpensive operation so you wouldnt gain anythin from that case.

I don’t know if it is still an issue for anyone, but I can share our approach to use many scenes in one TD:

  • all the scenes are off by default so that the scene does not use any ram or whatever;
  • there is an empty container called OUTPUT;
  • every time you need to play any scene you just put its name into clone parameter of the OUTPUT;
  • when you change this parameter to another scene TD erases all the ram and video ram and clears everything, then it loads a new scene;
  • all scenes have top output out1, so that whatever scene is used as a clone OUTPUT is always connected to the further nodes in pipeline (mapping or anything else)

So, actually all scenes stay off during the show, active scenes are just clones.

Hope this will help

1 Like

Hi,
can you post a small example of this. I’d like to use the approach to see if is suits me but am not sure how you are changing the master scenes from ‘off’ to ‘on’ so neatly.

Thanks,
Ian

Hi, I found the info from 3dbill is very interesting(thank you for sharing!) and made some test tox(attached)
I was hoping that I could make smooth switch/loads of component with this approach. But I got slight pause when I change the source component. Also I had crach when I switch component very quickly… Does anyone know another nice idea/way to change component dynamicaly&safely?
loadSwitchCompTest077.tox (66.3 KB)

I personally found using the clone method not to work very well. I have two solutions depending on the requirements.

#1 fast load, uses memory for each comp and doesn’t release it:

  • load all the your components that you need and have them all cook once in order to load them entirely into memory
  • then use selects or switches to switch between components
  • when not switched in, set cooking to off so absolutely nothing cooks when they aren’t be used

#2 uses not as much memory (if using the same comp in different places at different times)

  • rather than using the cloning method write a script the uses opcopy and oppaste commands to copy and paste your components into the desired network

hope this helps

Thank you for your clear advice Keith, that’s a very helpful information!

I am confused what people are talking about as far as turning scenes “on” or “off”. Can someone give me a clear answer on that. I would like to make a container component and everything inside it go completely inactive and free the memory of all nodes inside it.

Were basically saying to set cooking on and off for a container which must be done with scripting. the tscript would be to turn on and off cooking:

opset -c 1 container opset -c 0 container

setting cooking off will completely disable cooking on all ops in the container

to clear the memory you’ll have to reduce the resolution of all the tops to 2x2 before you turn off cooking.

Question: how does one turn off cooking with Python?

Statement: It seems strange to have to do something as hacky as reducing resolution to 2x2 in order to achieve such an obvious need as clearing the memory. o_O