Feature Request: Windows support

[ghost]

Not sure if this is planned or not, but would be really nice to see this get Windows support! Looking at the source with my limited knowledge of cpp, I think the file open/save dialogs and such are the only parts that require macOS, but maybe there's more to it I'm not aware of.

[baku89]

@stysmmaker Thank you for the comment. Of course, I'm thinking of supporting Windows. Since I have been using Windows quite a little recently, I am focusing on macOS at the present.

And to be honest, I'm not sure how much AE users really need a kind of this plugin -- I will try to support Windows if there are more reactions like yours.

FYI, PixelsWorld would be a good alternative for Windows, which allows users to write effects in GLSL/Lua. Though it's proprietary and users need to understand its specification, please try it if you're interested.

[Leonid900]

It would be very cool to see Windows support!
After Effects are great software, but with really customizable effects it would be much more powerful.
I'm not experienced in writing shader code but now I use Blender 3D shader nodes for some complicated effects, like CRT screen emulation, it's not very convenient to switch between software.
It could be also useful for some specific tasks for cartoon animation production.

[rebane2001]

How much would I need to donate to get a Windows version :P?

[mmdurrant]

@baku89 I think I can get it building on Windows.

[gabgren]

I tried too, nothing seems to be preventing us from doing it, only a few #ifdef to handle MacOs dialog vs Windows dialogs. But I got stuck to a bunch of "byte" is ambiguous errors.. I have put it on the shelf for now but definitely going back to it soon. I was planning on making a PR for a windows build once I am done. I can share it now if you want to look at it/contribute

[baku89]

Thanks so much for your consideration to contribute.

@gabgren Which lines does the compiler on Windows throw as errors?
I quickly sought the source files, but I couldn't find any sort of variables with the type byte.

If it is related to VVGL/VVISF, which is a wrapper for managing OpenGL contexts and parsing ISF, we might have to fix the forked version of them rather than this repo.

[mmdurrant]

Awesome! That was my focus last night. I started getting a build environment for ISF4AE first - I knew I'd need the VVGL/VVISF dependencies but wanted to get the ISF4AE bits to the point where those dependencies were the only thing missing.

VVGL looks to use GLFW so I feel like this shouldn't be too difficult. I think you're right about the sections for Windows file dialogs vs Mac, I think that might be the extend of the differences.

@gabgren I have an mmdurrant/ISF4AE fork and have started mmdurrant/win branch.

[baku89]

Sounds great!

Since my skill is basically like a front-end developer and I'm not used to writing such a low-level implementation in C++, the source code might be quite messy and hard to understand.
So if you have any questions about the architecture of the plugin or AESDK, pls feel free to ask me.

[timurco]

@baku89 Hey, I'm currently trying to transition part of the engine to a Windows version, but I've hit some snags with VVGL in Windows. The plugin crashes with the newer versions of the Nvidia Studio drivers. Interestingly, everything works perfectly with the older versions. I suspect the issue is related to context creation since I get a glGetError() = 1282 (Invalid operation) at the line tmpCtx->makeCurrentIfNotCurrent(); in GLBufferPool.h, under the function CreateRGBAPBO.

Some backstory:
I tried to keep just the essentials in GlobalData to replicate the error:

struct GlobalData {
  AEGP_PluginID             aegpId;
  VVGL::GLContextRef        context;
  VVGL::GLCPUToTexCopierRef uploader;
  VVGL::GLTexToCPUCopierRef downloader;
  VVISF::ISF4AESceneRef     mainScene;
};

GlobalSetup

Another quirk with Windows is that the context in GlobalSetup is set up slightly differently than the Mac version:

// Initialize global OpenGL context
#ifdef AE_OS_WIN
  GLContext::bootstrapGLEnvironmentIfNecessary();
  globalData->context = VVGL::CreateNewGLContextRef(nullptr, nullptr); // VVGL on Windows Doesn't have pixel format functions
#else
  globalData->context = VVGL::CreateNewGLContextRef(NULL, CreateCompatibilityGLPixelFormat());
#endif

Then I just initialize the mainScene like this:

globalData->mainScene = VVISF::CreateISF4AESceneRefUsing(globalData->context->newContextSharingMe());
globalData->mainScene->useCode(MAIN_SHADER, "");

PreRender

In PreRender, I just pass the mainScene to ParamInfo:

auto *paramInfo = static_cast<ParamInfo *>(suites.HandleSuite1()->host_lock_handle(paramInfoH));
paramInfo->scene = globalData->mainScene.get();

SmartRender

And then in SmartRender, I load the input to CPU:

ERR(uploadCPUBufferInSmartRender(globalData, in_data->effect_ref, extra, checkoutIndex, layerSize, image));

It's within uploadCPUToTex that I encounter the error at the aforementioned CreateRGBAPBO in GLBufferPool.h:

auto imageAE = globalData->uploader->uploadCPUToTex(imageAECPU);
assert("OpenGl Error" && glGetError() == GL_NO_ERROR);

If I ignore the assert, I get an Access Violation during the copying from cpuBackingPtr because cpuBackingPtr is null:

for (size_t y = 0; y < paramInfo->outSize.height; y++) {
  if (!outputImageCPU->cpuBackingPtr) {
    err = PF_Err_OUT_OF_MEMORY;
    assert("FATAL! CPU backing pointer is NULL! Cannot copy CPU buffer to EffectWorld!" && false);
  }
  glP = (char *)outputImageCPU->cpuBackingPtr + y * bytesPerRowGl;
  aeP = (char *)outputWorld->data + y * outputWorld->rowbytes;
  memcpy(aeP, glP, paramInfo->outSize.width * pixelBytes);
}

And another thing. The error only appears when I press the play button in AE and during background multi-threaded rendering, which made me think it might be related to multithreading. When I simply move the sliders, the error doesn't show up at all.

Any ideas on what I should be looking into or where I should dig next? Everything works great on Mac, and even on Windows, but updating the Nvidia drivers brings about these weird issues. Or could the 1282 error be a red herring, and the null cpuBackingPtr might be due to some other reason?

---

⚠️ Update:
I just checked on a Mac, and the same OpenGL errors occur, yet the plugin works correctly. So, it seems that the cpuBackingPtr becomes NULL not because of them...

[mobile-bungalow]

Can you share your branch? seeing any other edits you made to the locking code might provide hints.

[gabgren]

See #24

[baku89]

@gabgren Thank you so much for your pull request!
Although I have no Windows machine with AE installed and couldn't check if it works by myself, I've merged your patch to the main branch.

I would also like to thank everyone else who participated in this thread and discussed the Windows support!

[baku89]

And am also wondering how to compile, verify, and release the plug-in for both platforms more easily. The notarization on macOS is quite strict and complicated so I've executed a bash script to prepare the binary by hand on a local machine. But this must be automated by something like GitHub Actions.

But regarding Windows, every time I update the version, I have to ask someone who uses AE on Windows to build it manually and send me back the binary. So if there's any smarter way to automate this process, it should be helpful for future updates.

[gabgren]

I guess you could run a windows VM on your Mac ? Notarization on OSX is quite tricky the first time but can be automated if the certificate is installed on the computer. Le jeu. 28 sept. 2023 à 10:16, Baku 麦 ***@***.***> a écrit :

…

And am also wondering how to compile, verify, and release the plug-in for both platforms more easily. The notarization on macOS is quite strict and complicated so I've executed a bash script to prepare the binary by hand on a local machine. But this must be automated by something like GitHub Actions. But regarding Windows, every time I update the version, I have to ask someone who uses AE on Windows to build it manually and send me back the binary. So if there's any smarter way to automate this process, it should be helpful for future updates. — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANFCMK3USXJPSGPTNS32B3X4WBC3ANCNFSM6AAAAAARSNRCWQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[timurco]

@gabgren Thank you so much for your pull request! Although I have no Windows machine with AE installed and couldn't check if it works by myself, I've merged your patch to the main branch.

I would also like to thank everyone else who participated in this thread and discussed the Windows support!

@baku89 thank you so much for such an amazing repository! Parts of your code still inspire my projects. It's very well-organized and has some beautifully done implementations.

--

I wanted to ask, is it alright if I open a separate Issue regarding the problem with the Windows version, which I still couldn't resolve in the fork we mentioned in the pull request to you?

[timurco]

I have no Windows machine with AE installed and couldn't check if it works by myself, I've merged your patch to the main branch.

For Windows, we can also attach a Release version. Here, for example, is an archive. It should work on its own, because it contains the static glew32s.lib, so there's no need to copy dll to system32 =)

ISF4AE.zip

[gabgren]

@baku89 for notarization, I made a tool to make life easier: https://github.com/gabgren/notarizer

[mmdurrant]

I'm trying to debug a dumb issue but can't compile this because I can't get the VVISF-GL submodule patch to apply due to: error: git diff header lacks filename information when removing 1 leading pathname component (line 98) Please advise. Michael Durrant ***@***.***

…

On Thu, Sep 28, 2023 at 8:18 PM gabgren ***@***.***> wrote: @baku89 <https://github.com/baku89> for notarization, I made a tool to make life easier: https://github.com/gabgren/notarizer — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKYJ5R7BJLQA6SVHTQEFWDX4YVXHANCNFSM6AAAAAARSNRCWQ> . You are receiving this because you commented.Message ID: ***@***.***>

[wr4thful]

I have no Windows machine with AE installed and couldn't check if it works by myself, I've merged your patch to the main branch.

For Windows, we can also attach a Release version. Here, for example, is an archive. It should work on its own, because it contains the static glew32s.lib, so there's no need to copy dll to system32 =)

ISF4AE.zip

hi, ive installed the plugin using the archive that u attached. however i noticed some issues with the plugin, sometimes the shader effect is not displaying at all regardless of what i do. even reloading the shader or readding the ISF4AE in new layers doesnt fix it. so after creating a complex procedural effect using the plugin and then purging the project i completely lost most of the progress in the procedural effect. im not sure if this issue exist in the latest source code or its already fixed in the latest source code but when im trying to build the source code i encountered the same issue as the guy above me.

trying to apply
git apply VVISF-GL-Submodule.patch
returns an error
error: git diff header lacks filename information when removing 1 leading pathname component (line 98)

i dont really understand how to write code and i have no idea how to troubleshoot this
i would really appreciate any help if possible, thanks :)