GLator copy won't coexist with GLator

[Wogos Media]

After Effects 2018 (plug-in SDK), Visual Studio C++ 2017, Windows 7 (x64)

Attempting to make my own GLator versions, I first copied GLator to GLatorExp (changing all occurrences of "GLator" to "GLatorExp", and "successfully" compiled and deployed both original and copy.  Both appear on the Effects menu, and both plug-ins work perfectly.  However when I add either one after adding its "twin" to the workspace, I get "After Effects error: invalid filter (25::3)".  So it appears that I can only run one shader plug-in at a time. Yet I can add several instances of either GLator or its "twin" without issue.  I assume there is an issue with identity.  Yet I renamed the source files and shaders, and edited the names in all of the source files including the .r.   I haven't yet tried any of the other example plug-ins to see whether they suffer a similar issue, but I compiled and loaded all without issue.

What am I missing?

[Guest]

Not sure if still apliccable, but in the past GLator was a very badly written example that showed exactly this behaviour. It used its own OpenGL context, but did not protect against context switching by the host, if for example AE itself or one of the other plugins also used OpenGL. This then lead to only one plugin working (with maybe mutltiple instances of it, as the context was shared globally within that one plugin), but crashing or misbehaving across several processes.

As far as I remember, Adobe changed something in that regard in the GLator sources, but this sample code still seems to cause problems from what I heard. I switched to a self-written and completely separate OpenGL context and own context handling from within my plugins years ago and never had any problems with my written OpenGL/GLSL plugins in AE.

[françois leroy · Accepted solution]

Hi!

the latest GLator is better that the old one, though it's not perfect. Toby's right, it used to misuse contexts and lead to troubles...

But I think a quick fix, in your case, would be to give a new name when you create your OpenGL window (look into GL_base.cpp).

In my own OGL structure, I give a random name, so I'm sure 2 plugins will never use the same name.

Cheers,

François

[Wogos Media]

Much thanks gentlemen. GLator uses an officious appearing string constant for the window name as you indicated. Fooled the rookie. Gaving each instance its own name fixes my issue. 

Wondering if I should just generate a GUID or something so I don’t have to change GL_base.cpp for each filter. 

[françois leroy]

For all my plugins, I use the same code, that generates a random name based on current date (including milliseconds).

This way, as windows are created at different times, I'm sure they use different names.

Cheers,

François

[Guest]

I just looked at the GLator example from Adobe, and I think they actually address this correctly now?

// very tricky, windows needs a unique class name for each window instance

// to derive a unique name, a pointer to "this" is used

static std::atomic_int S_cnt;

std::stringstream ss;

ss << "AESDK_OpenGL_Win_Class" << S_cnt.load();

S_cnt++;

className = ss.str();

[Wogos Media]

Nope -- my issue was with that code (not very tricky). Seems that S_cnt.load() initializes to the same value for both GLator and its twin. François's solution is better.

[Guest]

Yeah, I wondered, as the comments somehow don't match the actual code, they use an atomic instead of a unique pointer.