Super excited to be sharing these videos with everyone. I’ve been working on this for the last few weeks and I’m so glad I finally get to talk about it.
Creating this thread for a place to chat about this new integration. Happy to help anyone through any hurdles they’re having or celebrate with you if you just want to say it’s working great!
This is an EXCELLENT run through of the new scripts tying these giants together. Great stuff for the folks that made it and great great job explaining it, Jeff. Really looking forward to making “delightful Action nodes” with this.
I’m just diving into the 2025 releases and there is one thing really jumped out from watching this. I haven’t used the Lens Distortion node yet, but since the distortion data moves directly between Syntheyes and Flame, does this mean we don’t need ST maps for this workflow? I must be missing something obvious.
Thanks for the kind words. And yes, delightful action nodes for everyone.
You are right! ST Maps are used to send the lens distortion data from one place to another, but since SynthEyes is integrated so closely, it’s able to just kind of send the data manually without the need for an ST Map.
I tried to make it super clear that if you DO start to go down the path of the traditional Lens Distortion route that you might be used to (clicking the Lens Workflow button, clicking Redistorted(2) and clicking OK), then that actually messes the data up, so you need to lose that muscle memory and try not to click that button.
But as long as you click the “More” button, set the distortion you want, and hit refine, by doing that, SynthEyes will know that you’re working with Lens Distortion, and it will automatically import the necessary Undistort and Redistort Lens Distortion nodes, and correctly compensate for the lens distortion.
It sure does work in Linux! I haven’t fully put it through its paces on Linux (I did my testing on Mac) but it does work in Linux and should be essentially the same workflow with some slightly different paths of course. Let me know if anything doesn’t make sense!
I am in a quandary with this integration. The short version is this; ‘Re-open in SynthEyes’ is not working. Boris Support is insisting that the problem occurs because I am saving the Batch Group to the Flame Library. That say that I should not expect the integration to continue to work in any Batch Group that has been loaded back from the Library to the Desktop.
Is that true?
Thanks for your thoughts!
Grant
Details below, if useful…
I’m on Flame 2025.1.2 on Mac
It works fine up until the point that you save & reopen
I’m using the default export tags & have tried many variations
Re-open DOES work, after re-open in Flame, if you remove the batch small ID and unique ID tags
After a save, Flame reloads the clip with different identifier number, so SynthEyes can’t recognise it.
I’ve tried running this on published media, or saving the batch externally, without success
Boris support can replicate the issue, but say its not a problem
We spoke on discord and I’ve actually been in correspondence with the SynthEyes team about this but I’ll write some information here for those of you reading this in the future because it’s decently important.
It looks like in our testing of this feature, we didn’t realize exactly how some of the behind the scenes Batch IDs work in Flame. The default behavior for the SynthEyes integration uses some unique Batch Group identifiers SynthEyes is calling BATSML and BATID. If I remember correctly, this was due to the fact that you can have duplicate Batch Groups with the same name and different content in it on the desktop, and in the case of BFX, the name of the Batch Group was a bit vague, so it was determined that it would be best to use unique identifiers to ID those batch groups so the right one got associated with its corresponding SynthEyes project files. That sounded great, so we went with it, I made my tutorial, all was well in the world.
What we didn’t realize and didn’t test for is that the unique IDs associated with the batch groups are re-generated each time you pull the batch group out of the library. Grant noticed this and flagged it and that’s caused a bit of an investigation. I haven’t finished talking with the SynthEyes team about this but we’re talking. I’m pretty sure what this means is that it will be in everyone’s best interest to not use BATSML and BATID during the “Integrate with Flame” stage, and instead diligently try to not duplicate your batch groups to ensure no paths get crossed. In my brief testing I found things seemed to work alright, but admittedly I didn’t test BFX (because I kind of just realized that while I was writing this), but I’ll report back with more info when I get more info from SynthEyes.