Skip to main content
Wogos Media
Wogos Media
Participant
August 9, 2018
Answered

GLator copy won't coexist with GLator

  • August 9, 2018
  • 2 replies
  • 958 views

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?

This topic has been closed for replies.
Correct answer françois leroy

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

2 replies

françois leroy
françois leroyCorrect answer
Inspiring
August 9, 2018

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
Wogos MediaAuthor
Participant
August 10, 2018

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. 

A
Anonymous
August 10, 2018

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();

A
Anonymous
August 9, 2018

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.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices