Windows Prebuild Viewer error on startup

[greenbrettmichael]

The viewer in the prebuilt windows download starts with the following error: C:\Users\Brett\Downloads\MaterialX_Windows_VS2022_x64_Python39> .\bin\MaterialXView.exe Failed to load standard data libraries: XInclude cycle detected. *** Validation warnings for standard_surface_default.mtlx *** Invalid port connection: <input name="base_color" type="color3" output="tmtestout" nodegraph="nodegraph1"> Invalid port connection: <input name="specular_color" type="color3" output="tmtestout2" nodegraph="nodegraph1"> Invalid port connection: <input name="transmission_color" type="color3" output="troutput" nodegraph="nodegraph1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1"> Mismatched types in port connection: <input name="texcoord" type="vector2" nodename="multiply1">

A dialog box with an error is shown that states Failed to load material Could not find a matching implementation for node 'surfacematerial' matching target 'genglsl

The window maintains a grey appearance, loading other geometry does not change the behavior

[greenbrettmichael]

I was not able to replicate by building the project on the latest HEAD commit. Perhaps it is possible that the prebuilt needs to be updated or has an absolute path baked in

[jstone-lucasfilm]

@greenbrettmichael Maybe this is just a corrupted binary download? This morning, I downloaded the pre-built VS2022 package from the front page of the MaterialX GitHub, and the viewer seems to work smoothly in that build.

[greenbrettmichael]

@greenbrettmichael Maybe this is just a corrupted binary download? This morning, I downloaded the pre-built VS2022 package from the front page of the MaterialX GitHub, and the viewer seems to work smoothly in that build.

If you have an MD5 hash of the zip that you want to share to check I would be glad to check against that on my machine!

[jstone-lucasfilm]

Here's the MD5 I get for my local download of the VS2022 binary package:

4178313e4fe79b2dc3f4a3bebd5a6bbf

[greenbrettmichael]

I computed the same MD5 on my package 4178313E4FE79B2DC3F4A3BEBD5A6BBF

I also re-extracted the zip and tried again and was able to replicate.

If there is any information that you would like me to extract I would be willing to dig around. I am not blocked by this issue since I have built locally (and looking forward to adding materialX support to a project that I am working on).

Is there a difference how we are running? I found that launching the exe from windows explorer leads to many unresolved paths for resources and libraries folders. Unfortunately using the args like in help does not work .\MaterialXView.exe --path "../" if I run from the main dir those paths are resolved ".\bin\MaterialXView.exe"

[jstone-lucasfilm]

Very interesting, and this does seem like an issue we should learn more about and resolve. Let me know if you have any insights as to what might be different about your Windows setup, as I'd like this use case to be properly handled by MaterialXView in the future. During initialization, the viewer uses its executable path to make an educated guess as to where its required libraries folder is located, and it sounds like it's failing to find the folder in this situation.

[greenbrettmichael]

Sure, it looks trivial to setup a similar folder structure from the local build and setup a debugger to see what is going on. I will look at that for an obvious environment reason sometime in the next few days

[kwokcb]

FYI: In case this helps, note that these cases will fail currently. This should not be the case with the installation, but perhaps something is getting confused as searching is all relative to the executable / module path, it's parent paths, and any custom user search paths.

1. MaterialXView in same folder as libraries (which contains all the definitions).

MaterialXView
libraries <-- not found
resources 

2. Incorrect libraries folder found. First one found will be used any other search paths are ignored.

MaterialXView
../libraries (which is not contain the materialx libraries definitions)
<somePathLocation>/libraries (which is not contain the materialx libraries definitions)
<correctFolder>/libraries (which contains the materialx libraries definitions <-- not found