Hello Flame folks,
I’m looking into ways of launching flame with a more centralized environment. We often use application centric environment variables and flags to manipulate certain things on launch.
I’ve found the list of launch flags that I can use on the cmd line.
I’m also aware of several “DL_*” environment variables, like DL_PYTHON_HOOK_PATH, DL_GMASK_AUTO_MOVE_MODE, etc.
Is there a full list of these variables available somewhere?
Any other tips for more “centralized” application environment?
@Jacob There is no list of environment variables available.
That being said, what you are trying to achieve is something that we would like to improve for the future so please send me a direct message if you would like to have a chat with members of the development team on that subject so we can identify your needs an requirements.
If you are interested in truly optimizing your Flame experience for centralization, checkout my S&W videos on my YouTube channel. This has revolutionized our Flame workflow.
Reading this about flame connection problems, I saw something about an environment variable I didn’t know about, and I’ve been surprised that such specific variables exist.
There are more interesting sutff like this one, about start flame with all libraries closed, what I find it incredibly interesting and useful. For example, to prevent flame crashing when some clip/desktop/library gets corrupted. Or simply, as the original topic says, to speed up flame start. If I had known about this, it would have saved some dramatic situation. We have all read topics here about people with this problem and I don’t remember anyone talking about this
I wonder why there is no a list of environment variables availabe. Or if It’s the typical scenario where adults think that children should not know some things. Since a few versions, environment variables can be easily set with the setup tool. So I guess that we, even as user-level, we might know a little bit more about this.
The main issue is that most environment variables are often put in place for internal development purposes and are not part of the testing routine performed in subsequent releases. Moreover, we do not qualify/test the different combinaisons, making it impossible for us to certify that the application will run smoothly depending on which ones you use.
OK. I can understand completely the developmental and testing nature of many of them. No interest here. But I wonder if there might be some of them considered as user-level. And well-documented in a list, and not in casual findings.
In prior versions of flame (up to 2023.2 at least) a batch group write file node would switch compression types if this env var was not set.
A batch group write file node could be set to ‘piz’, the batch group could be saved/iterated, closed, reloaded and the write file node would switch to RLE.
If the application was closed, restarted and any batch group reloaded, all of the write file nodes would revert to RLE.
I guess I’m superstitious - that env-var is tattooed in my eyeballs.
Thanks Alan,
I just tried it - all write nodes retain compression parameters, between saves, loads and restarts and reloads.
Thanks @Flame Team for these invisible fixes.
Happy Friday
And this morning all write nodes have reverted to RLE compression.
I’ll be reverting my DL_OPENEXR_COMPRESSION voodoo until this defect is properly eliminated.
Sigh.
We’ve just finished two projects, both on 2023.3.2, one of them would constantly revert to RLE from PIZ, however, the other one was fine, (PIZ).
Both projects were linear workflow, non-ACES, 16bit, 23.976fps. The only difference was one was UHD, the other was 4448x3096.