I managed to build on OS X but have problem importing the Python module

Anyone having success on Windows or CentOS to verify if this is OS specific ?

Cheers
----log output----
(materialx-env) Nicholass-MacBook:build-gcc nicholas$ python
Python 2.7.10 (default, Jul 14 2015, 19:46:27)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MaterialX
Traceback (most recent call last):
File "", line 1, in
File "/Users/nicholas/projects/MaterialX/materialx-env/lib/python2.7/site-packages/MaterialX/init.py", line 1, in
from MaterialX.main import *
File "/Users/nicholas/projects/MaterialX/materialx-env/lib/python2.7/site-packages/MaterialX/main.py", line 3, in
from MaterialX.PyMaterialX import *
ImportError: No module named PyMaterialX

On Gentoo, I'm having issues, building MaterialX-1.37.0 using gcc-10.1.0

[3/196] /usr/bin/x86_64-pc-linux-gnu-g++ -DMATERIALX_BUILD_VERSION=0 -DMATERIALX_MAJOR_VERSION=1 -DMATERIALX_MINOR_VERSION=37 -DMATERIALX_OSLC_EXECUTABLE=\"\" -DMATERIALX_OSL_INCLUDE_PATH=\"\" -DMATERIALX_TESTRENDER_EXECUTABLE=\"\" -I/var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/..  -O2 -pipe -march=bdver2 -fstack-protector-strong -fstack-check -fPIC   -Wall -Wno-missing-braces -std=gnu++11 -MD -MT source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o -MF source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o.d -o source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o -c /var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/Element.cpp
FAILED: source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o 
/usr/bin/x86_64-pc-linux-gnu-g++ -DMATERIALX_BUILD_VERSION=0 -DMATERIALX_MAJOR_VERSION=1 -DMATERIALX_MINOR_VERSION=37 -DMATERIALX_OSLC_EXECUTABLE=\"\" -DMATERIALX_OSL_INCLUDE_PATH=\"\" -DMATERIALX_TESTRENDER_EXECUTABLE=\"\" -I/var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/..  -O2 -pipe -march=bdver2 -fstack-protector-strong -fstack-check -fPIC   -Wall -Wno-missing-braces -std=gnu++11 -MD -MT source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o -MF source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o.d -o source/MaterialXCore/CMakeFiles/MaterialXCore.dir/Element.cpp.o -c /var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/Element.cpp
/var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/Element.cpp: In member function ‘virtual std::pair<int, int> MaterialX::Element::getVersionIntegers() const’:
/var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/Element.cpp:154:17: error: ‘invalid_argument’ in namespace ‘std’ does not name a type
  154 |     catch (std::invalid_argument&)
      |                 ^~~~~~~~~~~~~~~~
/var/tmp/portage/media-libs/MaterialX-1.37.0/work/MaterialX-1.37.0/source/MaterialXCore/Element.cpp:157:17: error: ‘out_of_range’ in namespace ‘std’ does not name a type
  157 |     catch (std::out_of_range&)
      |                 ^~~~~~~~~~~~

When using gcc < 10, the build succeeds, so I thought it might be related to the change in -fcommon defaulting to -fno-common in gcc-10, but simply adding the -fcommon flag when building didn't solve the issue.

Hello, this is a question rather than an issue with MaterialX.

We are looking to start building authoring support for MaterialX from within DCCs like Clarisse. Initially we are planning to start small, with some of the more fundamental things.

I was wondering if you have an example of this kind of translation between an actual DCC and MaterialX, that we could use as a reference for this work?

Thanks!

It looks like <cstdlib> gets included via <algorithm> on Linux but not OSX, which is (for me at least) resulting in a failed compilation on my Macbook.

A possible fix:

diff --git a/source/MaterialXFormat/Environ.cpp b/source/MaterialXFormat/Environ.cpp
index 4a9ef04..529af29 100644
--- a/source/MaterialXFormat/Environ.cpp
+++ b/source/MaterialXFormat/Environ.cpp
@@ -7,6 +7,8 @@
 
 #include <MaterialXCore/Util.h>
 
+#include <cstdlib>
+
 #if defined(_WIN32)
 #define WIN32_LEAN_AND_MEAN
 #include <windows.h>
diff --git a/source/MaterialXRender/ImageHandler.h b/source/MaterialXRender/ImageHandler.h
index 4f83626..9e79f62 100644
--- a/source/MaterialXRender/ImageHandler.h
+++ b/source/MaterialXRender/ImageHandler.h
@@ -14,6 +14,7 @@
 #include <cmath>
 #include <map>
 #include <array>
+#include <cstdlib>
 
 #include <MaterialXFormat/File.h>
 

Add a slider to rotate the lighting environment about the Y-axis in the MaterialX viewer.

At the moment, it's only possible to orbit the camera about the model, which doesn't change the relationship between the model and the lighting environment. This task would add a new slider that rotates the lighting environment itself about the Y-axis, allowing an additional axis of freedom in material viewing. The new rotation control should apply to both indirect and direct lighting components.

ooppps! mistakenly added an issue. It is okay to be removed.

This seems to have been a conscious choice, but I'm wondering what the impediment is to building shared libraries on Windows? This seems like a problem for integrating MatX into DCCs that need to run on Windows... Specifically if Houdini wants to add MatX support to USD and to some other part(s) of Houdini, we'd need to link MatX into multiple libraries that would load simultaneously which at best is a waste or time and memory, and at worst will cause crashes like in #485...

Are there any other known Windows-specific limitations to MatX?

It seems like including the same document twice in a materialX document causes an error related to duplicate nodes. It happens when documents are recursively included so any type of use where you include a document when a node is needed is likely to break if you have any type of hierarchical includes.
It can easily be solved by using CopyOptions to skip duplicate elements but using it locally is likely to produce documents that are incompatible with applications not using that setting.

Here is a python script triggering the issue:

import MaterialX as mx

a = mx.createDocument()
a.addNodeDef('banana')
b = mx.createDocument()
b.importLibrary(a)
c = mx.createDocument()
c.importLibrary(a)
c.importLibrary(b)

Ideally I would like to be able to include any document from which I directly use nodes in my document regardless if these documents are dependent on each other and have it work in any materialx application regardless of how they set up their CopyOptions.

Hi,

The following does not compile

class Material {};
#include "MaterialXFormat/XmlIo.h"

void fnord() {
  auto ptr = MaterialX::createDocument();
  MaterialX::readFromXmlFile(ptr, "fnord.mtlx");
}

The specific compile error in msvc is MaterialXCore/Document.h(116): error C2440: 'return': cannot convert from 'std::shared_ptr<MaterialX::Material>' to 'std::shared_ptr<Material>'. We get similar errors in clang and gcc.

The reason is that Material.h starts with

namespace MaterialX
{

/// A shared pointer to a Material
using MaterialPtr = shared_ptr<class Material>;

It's using the type aliases to forward declare the MaterialX::Material type. However, if there's a non-namespaced Material class defined somewhere before this gets included then the type alias will use that type instead of treating the <class Material> as a forward declaration.

We can work around this issue by moving the MaterialX includes to come before the mildly evil application header that is defining a bare Material class for us, but it would be nice if the conflict didn't exist.

A solution is adding explicit forward declarations before any of the type aliases. The pattern seems to be pretty common in the API.

Write a MaterialX graph that implements the Disney Principled 2012 shading model, as described here:

https://blog.selfshadow.com/publications/s2012-shading-course/burley/s2012_pbs_disney_brdf_notes_v3.pdf

The existing graphs for Autodesk Standard Surface and UsdPreviewSurface would make good reference points for this new graph implementation:

https://github.com/materialx/MaterialX/blob/master/libraries/bxdf/standard_surface.mtlx
https://github.com/materialx/MaterialX/blob/master/libraries/bxdf/usd_preview_surface.mtlx

The existing MaterialX interface for Disney Principled 2012 may be found here:

https://github.com/materialx/MaterialX/blob/master/libraries/bxdf/disney_brdf_2012.mtlx

Hi,

Is there any function to connect upstream node specific output to downstream node in NodeGraph? For instance: connect image node "color3" output red channel to remapFloat input parameter, I have tried to define multiple output node with NodeDef but I can`t find any connecting function.

Cheers.

K.T.

Hi all,
is a Java implementation for MaterialX planed for the future or are you interested in such a project?

Thanks,

Hendrik

Update GGX specular reflections in MaterialXGenGlsl to use height-correlated Smith masking-shadowing, as described in Eric Heitz's paper:

http://jcgt.org/published/0003/02/03/paper.pdf

The existing implementation of Smith masking-shadowing for MaterialXGenGlsl can be found here:

https://github.com/materialx/MaterialX/blob/master/libraries/pbrlib/genglsl/lib/mx_bsdfs.glsl#L54

Example of the bug has been posted below. Current workaround is to use setAttribute('node', 'somenode')

temp_output = self.document.getNodeDef('material_output')
temp_output.setNode('new_output_node')
AttributeError: 'MaterialX.PyMaterialX.ShaderRef' object has no attribute 'setNode'

<output name="diffuse" type="color3" nodename="n4"/>

<constant name="c1" type="color3">
  <parameter name="value" type="color3" value="0.0,0.0,0.0" publicname="diffbase"/>
</constant>

In most cases name names an object.

nodename is confusing because it does not name a thing. I suggest "noderef".

publicname is confusing because it also does not name a thing, it indicates use, or semantic. I suggest "semantic"

Similarly, I suggest "fileref" as type for images, as opposed to "filename"

I suspect there are other uses of name I haven't spotted that don't name things but reference things.

On Linux with g++ 6.3.1, when I link the MaterialX static libraries into two separate shared libraries, then use both of those shared libraries in a program, the program crashes at exit. I get the following diagnostic in the terminal:

bash-4.2$ ./test
Creating MaterialX document in TestA
Creating MaterialX document in TestB
*** Error in `./test': double free or corruption (!prev): 0x0000000002055c30 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81299)[0x7f95634d5299]
/home/sunya/projects/HYD-2108/libtestA.so(_ZN9__gnu_cxx13new_allocatorIPNSt8__detail15_Hash_node_baseEE10deallocateEPS3_m+0x20)[0x7f95648c80ee]
/home/sunya/projects/HYD-2108/libtestA.so(_ZNSt16allocator_traitsISaIPNSt8__detail15_Hash_node_baseEEE10deallocateERS3_PS2_m+0x2b)[0x7f95648c777c]
/home/sunya/projects/HYD-2108/libtestA.so(_ZNSt8__detail16_Hashtable_allocISaINS_10_Hash_nodeISt4pairIKSsPFSt10shared_ptrIN9MaterialX5ValueEERS3_EELb1EEEEE21_M_deallocate_bucketsEPPNS_15_Hash_node_baseEm+0x5a)[0x7f956498046c]
/home/sunya/projects/HYD-2108/libtestA.so(_ZNSt10_HashtableISsSt4pairIKSsPFSt10shared_ptrIN9MaterialX5ValueEERS1_EESaIS9_ENSt8__detail10_Select1stESt8equal_toISsESt4hashISsENSB_18_Mod_range_hashingENSB_20_Default_ranged_hashENSB_20_Prime_rehash_policyENSB_17_Hashtable_traitsILb1ELb0ELb1EEEE21_M_deallocate_bucketsEPPNSB_15_Hash_node_baseEm+0x42)[0x7f956497f0c6]
/home/sunya/projects/HYD-2108/libtestA.so(_ZNSt10_HashtableISsSt4pairIKSsPFSt10shared_ptrIN9MaterialX5ValueEERS1_EESaIS9_ENSt8__detail10_Select1stESt8equal_toISsESt4hashISsENSB_18_Mod_range_hashingENSB_20_Default_ranged_hashENSB_20_Prime_rehash_policyENSB_17_Hashtable_traitsILb1ELb0ELb1EEEE21_M_deallocate_bucketsEv+0x2a)[0x7f956497e37c]
/home/sunya/projects/HYD-2108/libtestA.so(_ZNSt10_HashtableISsSt4pairIKSsPFSt10shared_ptrIN9MaterialX5ValueEERS1_EESaIS9_ENSt8__detail10_Select1stESt8equal_toISsESt4hashISsENSB_18_Mod_range_hashingENSB_20_Default_ranged_hashENSB_20_Prime_rehash_policyENSB_17_Hashtable_traitsILb1ELb0ELb1EEEED1Ev+0x24)[0x7f956497da56]
/home/sunya/projects/HYD-2108/libtestA.so(_ZNSt13unordered_mapISsPFSt10shared_ptrIN9MaterialX5ValueEERKSsESt4hashISsESt8equal_toISsESaISt4pairIS4_S7_EEED1Ev+0x18)[0x7f956498e606]
/lib64/libc.so.6(__cxa_finalize+0x9a)[0x7f956348e05a]
/home/sunya/projects/HYD-2108/libtestB.so(+0x263853)[0x7f95642a4853]

To reproduce this, you can unpack the attached file, modify the build.sh script to point to your MaterialX install, then run it and the produced test program. repro.zip

I don't think this is an issue specific to MaterialX itself. I'm not a linker expert but I think this is an expected gotcha with using static libraries with static variables with external linkage. I believe this could be avoided if I linked against a shared library build of MaterialX, but it appears only static builds are supported.

Could MaterialX allow shared library builds? Right now static builds are forced via the "STATIC" keyword specified in the add_library calls in the various CMakeList.txt files, but removing that let me build shared libraries that seemed to work OK in my limited testing.

Having the materialX viewer open makes my laptop's fans spin. It seems like it's rendering regardless if anything changed since last frame.

Hi again,

Our main renderer for the foreseeable future seems to only support OIIO 1.x (unfortunately).
In #316 it was mentioned supporting both API's in the future was an option.

It looks pretty trivial to do so, as the only file that needs changing is OiioImageLoader.cpp, and the OIIO_VERSION_MAJOR def could probably used to branch in the pre-processor.

Assuming the paper work for #355 goes through ok, would this be an acceptable solution?

Add Python bindings for the TextureBaker class, allowing texture-baking utilities to be authored entirely in Python:

https://github.com/materialx/MaterialX/blob/master/source/MaterialXRenderGlsl/TextureBaker.h

Examples of Python bindings for other GLSL rendering functionality in MaterialX may be found here:

https://github.com/materialx/MaterialX/tree/master/source/PyMaterialX/PyMaterialXRenderGlsl

To test this new functionality, we would ideally add a new script that leverages the bindings for the TextureBaker:

https://github.com/materialx/MaterialX/tree/master/python/Scripts

Add support for the generation of Sphinx documentation for MaterialX Python, using the approach described here:

https://pybind11.readthedocs.io/en/stable/advanced/misc.html#generating-documentation-using-sphinx

Hello,

We'd quite like to be able to provide our own version of pybind11 (which is partially covered here #146).

Sadly, if pybind11 is made available by using a CMake install, they aren't explicit put in a /tools directory but instead will be placed in /share/cmake/pybind11 etc.

as expected by:
list(APPEND CMAKE_MODULE_PATH "${MATERIALX_PYTHON_PYBIND11_DIR}/tools")

Using find_package(pybind11) is a pretty standard way of accessing the modules.

Would it be acceptable to change the logic such that it first searches for pybind11, before appending the path and including pybind11Tools?

It seems that the current cmake setup is ignoring CMAKE_DEBUG_POSTFIX in favor of MATERIALX_DEBUG_POSTFIX.

I had to add an special MaterialX-only case to my build pipeline as all other dependencies in my setup (OSL/OpenExr/... ) do follow the built-in cmake CMAKE_DEBUG_POSTFIX variable.

I understand that this is a trivial issue with a clean and proper workaround though imho there is also no reason the keep the custom MATERIALX_DEBUG_POSTFIX.

I can help by making the needed code changes/PRs if there is consensus here that this should be changed.

Add the MaterialX Python library to the PyPi registry, making it available from the command line via "pip install" on Windows, Linux, and MacOS. Some starting references may be found below:

https://pypi.org/
https://github.com/pybind/python_example

I have a nodegraph/nodedef looking like this:

  <nodedef name="ND_MtlxShader" type="color3" node="MtlxShader">
    <input name="banan" type="color3" value=" 1.000000, 0.047582, 0.000000" uifolder="Material Inputs" />
  </nodedef>
  <nodegraph name="inputs" nodedef="ND_MtlxShader" type="color3">
    <output name="baseColor_output" type="color3" interfacename="banan" />
  </nodegraph>

I.E the output is directly connected to an input using interface name.
When I generate GLSL from it I get something like this:
void inputs(vec3 banan, out vec3 baseColor_output)

void inputs(vec3 banan, out vec3 baseColor_output)
{
    baseColor_output = vec3(0.0);
}

If I introduce a node doing nothing between the input and the output it works.

  <nodedef name="ND_MtlxShader" type="color3" node="MtlxShader">
    <input name="banan" type="color3" value=" 1.000000, 0.047582, 0.000000" uifolder="Material Inputs" />
  </nodedef>
  <nodegraph name="inputs" nodedef="ND_MtlxShader" type="color3">
    <output name="baseColor_output" type="color3" nodename="node_1350078633" />
    <add name="node_1350078633" type="color3">
      <input name="in1" type="color3" interfacename="banan" />
      <input name="in2" type="color3" value=" 0.000000, 0.000000, 0.000000" />
    </add>
  </nodegraph>

Now the generated code looks like this:

void inputs(vec3 banan, out vec3 baseColor_output)
{
    const vec3 node_1350078633_in2_tmp = vec3(0.000000, 0.000000, 0.000000);
    vec3 node_1350078633_out = banan + node_1350078633_in2_tmp;
    baseColor_output = node_1350078633_out;
}

I would think this is a bug. If not, is there a way of connecting an input to an output directly and should there be an error when validating things if doing it the way I did?

This task represents additional work to compensate for multiple scattering in MaterialX-generated GLSL, building upon recent improvements to energy conservation (#402), and using the following references as a guide:

https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf
https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf
https://blog.selfshadow.com/2018/05/13/multi-faceted-part-1/

Hi All,

This is obviously a question rather than an issue, but I thought I'd submit it anyway just to see where it goes.

There exists MaterialXGenGlsl to generate OpenGL shader code. However, the Mari paint application from Foundry has a very particular API for specifying shader code, which uses python and xml to encapsulate a custom glsl shader definition.

Is anyone using GenGlsl to produce a custom Mari shader? Given Mari's custom shading limitations, is this even a realistic proposition? And if it is, could there be a MaterialXGenMari?

Thanks, mitch

Hey there, this is more of a question.

But in the following example:

import MaterialX

doc = MaterialX.createDocument()
graph = doc.addNodeGraph()

add1 = graph.addNode("add")
add2 = graph.addNode("add")
add2.setConnectedNode("in1", add1)

graph.removeNode(add1.getName())
print(MaterialX.writeToXmlString(doc))

The output will be:

<?xml version="1.0"?>
<materialx version="1.37">
  <nodegraph name="nodegraph1">
    <add name="node2" type="color3">
      <input name="in1" type="color3" nodename="node1" />
    </add>
  </nodegraph>
</materialx>

As you can see, there is still a reference to "node1", which as a node, no longer exists.

I'm not sure if this is a bug or not, but if It's not, is the intention suppose to be that you can now create a new "node1" which will neatly fit in its place?

I have a mtlx file exported from Substance. When trying to run through the texture baker script I get an error "LookupError: Could not find a nodedef for node 'standard_surface_constructor'". I tried manually setting the --library or --path option to the included stdlib/stlib_defs.mtlx file. Since I see that node defined as a "surfaceshader" and that is there.

Any ideas?
MTL_Exports 2.zip

Hi,

I am trying to build the project on Ubuntu with the python library and the viewer but this is the error output :

MaterialX/build $ cmake -DMATERIALX_BUILD_PYTHON=ON -DMATERIALX_BUILD_VIEWER=ON ..                                 
-- Using X11 for window creation
-- Using PyBind11 v2.4.3
CMake Error at source/PyMaterialX/PyBind11/tools/FindPythonLibsNew.cmake:96 (message):
  Python config failure:

  Traceback (most recent call last):

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

  ImportError: cannot import name 'sysconfig' from 'distutils'
  (/usr/lib/python3.7/distutils/__init__.py)

Call Stack (most recent call first):
  source/PyMaterialX/PyBind11/tools/pybind11Tools.cmake:16 (find_package)
  source/PyMaterialX/CMakeLists.txt:41 (include)


-- Configuring incomplete, errors occurred!
See also "MaterialX/build/CMakeFiles/CMakeOutput.log".
See also "MaterialX/build/CMakeFiles/CMakeError.log".

Most of the links on internet suggest to do sudo apt install python3-distutils but it's already installed on my system.

Also those commands works properly :

$ python2 -c "from distutils import sysconfig"
$ python3 -c "from distutils import sysconfig"

Specs :

OS: Linux pop-os 5.4.0-7642-generic 20.04
python2: 2.7.18
python3: 3.8.5
python3-distutils: 3.8.5-1~20.04.1

What could be the issue here?

Thanks

Hi,

If I download a release tar.gz (i.e. v1.36.4.tar.gz), and run cmake to build and include the option to build the viewer, it fails with this error:

CMake Error at source/MaterialXView/CMakeLists.txt:2 (message):
  Building the MaterialX viewer requires the NanoGUI submodule to be present.
  Update your repository by calling the following:

  git submodule update --init --recursive


-- Configuring incomplete, errors occurred!

Building from a git clone works great.

Is there a way the submodules could be included with the release tar.gz files?

Thanks,
Zach

Hi! I've tried to run MaterialX viewer from latest (on 30-Jul-2020) prebuilt distribution, but it complaints about stdlib\genglsl shaders.

Output:

MaterialX_Windows_VS2017_x64_Python37\bin>MaterialXView.exe
Failed to generate environment shader: Could not find source file 'stdlib\genglsl\mx_image_color3.glsl' used by implementation 'IM_image_color3_genglsl'
Failed to generate wireframe shader: Could not find source file 'stdlib\genglsl\mx_constant.inline' used by implementation 'IM_constant_color3_genglsl'
Failed to generate shadow shader: Could not find source file 'stdlib\genglsl\mx_constant.inline' used by implementation 'IM_constant_color3_genglsl'
Failed to generate shadow blur shader: Could not find source file 'stdlib\genglsl\mx_image_color3.glsl' used by implementation 'IM_image_color3_genglsl'
Caught exception in main loop: Could not find source file 'stdlib\genglsl\mx_constant.inline' used by implementation 'IM_constant_color3_genglsl'

I have used the link from repo readme: https://ci.appveyor.com/api/projects/jstone-lucasfilm/materialx/artifacts/build%2FMaterialX_Windows_VS2017_x64_Python37.zip?job=Environment%3A%20APPVEYOR_BUILD_WORKER_IMAGE%3DVisual%20Studio%202017%2C%20GENERATOR%3DVisual%20Studio%2015%202017%2C%20TOOLSET_NAME%3DVS2017%2C%20ARCH%3Dx64%2C%20PYTHON%3DC%3A%5CPython37-x64%2C%20PYTHON_NAME%3DPython37

This is more of a user question, but how to generate these basic shapes (square and a disc) without using a texture in MaterialX?

Square, Disc, Paraboloid, Bell, Gaussian, Thorn, Pyramid, Brick, Gradation, Waves, Half Bell, Ridged Bell, Crescant, Capsule, Cone, Hemisphere

https://docs.substance3d.com/sddoc/shape-159450957.html

The philosophy section of MaterialX says we're supposed to generate new nodes from the basic nodes. However, I was hoping to see if anyone has done this.

Would it be possible to make object space positions to be normalized by the bounding box of the object or similar so it's possible to make materials with noises that are not completely dependent on the scene size.

When trying to compile "source/MaterialXRenderGlsl/CMakeFiles/MaterialXRenderGlsl.dir/GLCocoaWrappers.m.o" on MacOS 10.14.6 (or higher, presumably), I get a large number of deprecation warnings such as the following:

/Users/smythe/Documents/GitHub/MaterialX/source/MaterialXRenderGlsl/GLCocoaWrappers.m:19:5: warning: 
      'NSOpenGLPixelFormatAttribute' is deprecated: first deprecated in macOS 10.14 - OpenGL API
      deprecated; please use Metal and MetalKit. (Define GL_SILENCE_DEPRECATION to silence these
      warnings.) [-Wdeprecated-declarations]
    NSOpenGLPixelFormatAttribute list[50];
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:101:18: note: 
      'NSOpenGLPixelFormatAttribute' has been explicitly marked deprecated here
typedef uint32_t NSOpenGLPixelFormatAttribute NS_OPENGL_DEPRECATED(10.0, 10.14);
                 ^
/Users/smythe/Documents/GitHub/MaterialX/source/MaterialXRenderGlsl/GLCocoaWrappers.m:23:21: warning: 
      'NSOpenGLPFAAllRenderers' is deprecated: first deprecated in macOS 10.14 - OpenGL API
      deprecated; please use Metal and MetalKit. (Define GL_SILENCE_DEPRECATION to silence these
      warnings.) [-Wdeprecated-declarations]
        list[i++] = NSOpenGLPFAAllRenderers;
                    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:60:5: note: 
      'NSOpenGLPFAAllRenderers' has been explicitly marked deprecated here
    NSOpenGLPFAAllRenderers          NS_OPENGL_ENUM_DEPRECATED(10.0, 10.14)  =   1,     /...
    ^

as well as the following ERROR:

/Users/smythe/Documents/GitHub/MaterialX/source/MaterialXRenderGlsl/GLCocoaWrappers.m:202:5: error: 
      unknown type name 'NSOpenGLContextAuxiliary'
    NSOpenGLContextAuxiliary* contextAuxiliary =  [context CGLContextObj];
    ^

As a result, MaterialXRender can no longer be compiled on MacOS, and unfortunately, just turning off MATERIALX_BUILD_VIEWER in CMake is not sufficient to make the build successful.

I believe the MaterialX file listed below should work. However, I get the following warnings:

Mismatched types in port connection: <input name="diffuseColor" type="color3" nodename="myfunc1" member="color">
Mismatched types in port connection: <input name="roughness" type="float" nodename="myfunc1" member="roughness">

After printing the warnings, MaterialView crashes on this line due to type being a nullptr:
throw ExceptionShaderGenError("No syntax is defined for the given type '" + type->getName() + "'.");

<?xml version="1.0"?>
<materialx version="1.38" colorspace="lin_rec709">
    <typedef name="myoutput">
        <member name="color" type="color3"/>
        <member name="roughness" type="float"/>
    </typedef>
    <nodedef name="ND_myfunc_myoutput" node="myfunc">
        <input name="in1" type="color3" value="0.5, 0, 0"/>
        <input name="in2" type="color3" value="0.5, 0, 0"/>
        <output name="out1" type="myoutput"/>
    </nodedef>
    <implementation name="IM_myfunc_myoutput" nodedef="ND_myfunc_myoutput" file="blah2.glsl" function="myfunc"/>
    <myfunc name="myfunc1" type="myoutput">
        <input name="in1" type="color3" value="0, 0.5, 0"/>
        <input name="in2" type="color3" value="0, 0.5, 0"/>
    </myfunc>
    <UsdPreviewSurface name="SR_default" type="surfaceshader">
        <input name="diffuseColor" type="color3" nodename="myfunc1" member="color"/>
        <input name="roughness" type="float" nodename="myfunc1" member="roughness"/>
    </UsdPreviewSurface>
    <surfacematerial name="mymaterial" type="material">
        <input name="surfaceshader" type="surfaceshader" nodename="SR_default"/>
    </surfacematerial>
</materialx>

I'm not sure how blah2.glsl should be written in this case, but this is what I'm trying:

void myfunc(vec3 in1, vec3 in2, out myoutput out1)
{
    out1.color = in1 + in2;
    out1.roughness = 0.5;
}

I believe the following file should lead to a green object in MaterialXView, but right now I get a black object. Additionally, I see the following output: "OpenGL error after program unbind geometry: 1282". If I replace the interfacename="colorA" and interfacename="colorB" lines with a value then everything shows up properly.

<?xml version="1.0"?>
<materialx version="1.38" colorspace="lin_rec709">
    <nodedef name="NG_mymaterial" node="mymaterial">
        <input name="colorA" type="color3" value="0, 0.5, 0"/>
        <input name="colorB" type="color3" value="0, 0.5, 0"/>
        <output name="out" type="material"/>
    </nodedef>
    <nodegraph name="blah" nodedef="NG_mymaterial">
        <add name="add1" type="color3">
            <input name="in1" type="color3" interfacename="colorA"/>
            <input name="in2" type="color3" interfacename="colorB"/>
        </add>
        <UsdPreviewSurface name="SR_default" type="surfaceshader">
            <input name="diffuseColor" type="color3" nodename="add1"/>
        </UsdPreviewSurface>
        <surfacematerial name="m1" type="material">
            <input name="surfaceshader" type="surfaceshader" nodename="SR_default"/>
        </surfacematerial>
        <output name="out" type="material" nodename="m1"/>
    </nodegraph>
    <mymaterial name="Material1" type="material"/>
</materialx>

Attempting to import either of these modules results in an error to the tune of:

>>> import MaterialX.PyMaterialXGenOsl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: PyMaterialXGenShader.cpython-37m-x86_64-linux-gnu.so.1: cannot open shared object file: No such file or directory

In both python 2 and python 3.
It appears MaterialX.PyMaterialXGenShader needs to be imported first.

>>> import MaterialX.PyMaterialXGenGlsl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: PyMaterialXGenShader.so.1: cannot open shared object file: No such file or directory
>>>
>>> import MaterialX.PyMaterialXGenShader
>>> import MaterialX.PyMaterialXGenGlsl
>>> import MaterialX.PyMaterialXGenOsl

I'm not sure if these modules, are intended to act as an implementation detail (as none of these modules are imported in the main.py / __init__.py files).

Assuming they are expected to be used explicitly, a simple (and inelegant) solution, would be to simply do an import (in the working order) in main.py.

mx_remap_float.osl looks suspiciously similar to mx_ramp4_float.osl, did something get misplaced here? Also seems to apply to other remap files. I did find the expected implementation is in mx_func.osl though.

Any plans for Python 3 support? What would be necessary to generate the proper python bindings for this library?

Particularly on the page SampleFiles.html, all the links point to a 404.

This is a question rather than an issue. I'd like to store the node positions when writing .mtlx files, so can I add an arbitrary attributes to the Nodes using the MaterialX API, as I see there are set, get, remove attribute member functions in the Node class?

Missing ALL in target?

CMake 3.9.0, CentOS 7.2

This fixes it.

--- a/documents/CMakeLists.txt                                                                                      
+++ b/documents/CMakeLists.txt                                                                                      
@@ -9,12 +9,12 @@ find_package(Doxygen)                                                                             
                                                                                                                    
 if(DOXYGEN_FOUND)                                                                                                  
     configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)                   
-    add_custom_target(MaterialXDocs ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile                     
+    add_custom_target(MaterialXDocs ALL ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile                 

Hello,

Just an idea looking through the codebase with plans to bring it into a game engine/runtime environment. Perhaps MaterialX needs a compile-time option added which removes runtime exceptions? Game engines tend to frown upon using them.

Notable examples:
SPIRV-Cross
https://github.com/KhronosGroup/SPIRV-Cross/blob/master/spirv_cross_error_handling.hpp
PugiXML
https://github.com/materialx/MaterialX/blob/master/source/MaterialXFormat/PugiXML/pugiconfig.hpp#L30

Just to note it's awesome seeing Library.h alias containers, makes it simple to swap out with another one eg. EASTL that's good.

Cheers!

I believe this mtlx should show up green, but it shows up red instead, the default value on the image node is ignored. It appears correctly in the glsl though.

Thanks,
Koen

<nodegraph name="defaultMix" >
    
    <image name="mask" type="float" >
        <parameter name="file" type="filename" value="i_dont_exist.png" />
        <parameter name="default" type="float" value="1.0"/>
    </image>
    
    <mix name="over" type="color3">
        <input name="bg" type="color3" value="1.0,0.0,0.0" /> 
        <input name="fg" type="color3" value="0.0,1.0,0.0" />
        <input name="mix" type="float" nodename="mask"/>
    </mix>

    <output name="colorOut" type="color3" nodename="over" />
</nodegraph>

<material name="Material">
    <shaderref name="Material" node="standard_surface">
        <bindinput name="base_color" type="color3"  nodegraph="defaultMix" output="colorOut" />
    </shaderref>
</material>

I'm having an error when calling input object's getValue() method, if the type is floatarray. Can't see anything about this type in the class index docs either?

AttributeError: 'MaterialX.PyMaterialXCore.Value' object has no attribute 'getData'

Hello,
I've build MaterialX on Centos7, using cmake3, with success but when I want to deals with the python module, I have some errors:
from .PyMaterialXCore import * ModuleNotFoundError: No module named 'MaterialX.PyMaterialXCore'

I have checked in the folder, the file doesn't exist at all. same thing for the PyMaterialXFormat file. I only have this :

I have trtied to build with no options changed, then in activating the MATERIALX_BUILD_PYTHON option, same result

I can't use the prebuild version for now as centos7 use older GLIB

how can I fix it please ?

use codeexamples :
import MaterialX as mx

Create a document.

doc = mx.createDocument()

Create a node graph with a single image node and output.

nodeGraph = doc.addNodeGraph()
image = nodeGraph.addNode('image')
image.setParameterValue('file', 'image1.tif', 'filename')
output = nodeGraph.addOutput()
output.setConnectedNode(image)

Create a simple shader interface.

shader = doc.addNodeDef('shader1', 'surfaceshader', 'simpleSrf')
diffColor = shader.setInputValue('diffColor', mx.Color3(1.0))
specColor = shader.setInputValue('specColor', mx.Color3(0.0))
roughness = shader.setParameterValue('roughness', 0.25)

Create a material that instantiates the shader.

material = doc.addMaterial()
shaderRef = material.addShaderRef('shaderRef1', 'simpleSrf')

Bind roughness to a new value within this material.

bindParam = shaderRef.addBindParam('roughness')
bindParam.setValue(0.5)

Display the value of roughness in the context of this material.

print str(roughness.getBoundValue(material))

the code "image = nodeGraph.addNode('image')" can't run
mistake will be display "'PyMaterialX.NodeGraph' object has no attribute 'addNode'"? why? thankes for you reply!

Hi,
I'm trying to build MaterialX on Ubuntu 18.04 against VFX Platform 2018 (using Gaffer's libs https://github.com/GafferHQ/dependencies/releases) using GCC 6.3 which does build Gaffer and launches fine.

The issue I have with MaterialX is when building the Python bindings, using this release :

[100%] Linking CXX shared library PyMaterialX.so
cd /home/alex/dev/GafferMaterialX/dependencies/MaterialX/working/MaterialX-1.36.1/source/PyMaterialX && /usr/bin/cmake -E cmake_link_script CMakeFiles/PyMaterialX.dir/link.txt --verbose=1
/usr/bin/g++-6 -fPIC   -shared -Wl,-soname,PyMaterialX.so.1 -o PyMaterialX.so.1.36.1 CMakeFiles/PyMaterialX.dir/PyDefinition.cpp.o CMakeFiles/PyMaterialX.dir/PyDocument.cpp.o CMakeFiles/PyMaterialX.dir/PyElement.cpp.o CMakeFiles/PyMaterialX.dir/PyException.cpp.o CMakeFiles/PyMaterialX.dir/PyGeom.cpp.o CMakeFiles/PyMaterialX.dir/PyInterface.cpp.o CMakeFiles/PyMaterialX.dir/PyLook.cpp.o CMakeFiles/PyMaterialX.dir/PyMaterial.cpp.o CMakeFiles/PyMaterialX.dir/PyMaterialX.cpp.o CMakeFiles/PyMaterialX.dir/PyNode.cpp.o CMakeFiles/PyMaterialX.dir/PyObserver.cpp.o CMakeFiles/PyMaterialX.dir/PyProperty.cpp.o CMakeFiles/PyMaterialX.dir/PyTraversal.cpp.o CMakeFiles/PyMaterialX.dir/PyTypes.cpp.o CMakeFiles/PyMaterialX.dir/PyUtil.cpp.o CMakeFiles/PyMaterialX.dir/PyValue.cpp.o CMakeFiles/PyMaterialX.dir/PyVariant.cpp.o CMakeFiles/PyMaterialX.dir/PyXmlIo.cpp.o -flto ../MaterialXFormat/libMaterialXFormat.a -ldl ../MaterialXCore/libMaterialXCore.a -ldl 
/usr/bin/x86_64-linux-gnu-ld: /tmp/ccKnwgRG.ltrans10.ltrans.o: relocation R_X86_64_PC32 against symbol `_ZNSt10shared_ptrIKN9MaterialX16InterfaceElementEEC1Ev' can not be used when making a shared object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
source/PyMaterialX/CMakeFiles/PyMaterialX.dir/build.make:538: recipe for target 'source/PyMaterialX/PyMaterialX.so.1.36.1' failed

Debugging this I use:

ar -x libMaterialXCore.a
readelf --relocs Element.cpp.o | egrep '_ZNSt10shared_ptrIKN9M'

And get this:

Relocation section '.rela.text._ZNSt10shared_ptrIKN9MaterialX16InterfaceElementEED2Ev' at offset 0x17d570 contains 1 entry:
Relocation section '.rela.text._ZNSt10shared_ptrIKN9MaterialX16InterfaceElementEEC1Ev' at offset 0x17d5a0 contains 1 entry:
Relocation section '.rela.text._ZNSt10shared_ptrIKN9MaterialX16InterfaceElementEEC1EDn' at offset 0x17d5b8 contains 1 entry:
000000000018  27a100000004 R_X86_64_PLT32    0000000000000000 _ZNSt10shared_ptrIKN9M - 4

This is strange as I can see -fPIC being applied in the CMakeLists.txt via:

CMAKE_POSITION_INDEPENDENT_CODE TRUE
https://github.com/materialx/MaterialX/blob/master/CMakeLists.txt#L9

Any ideas on how to get around this? Looks like a conflict between R_X86_64_PC32 and R_X86_64_PLT32 unless they're compatible?

Cheers!

We should make sure all appropriate MaterialX attributes are added as OSL parameter metadata. For example docs/help, min/max values etc.

In addition we should implement support for adding in custom attributes as shader or parameter metadata. Possibly configurable by setting a list of the corresponding attribute names on the generator before generation.

Implement a WebGL viewer for MaterialX content, allowing a MaterialX document to be viewed directly in the browser.

One path to this implementation would be to upgrade MaterialXView to the latest version of NanoGUI (https://github.com/mitsuba-renderer/nanogui), which supports WebGL through Emscripten.