Animating L-Systems and other complex SOPs

Hello forum user!

Here is a method I came up with to animate large generation growths of L-systems in real-time. Doing so from the lsystems SOP is seriously CPU expensive so I came up this component which saves out a sequence of SOPs and then hooks them up to a blend SOP which allows you to animate them from the component level.

It seems to be super effective so I’m wondering what the draw-backs are! haha Can anyone offer any tips on improving it? Any things to look out for (other than the space the models take up in the GPU memory I guess)? So far there are a few steps you need to take to render out the files and I’m wondering how much of that can be automated/simplified/optimized.

Let me know if you find this method cool or if it’s 2 wacky.
Thanks!
L-System Renderer.toe (8.55 KB)

Hi Owen,

Thanks for sharing the technique. After following the instructions, and creating a folder to match the folder path, etc I got it working and performance is smooth with 1000 TOG frames animating at 60fps.

My specs: TD 088 Build 62380, Intel Xeon E5 3.5Ghz with 16GB CPU RAM, Nvidia Quadro M5000 with 8GB GPU RAM, Intel SSD (SATA III)
It probably runs well on lesser specs but posting for reference in case performance varies.

As requested, some tips and related info on this:

  1. There’s no need for the Timeline CHOP, you can run the SOP animation baking entirely off the Timer CHOP you have. Then you can script the playback of the Timer CHOP with the custom parameters you have without all these extra steps to manually reset/pause/play the timeline.

As a general rule of thumb: Don’t rely on the timeline for your project to actually work, it can get very unintuitive and things can break easily.
ONLY use the timeline as a sort of debug mode you can enable a reference to temporarily to scrub through linear animations easily.

  1. You can script the realTime cooking state of TouchDesigner via the project class to turn off when baking the SOPs / TOGs, and then turn realTime back on when it’s finished. Typically you wouldn’t want to mess around with this but for projects that are not a “real-time system” and just a workflow “utility” --it’s fine. More info here:
    derivative.ca/wiki088/index. … ject_Class

  2. Set a default Filename and Folderpath in your Custom Parameters, and package up the entire project up in a ZIP file with the TOE and the default folder right next to to the TOE so it’s already there ready to go.
    e.g.
    Filename default: SOP_Frame
    Folderpath default: SOP_Anim

  3. Minor note: Looks like you are using a Switch SOP, not a Blend SOP as you said, which is good since you bake out a TOG with different number of vertices for a large number of frames and a Blend SOP wouldn’t work anyway.

  4. Also just an FYI that SOP models exist in CPU memory, and are only handed over to the GPU memory at render time. In this example this is perfectly fine and probably desired as most systems have more CPU RAM than they do GPU RAM.
    I baked out 1000 frames / TOGs of L-system SOP animation per the defaults in your TOE.
    Without the TOGs loaded in the project TD uses approx 600MB CPU RAM as a baseline.
    With the 1000 TOGs loaded TD uses approx 3.5GB - 4.5GB CPU RAM.

There are ways you could bake out and store the vertex positions to be preloaded into GPU RAM, using 32-bit Textures / TOPs, as one may use with a GLSL particle system. Could make sense if you needed to truly blend/morph between only keyframes of vertex positions with high performance or do some calculations / transformations between keyframes in the vertex shader of a GLSL MAT --but I think that’s all out of scope for the goals of what your particular SOP/TOG baking technique is meant to accomplish.

Hi Landoth,

Thanks a lot for the thoughtful reply!

I’ll make a more in depth reply with a revision of the animation baker component which addresses some of the points you brought up when I get a chance.

I’ve looked into combining this technique along with a GLSL particle baker that Barakooda made but haven’t yet progressed too much in that direction. I would definitely be interested in finding ways to convert vertices into 32 bit video for my geos but for the moment this seems to be working out mostly fine. Hogging up that much RAM is definitely a bit of a bottleneck though and is sometimes a bit weird on my system. I’ve finally gotten my head around what’s reasonable to expect from my GPU’s performance and harddrives but RAM still has a few mysteries concerning how quickly I can pull things from it or how much is generally used up by other processes. I’ve got 32 gigs here and I’ve managed to max out TD’s CPU memory a few times using a SOP file folders significantly less than that.