Windows version is available...

[Darth kenobi]

I am totally new to Gaffer and windows version is available or I have to build manually...

[Roy Nieterau]

I believe there currently is no officially supported Windows build. I'd love one too. :)

You can have a look in this topic where some work was being done on building a Windows version: https://groups.google.com/forum/#!msg/gaffer-dev/rQraWNbDxaU/zpvM59R1AwAJ

Some test releases were also done at the time: https://github.com/boberfly/gaffer/releases

If you are looking to develop and help on the Windows build it's likely good to join that Windows topic.

Cheers,

Roy

[Eric Mehl]

I've been working on moving the Windows version forward as well - it's working and usable but I'm reluctant to put something up as a Release because there are still bugs here and there and the main dev team hasn't reviewed my changes yet. I'm mostly using it for orchestrating Python scripts and some light image processing at this point, though I believe all features are functioning.

If you want to build it, I have a set of forks that are working albeit with a messy commit history. It's 100% going to change as I'll be continuing to work out the file path handling and then rebasing in the next few weeks to submit as a new PR to include updates on the main project from the last few months.

The branch you want to build / fork is called "msvc2017_for_merge" for all three of these repositories:

1. Gaffer Dependencies: https://github.com/hypothetical-inc/gafferDependencies
   
2. Cortex: https://github.com/hypothetical-inc/cortex
3. Gaffer: https://github.com/hypothetical-inc/gaffer

You need to build in that order from within Visual Studio's "x64 Native tools command prompt for visual studio 2017".

If you are interested in contributing I'd definitely welcome you - to my knowledge I'm the main driver on it at the moment, and due to time constraints my efforts are focused on internal production needs.

[Roy Nieterau]

Thanks Eric for breaking this down like that - I might be interested in playing around and compiling it too, so this is a great help. 

I'd appreciate it if you are able to put up a "binary release" that works off the bat on one of your repos - even if it's just to test the current state of the conversion. And if I get to compiling it myself that if it breaks somewhere I'm sure it's not because I miscompiled anything.

I'm expecting the major effort is in the path handling to get cross-compatibility at this point, right? Or are you still facing some other major issues?

[Eric Mehl]

I put up a pre-release for Windows here: https://github.com/hypothetical-inc/gaffer/releases/tag/0.52.0.0-beta

It's for testing only but hopefully is enough to get you started. I made a few notes of missing / unknown / buggy features on the release page.

Aside from some things like Arnold and 3delight support that I'll likely never be able to add myself, I think it's pretty close to being ready for review and hopefully release. Close as far as progress that is, not necessarily time :) You are right that the main thing I know of that needs work is the cross platform pathing. The version in that release loads and browses the file system fine on Windows. The code for handling paths created on one platform and loaded on another is the main missing piece right now.

There is one bug I'm looking at that breaks Alembic loading for files exported from 3dsMax, but Houdini Alembics are working and I've had success converting 3ds Max Alembic files using the included abcconvert.exe (included in the release since it's part of the Alembic package).

So definitely a work in progress but there is progress.

[Roy Nieterau]

Thanks, opens fine here.

Did a quick test run with an Alembic from Maya and that seems to work just fine - with some transform animation and mesh deformation on cubes. Also a huge Houdini alembic also opened up perfectly. I don't have 3DsMax to quickly test with unfortunately.

However, with that Maya alembic:

• It does work if the Alembic is written out in Ogawa format.
• It does not work if the Alembic is written out in the HDF5 format.

Whenever it tries to load the HDF5 format Alembic a red exclamation mark pops up on the SceneReader node (it does seem to display some frames randomly though).

With HDF5 Alembic I get this error:

ERROR : BackgroundTask : IObject::getPropertiesHash()

ERROR: EXCEPTION:

Ogawa IStreams::read failed.

Maybe your 3DsMax is writing out Alembic as HDF5 and the issue is there?

If so it's likely something with the HDF5 support got compiled wrong in the Alembic dependency. Maybe related to this note that I saw in the Pixar USD build script for Windows.

Hope it helps, and thanks again!

[Eric Mehl]

Thanks for the report back! I'm glad it's working for you, I'm always nervous something in my development environment is keeping mine alive that others won't have set up.

Interesting about the HDF5 vs Ogawa. I've tried both on Max and neither works for me. I think it's something I've messed up in the path handling code though, the error I get is about not being able to set output names. It makes sense because the file system paths and scene location paths are handled through the same code. With Windows and its backslash scheme I've had to tweak some things and I must have broken an edge case that Max uses when exporting. Max is notoriously non-standard with some things so I'll just have to dig through and figure out what I broke.

That's a great find on compiling HDF5 on Windows, hopefully this weekend I'll be able to check that out. Sounds like a quick fix if needed.

[Roy Nieterau]

By the way, I noticed the links under "Help" to Forum and Issue Tracker didn't work - this is because it's using an old version of Qt.py that didn't find QDesktopServices correctly. If you update the Qt.py to the latest version that should be fixed.

So that would fix this particular error:

C:\Users\Gebruiker\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin>py

thon C:\Users\Gebruiker\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\b

in\../bin/gaffer.py

Traceback (most recent call last):

  File "C:\Users\Gebruiker\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifact

s\python\IECore\curry.py", line 48, in curriedFunction

    return func( *args, **kwds )

  File "C:\Users\Gebruiker\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifact

s\python\Gaffer\WeakMethod.py", line 67, in __call__

    return m( *args, **kwArgs )

  File "C:\Users\Gebruiker\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifact

s\python\GafferUI\Menu.py", line 183, in __actionTriggered

    item.command( *args, **kw )

  File "C:\Users\Gebruiker\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifact

s\python\GafferUI\ShowURL.py", line 58, in showURL

    QtGui.QDesktopServices.openUrl( QtCore.QUrl( url, QtCore.QUrl.TolerantMode )

 )

AttributeError: 'module' object has no attribute 'QDesktopServices'

Since the original Gaffer dependencies also seem to use the same Qt.py module as dependency I suspect the Linux version would have the same bug actually. :)

I was expecting that would fix the (i) help icons on nodes going to a documentation page too, but unfortunately they don't seem to do anything. The "Documentation" menu item is also disabled under the little cogwheel on the node. 

Did you have a good spot where we could post minor issues related to the Windows build? 

[Eric Mehl]

Unless the Gaffer folks prefer otherwise let's log issues on the Windows build to my repository for now: https://github.com/hypothetical-inc/gaffer/issues (just enabled it after finding it isn't on by default) I figure there's no use cluttering up their repo at the moment.

Thanks for the note on Qt.py and for sorting out how to fix it. That's getting pulled from the Gaffer Dependencies project so I'll update that in my fork so it gets pulled in to the Gaffer build.

I'll have a look at the documentation cog problem - on my Mac it loads a local file in a browser so I suspect this may be related to the old forward vs. backslash differences on Windows.

[Eric Mehl]

For anyone reading this thread and wondering about the Alembic reader issue it's actually very simple. Currently Cortex only recognizes files with a lowercase extension, Max defaults to upper case.

I submitted a pull request to make extensions case-insensitive and for now you can just change the case to lower for the extension in the SceneReader node (Windows is case insensitive so it's ok if there's a mismatch between the filename in Gaffer and the filename on disk).

[Eric Mehl]

I just tried loading HDF5 Alembic files created in both Houdini and Max and they are both working for me in Gaffer. I think upgrading Alembic included some cmake build fixes from the original repository.

Could you create an issue on the Hypothetical Gaffer issues pages and upload the Alembic model you are having trouble with? I'd like to test it out here and see if there's anything I can figure out or fix.

[Roy Nieterau]

Great news you resolved that 3DsMax Alembic issue - and good to hear that it was as simple as this.

I'll try to retrieve that Alembic file again tomorrow or otherwise produce some new ones.

[Roy Nieterau]

I quickly tried some HDF5 and Ogawa exports at home on my Windows 10 laptop and both seemed to work fine with a static cube, deformed cube and transformed cube. So not sure what happened with the Alembic at the office the other day - will definitely try to find it again.

Also, for anyone else... my laptop has 2 GPUs - an integrated Intel one and a dedicated Nvidia GT 750m. On the first one I got a bunch of GL errors that were also mentioned here. Going into Nvidia configuration panel and forcing the dedicated GPU for python.exe made it work. Going from the other thread it's a known issue with integrated Intel GPUs.

[Roy Nieterau]

I gave those Alembic files another go at the office and I was unable to reproduce the problem I had at the time. I guess I might have just mistyped the filepath that one time or something alike, as that does seem to sometimes give me the flickering behavior (as if it's keeping the original path in its cache somewhere).

So I guess at this stage the Alembic files work as expected in both formats.

[John Haddon]

It sounds like you might have rewritten the Alembic file while Gaffer was open, and Gaffer already had something cached in memory? In those situations you should be able to use the refresh button on the SceneReader to force a reload...

On Fri, 23 Nov 2018 at 12:30, Roy Nieterau <royni...@gmail.com> wrote:

I gave those Alembic files another go at the office and I was unable to reproduce the problem I had at the time. I guess I might have just mistyped the filepath that one time or something alike, as that does seem to sometimes give me the flickering behavior (as if it's keeping the original path in its cache somewhere).

So I guess at this stage the Alembic files work as expected in both formats.

--
You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

John Haddon - R&D Programmer

Image Engine

studio: +1 (604) 874-5634 | jo...@image-engine.com | www.image-engine.com



15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada

If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.

[Andrew Kaufman]

Just out of curiosity, why would you want to export an HDF5 alembic instead of an Ogawa one? Is there some deficiency in Ogawa? I was under the impression its unconditionally better than HDF5...

Andrew

Andrew Kaufman - R&D Lead

Image Engine

studio: +1 (604) 874-5634 | and...@image-engine.com | www.image-engine.com

[Roy Nieterau]

The only reason I chose to do an HDF5 export was to see whether Eric's failing case in Gaffer could have been due to it being the different format at the time, yet we sorted out that wasn't the case at all. His Alembics were failing due to an uppercase extension as stated in this topic.

In production I've never needed to move to HDF5 since Ogawa got implemented nor do I know of a case where you should. Hope that clarifies it.

[Jordan Bigge]

I'm totally new at gaffer, but I'm really impressed.

I'd love to test gaffer on Windows a little bit.  But it doesn't start on my system (windows 10 version 1809).

cmd error:

C:\Users\Render02>python C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\../bin/gaffer.py

Traceback (most recent call last):

  File "C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\../bin/gaffer.py", line 162, in <module>
    app = loadApp( appName )
  File "C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\../bin/gaffer.py", line 71, in loadApp
    return appLoader.load( appName )()
  File "C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\python\IECore\ClassLoader.py", line 161, in load
    module = imp.load_module( "IECoreClassLoader" + name.replace( ".", "_" ) + str( version ), fileForLoad, fileName, ( ".py", "r", imp.PY_SOURCE ) )
  File "C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\apps\gui\gui-1.py", line 45, in <module>
    import GafferUI
  File "C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\python\GafferUI\__init__.py", line 147, in <module>
    from _GafferUI import *
ImportError: DLL load failed: The specified procedure was not found.

Maybe you can help me

[Eric Mehl]

It looks like it's finding some libraries but not others which is strange. Double check that you have the file _GafferUI.pyd in the Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\python\GafferUI folder.

If you do have that file, check that the environment variables are set up correctly.

1. Remove the lines in the gaffer.bat file that say SETLOCAL and ENDLOCAL (otherwise it resets the environment after running the batch file)
   
2. run the gaffer.bat file
3. now "echo %PYTHONPATH%" - it should be something like "C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\python" for you
   

You can also get all the environment variables printed out by running "set" by itself.

You can post the results here too and I can try to help sort it out.

[Jordan Bigge]

Thank you very much for your efforts!

That's weird, the _GafferUI.pyd file is where it should be.

I've tested this version before:

https://github.com/boberfly/gaffer/releases

Gaffer got off to a smooth start.

Here are the environment variables:

C:\Users\Render02>echo %PYTHONPATH%

C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\python;

C:\Users\Render02>set

ADSK_CLM_WPAD_PROXY_CHECK=FALSE

ALLUSERSPROFILE=C:\ProgramData

APPDATA=C:\Users\Render02\AppData\Roaming

CommonProgramFiles=C:\Program Files\Common Files

CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files

CommonProgramW6432=C:\Program Files\Common Files

COMPUTERNAME=RENDER2-PC

ComSpec=C:\WINDOWS\system32\cmd.exe

CORTEX_POINTDISTRIBUTION_TILESET=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\resources\cortex\tileset_2048.dat

DriverData=C:\Windows\System32\Drivers\DriverData

FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer

FPS_BROWSER_USER_PROFILE_STRING=Default

GAFFEROSL_CODE_DIRECTORY=C:\Users\Render02\gaffer\oslCode

GAFFERUI_IMAGE_PATHS=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\graphics;

GAFFER_APP_PATHS=C:\Users\Render02\gaffer\apps;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\apps;

GAFFER_ROOT=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..

GAFFER_STARTUP_PATHS=C:\Users\Render02\gaffer\startup;;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\startup

HOME=C:\Users\Render02

HOMEDRIVE=C:

HOMEPATH=\Users\Render02

IECOREGL_SHADER_INCLUDE_PATHS=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\glsl;

IECOREGL_SHADER_PATHS=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\glsl;

IECORE_FONT_PATHS=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\fonts;

IECORE_OP_PATHS=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\ops;

IECORE_OP_PRESET_PATHS=C:\Users\Render02\gaffer\opPresets;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\opPresets;

IECORE_PROCEDURAL_PATHS=C:\Users\Render02\gaffer\procedurals;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\procedurals;

IECORE_PROCEDURAL_PRESET_PATHS=C:\Users\Render02\gaffer\proceduralPresets;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\proceduralPresets;

INTEL_DEV_REDIST=C:\Program Files (x86)\Common Files\Intel\Shared Libraries\

JD2_HOME=C:\Users\Render02\AppData\Local\JDownloader 2.0

LOCALAPPDATA=C:\Users\Render02\AppData\Local

LOGONSERVER=\\RENDER2-PC

MIC_LD_LIBRARY_PATH=C:\Program Files (x86)\Common Files\Intel\Shared Libraries\compiler\lib\intel64_win_mic

NUMBER_OF_PROCESSORS=56

OneDrive=C:\Users\Render02\OneDrive

OS=Windows_NT

OSLHOME=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..

OSL_SHADER_PATHS=C:\Users\Render02\gaffer\shaders;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\shaders;

Path=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\bin;C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\lib;;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\polytrans64;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Users\Render02\AppData\Local\Microsoft\WindowsApps;

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

PROCESSOR_ARCHITECTURE=AMD64

PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 63 Stepping 2, GenuineIntel

PROCESSOR_LEVEL=6

PROCESSOR_REVISION=3f02

ProgramData=C:\ProgramData

ProgramFiles=C:\Program Files

ProgramFiles(x86)=C:\Program Files (x86)

ProgramW6432=C:\Program Files

PROMPT=$P$G

PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\Intel\Wired Networking\

PUBLIC=C:\Users\Public

PYTHONHOME=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..

PYTHONPATH=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\python;

QT_OPENGL=desktop

QT_QPA_PLATFORM_PLUGIN_PATH=C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\..\qt\plugins

SESSIONNAME=Console

SystemDrive=C:

SystemRoot=C:\WINDOWS

TEMP=C:\Users\Render02\AppData\Local\Temp

TMP=C:\Users\Render02\AppData\Local\Temp

USERDOMAIN=RENDER2-PC

USERDOMAIN_ROAMINGPROFILE=RENDER2-PC

USERNAME=Render02

USERPROFILE=C:\Users\Render02

VBOX_MSI_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\

windir=C:\WINDOWS

[Eric Mehl]

Those environment variables look like they should be set up fine. Let's try digging a little deeper to see if there's a problem with the Python that is being run.

In a fresh command line window, run the gaffer.bat again to setup the environment. Now just run "python" with no arguments. Mine gives this at the start of the Python session:

C:\Users\eric\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts(1)\bin>python
Python 2.7.15 (default, Nov 15 2018, 11:35:43) [MSC v.1913 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

Does that match yours?

Try running this short script from that Python session:

import sys
import platform
print sys.executable
print platform.architecture()
print sys.maxsize

I wish Python gave more informative error messages when loading libraries. I'm suspecting there's a mismatch between 32/64bit builds or something else internal to Python. That shouldn't be the case if it's picking up the Gaffer included Python, but maybe something is incorrectly set that is causing it to pick up another Python installation.

[Eric Mehl]

I should have mentioned - when I run that python script I get the following result:

C:\Users\eric\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts(1)\bin\python.exe
('64bit', 'WindowsPE')
9223372036854775807

How does that compare to your result?

Now just to try it out, put these two commands into your Python session:

import Gaffer
import GafferUI

I expect that to fail for you, but if it succeeds then it's a little more information to track down what's failing.

[Jordan Bigge]

Thank You!

As you expected it failed:

C:\Users\Render02>Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\python

Python 2.7.15 (default, Nov 15 2018, 11:35:43) [MSC v.1913 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

>>> print sys.executable
C:\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\bin\python.exe
>>> print platform.architecture()

('64bit', 'WindowsPE')

>>> print sys.maxsize
9223372036854775807


>>> import Gaffer
>>> import GafferUI

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

[Eric Mehl]

The good news is that it's picking up the right Python executable for Gaffer, so we can tick that one off the list.

The bad news is that we've done through most of the easy things I know of. Let's dig a little deeper now. Download and unzip the Windows Dependency Walker here: http://www.dependencywalker.com/

Now set up the Gaffer environment like before and from the command prompt (that part is important so it can find the DLL files and similar) run the depends.exe you unzipped. In the Dependency Walker open the _GafferUI.pyd file from the Python/GafferUI directory.

It takes a little getting used to reading the output but it will give you a tree view of all the files that pyd file is trying to load, including nested dependencies. It will almost certainly give some errors and warnings, indicated by red icons next to the dependency, particularly about system and kernel files. That part is normal. What we're interested in is the DLL files it references from the Gaffer directory. Especially the GAFFERUI.DLL - this should not be missing any Gaffer related dependencies (on my machine it can't find OpenGL32.dll and a couple other system files but those are taken care of when the program launches normally).

Attached is a screen capture of what I see under the GAFFERUI.DLL item. Can you post a screen capture of what your _GafferUI.pyd and also your _Gaffer.pyd? Since it seems like your _Gaffer.pyd is loading correctly it will be interesting to compare them.

[Eric Mehl]

Here's a large size that is legible.

[Jordan Bigge]

I have to admit that I can't do much with the results myself. But maybe you can read something from it.

[Jordan Bigge]

[Eric Mehl]

It looks like everything is being found correctly so I'm a little stumped on what is going wrong. I just figured out that Dependency Walker can export the results, can you post or send me the results of loading your _GafferUI.pyd? Not sure if there are security issues so you can email me at er...@thinkhypothetical.com if you'd rather not have it posted here. Then I can check it out in more detail and see what's going on.

Open up the _GafferUI.pyd like before and go to File->Save As and save it as a .dwi file.

I'm going to see about getting a Debug build going this weekend that might be helpful too, I'll let you know how that gets along.

On Friday, December 7, 2018 at 4:53:20 AM UTC-5, Jordan Bigge wrote:

[Eric Mehl]

One more question for you Jordan, do you have Visual Studio installed on this machine? I just thought that myself and maybe others who have successfully gotten Gaffer running probably had MSVC installed. If you don't have it, perhaps there's a file MSVC provides that needs to be included with the Gaffer Distribution.

Hopefully I'll be able to figure that out from the Dependency Walker file

[Roy Nieterau]

I'm probably wrong - but could it by any chance be giving an error because of a windows path with backslashes? I noticed it had a \r (because of users\render02) in the path which by pure luck isn't in yours Eric nor was it in mine (or other special characters). Just to be sure? ;)

[Eric Mehl]

Good thought! I just tried it out though and I'm getting a successful launch. I didn't create the exact directory, but I used `C:\Users\eric\Users\Render02\Desktop\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts` which I think should fail if it's an escaping issue.

I'm open to all suggestions though!

[Roy Nieterau]

Actually, I believe only the lowercase \r is a special character, not the uppercase one. Right?

[Jordan Bigge]

It's very interesting. I put it on three different machines. The workstation at work, my laptop and my PC at home. Each time with a different result. On the laptop Gaffer starts without problems, but viewport and nodegraph panel remain black. On the workstation at work it doesn't start at all as described. And on my private PC it runs without problems.

[Roy Nieterau]

The laptop likely has two GPUs in it, one of which is an intel integrated card (or alike) and that's giving errors. It's a known issue with Gaffer, also see this post.

Also, for anyone else... my laptop has 2 GPUs - an integrated Intel one and a dedicated Nvidia GT 750m. On the first one I got a bunch of GL errors that were also mentioned here. Going into Nvidia configuration panel and forcing the dedicated GPU for python.exe made it work. Going from the other thread it's a known issue with integrated Intel GPUs.

You can force Python to use the dedicated GPU, that should resolve it.

The issue you are having with the Workstation I don't know about unfortunately.

[Miguel González Viñé]

Hi Eric,

I'm really happy to know you're still working on the Windows version. We'd love to use Gaffer at work (The Frank Barton Company), but we don't think we're going to move to Linux in the near future. So our only chance to use it is the Windows version.

I tried the pre-release 0.52.0.0 when you wrote the email and I got also a python error I don't remember, but I thought that my anti-virus was mocking me. So now that I've more time, I've tested it again without it and it works perfectly at work. I also get the black panels at home like Jordan with a Mac Mini because of the Inter graphics card I suppose, however the OSX version works great.

Great to see the open dialog is getting better. The only weird thing I've notice is when I close Gaffer, the python executable process doesn't exit and I can't get the command prompt back. But I need to test it in more machines to check if this is an isolated problem of my computer. IIRC the Alex Fuller's version didn't had this problem.

About the support of Arnold you say in the release notes that is unknown. So I've tried to get it work but it doesn't as it looks like Gaffer/Cortex is not compiled against Arnold?

This is the output error:

ERROR : startup/gui/menus.py : Error loading Arnold module - "No module named IECoreArnold".

 Traceback (most recent call last):

  File "C:\Users\blue\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\startup\gui\menus.py", line 105, in <module>

    import GafferArnold

  File "C:\Users\blue\Downloads\Gaffer_Windows_Gaffer_0.52.0.0.283_artifacts\python\GafferArnold\__init__.py", line 55, in <module>

    __import__( "IECoreArnold" )

ImportError: No module named IECoreArnold

We'd like to contribute to get the Windows version working as its best, but we don't have any hard core developer at work. So we only could help as betatesters for now.

--

[Eric Mehl]

That is weird that it's working on some machines and not others, and that the failing machines are not all the known issue of the unsupported GPU. I'm leaning towards the GPU being the culprit for the other failing machine too, since it looks like it's being caused by some part of the UI loading. FYI to the group I'm messaging with Jordan separately to look at the detailed dependencies that hopefully will reveal what is missing on that mystery machine.

Also for general knowledge, I've found that Windows Remote Desktop does not support OpenGL (at least on my GeForce cards, I've read that Quadro cards might have that enabled). So if you are trying to launch Gaffer through a RDP session it will give the GPU failures - black windows and lots of error messages on the console. If you use something like RealVNC instead, that works (for me at least) since it's just relaying the screen through the network, not a lower-level connection like Microsoft offers.

[Eric Mehl]

You are right Miguel, I'm not building my Cortex with Arnold support, so I think you'd have to rebuild Cortex, and presumably Gaffer too, with the Arnold connection included. I'm not sure if there is a way to build Cortex and Gaffer with Arnold but without having the Arnold software (and license). Maybe they make headers available or even the whole API, just requiring a license to actually run it? I use Vray here so I don't know what Arnold offers in that regard.

I'm happy to have help with testing (and developing!) my Windows fork, though I have to be clear that I need to prioritize development work to suit my own production needs and don't have a lot of time available to provide wider ranging support, especially as a one man shop. But I'll definitely contribute what I can and help inch Gaffer on Windows towards being production ready and hopefully get it merged into the main repository when the time is right.

[Eric Mehl]

Good news and bad news on your mystery machine. Based on the dependency logs you sent me it looks like it's getting tripped up on zlib.dll, which is loaded by OpenImageIO. It's loading your system provided zlib.dll instead of the one included with Gaffer. The Gaffer / OpenImageIO version exports a needed function that your system zlib.dll isn't providing.

Can you look to see if the machine which is working smoothly does not have zlib.dll in the Windows\system32 folder? That would suggest it's loading the correct Gaffer version since it's not finding a system provided version.

The bad news is I'm not sure how to force loading the Gaffer provided zlib.dll. It will take me some time to figure out how to handle that, after a quick search it looks like it may be a more complicated task than it sounds. I'm of course open to suggestions from anyone with insight!

[Jordan Bigge]

It's on! I isolated the zlib.dll file and Gaffer starts without problems. 

[Eric Mehl]

Woohoo! Great to hear that sorted it for you.

I'll add to my to-do list to figure out how to force it to load the right DLL even if there's one in the system folder already.

[Alex Fuller]

Maybe we can just flag zlib to be static linked here? Not the best fix in the world but zlib is tiny anyways.

[Eric Mehl]

Yeah, I'm definitely leaning that way. Static linking a small library vs. sorting out manifests, known DLLs and all of that with cmake makes static linking sound like the clear winner.

[Miguel González Viñé]

Hi Eric,

sorry for the late reply, I was on holidays. 

Yes, afaik, you can download Arnold and using it without license from https://www.arnoldrenderer.com/, you will get a watemarked image. Just need to sign up on the website.

I'll wait until you can get Arnold support, if you have the time, or until you merge the Windows port, so I could try to compile it myself (I don't have to much knowledge about it though :) )

Best,

Miguel

[Eric Mehl]

Realistically it will be quite a while if ever that I can look into the Arnold stuff - I use Vray so there are a lot of to-dos ahead of Arnold support for me. It might make for a good intro if you are interested in diving in to some code and build wrangling. I'm guessing it wouldn't be too hard to get it working, but emphasis on the "guessing" part :)

I have Cortex and Gaffer both building on Appveyor now so that at least offers a reference platform to get started and I'm happy to answer questions along the way.

[Miguel González Viñé]

Hi Eric, 

I'd love to try it (the main problem is the little spare time). I'm going to write you a private email, so I don't make too much noise in the list.

Thanks,

Miguel