Is there a way to have more control over the way VRAM is loaded during the project starting up? I have this big project that crashes because it’s out of VRAM everytime i start it, because touch tries to load all my scenes into VRAM on startup, even though they’re behind a switch TOP that’s set to only view one of them. If i disable the comps in safemode, load the project and then enabIe them again it works fine, but i obviously wouldn’t want to do this everytime. I tried disabling everything on startup with the onStart() option in the execute DAT, but that only seems to run after the project’s done loading, so it doesn’t work for my problem. I’d like to have control over what needs to load into VRAM on startup maybe somehow is that possible?
Just thinking out loud here, but could you put your scenes on disk and load unload them as needed or if you only need one at a time use scene changer? A python startup script can be helpful here…
My issue is during startup. Once it’s running it’s all good, so scene changer and stuff won’t have any effect. Also the first point in the project load where python code can be executed is already too late for my problem. Like i said the onStart() of the execute DAT is too late and that’s the first possible time to execute any python as far as i know.
Ok sorry. that’s about as early as I can think of in startup. Seems like a TD developer question…
You could always go the other way around, save project with those comps set to cooking disabled, and then use python to selectively enable cooking.
Or refactor drastically and change your whole project architecture by splitting it in half say, so you cut it down enough so the first part loads up fine by itself, and then you load more stuff from disk as required. Do you use probe to check GPU memory etc? I often find I have to cut back on my networks and geometry etc to get good performance. First I get something working more or less with content I want, then ruthlessly optimize until it runs fast enough…
Yes this is the option i used to be able to play my show on saturday, but since i often save and change things, i’d like to not have to disable everything manually every time i save lest something crashes.
I don’t quite get what you mean by loading things from disk. My scenes are not video’s, they’e entire generative patches. I cut everything out i didn’t want to use for my show to about 10 scenes. This amount of content has run fine in the past and i think i have a quite optimized project. I’ve probed it extensively. I’ve recently upgraded my project from 2025.30960 to 2025.32460 and i feel like it may have to do with this, but i can’t find anything in the release notes about project loading or VRAM management having changed.
you test quickly if the buildnr is the issue, you can download older builds of TD and install them parallel next to your current build, to doublecheck if that changes the vram issue or not. If so that counts as a bug and can be reported.
Like @nettoyeur suggests, try older builds that used to work. If your code has run fine in the past one thing I have done is revert to older backups in the actual build that used to work until you step back to when it works again properly. Painful but sometimes necessary to discard hours, days of recent coding. I keep many older builds in parallel for this reason.
If all scenes are generative and you have checked GPU usage and every other tab in probe to see what is heaviest and consuming most resources I am guessing either your geometries or textures are the hogs. These can be loaded in stages in toxes as needed potentially.
If all else fails you might need to upgrade your hardware to suit your current ambitions.
Here are some other suggestions from our friendly AI Perplexity that might help. I often find when troubleshooting reading the actual links the AI based its advice on is very useful.
Hope this helps.
I have this same issue and run a large scenechanger based file.
My fix has been to use an executeDAT and call a Progressive Unload on the baseCOMP with all of my scenes inside at project start. That releases them from VRAM.
Something like
op(‘scenes’).progressiveUnload(nodesPerFrame=100)
You can read the following objects to monitor said progressive unload if you need:
op(‘scenes’).progressiveUnloader.active
op(‘scenes’).progressiveUnloader.gpuMemUnloaded
op(‘scenes’).progressiveUnloader.nodesUnloaded
See more monitoring objects here
Hope this helps!
This is similar to what i ended up doing for my project too. I wasn’t familiar with those objects though. They look useful and i’ll definitely look into them. Thanks!