Skip to content

Commit 34d72b6

Browse files
chellmuthChris Hellmuth
authored andcommitted
Merge remote-tracking branch origin/main into devdays-2025
2 parents 30ff611 + 3694c47 commit 34d72b6

File tree

166 files changed

+4258
-8473
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

166 files changed

+4258
-8473
lines changed

.github/workflows/main.yml

Lines changed: 18 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,18 @@ on:
77
pull_request:
88
paths-ignore:
99
- '**.md'
10+
schedule:
11+
# Nightly build
12+
- cron: '30 10 * * *'
1013
workflow_dispatch:
1114

1215
jobs:
1316

1417
build:
1518
name: Build
1619
runs-on: ${{ matrix.os }}
20+
env:
21+
IS_EXTENDED_BUILD: ${{ github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' }}
1722
strategy:
1823
fail-fast: false
1924
matrix:
@@ -109,6 +114,7 @@ jobs:
109114
python: 3.13
110115
cmake_config: -G "Visual Studio 17 2022" -A "x64"
111116
test_shaders: ON
117+
extended_build_oiio: ON
112118

113119
- name: Windows_VS2022_x64_SharedLibs
114120
os: windows-2025
@@ -156,11 +162,10 @@ jobs:
156162
Add-Content $env:GITHUB_PATH "$PWD/build/installed/bin"
157163
158164
- name: Install OpenImageIO
159-
if: matrix.build_oiio == 'ON' && runner.os == 'Windows'
165+
if: env.IS_EXTENDED_BUILD == 'true' && matrix.extended_build_oiio == 'ON' && runner.os == 'Windows'
160166
run: |
161-
C:/vcpkg/vcpkg install openimageio --triplet=x64-windows-release
162-
Add-Content $env:GITHUB_PATH "C:/vcpkg/installed/x64-windows-release/bin"
163-
Add-Content $env:GITHUB_PATH "C:/vcpkg/installed/x64-windows-release/share/openimageio"
167+
C:/vcpkg/vcpkg install openimageio --triplet=x64-windows
168+
Add-Content $env:GITHUB_PATH "C:/vcpkg/installed/x64-windows/bin"
164169
165170
- name: Install Python ${{ matrix.python }}
166171
if: matrix.python != 'None'
@@ -178,7 +183,12 @@ jobs:
178183
run: find source \( -name *.h -o -name *.cpp -o -name *.mm -o -name *.inl \) ! -path "*/External/*" ! -path "*/NanoGUI/*" | xargs clang-format -i --verbose
179184

180185
- name: CMake Generate
181-
run: cmake -S . -B build -DMATERIALX_BUILD_PYTHON=ON -DMATERIALX_BUILD_VIEWER=ON -DMATERIALX_BUILD_GRAPH_EDITOR=ON -DMATERIALX_BUILD_TESTS=ON -DMATERIALX_TEST_RENDER=OFF -DMATERIALX_WARNINGS_AS_ERRORS=ON ${{matrix.cmake_config}}
186+
shell: bash
187+
run: |
188+
if [ "${{ env.IS_EXTENDED_BUILD }}" == "true" ] && [ "${{ matrix.extended_build_oiio }}" == "ON" ]; then
189+
EXTENDED_BUILD_CONFIG="-DMATERIALX_BUILD_OIIO=ON -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows"
190+
fi
191+
cmake -S . -B build -DMATERIALX_BUILD_PYTHON=ON -DMATERIALX_BUILD_VIEWER=ON -DMATERIALX_BUILD_GRAPH_EDITOR=ON -DMATERIALX_BUILD_TESTS=ON -DMATERIALX_TEST_RENDER=OFF -DMATERIALX_WARNINGS_AS_ERRORS=ON $EXTENDED_BUILD_CONFIG ${{matrix.cmake_config}}
182192
183193
- name: CMake Build
184194
run: cmake --build build --target install --config Release --parallel 2
@@ -309,15 +319,15 @@ jobs:
309319
run: |
310320
git clone https://github.com/emscripten-core/emsdk --recursive
311321
cd emsdk
312-
./emsdk install 2.0.20
313-
./emsdk activate 2.0.20
322+
./emsdk install 4.0.8
323+
./emsdk activate 4.0.8
314324
source ./emsdk_env.sh
315325
echo "EMSDK=$EMSDK" >> $GITHUB_ENV
316326
317327
- name: Install Node
318328
uses: actions/setup-node@v4
319329
with:
320-
node-version: '16'
330+
node-version: '22.16.0'
321331

322332
- name: JavaScript CMake Generate
323333
run: cmake -S . -B javascript/build -DMATERIALX_BUILD_JS=ON -DMATERIALX_EMSDK_PATH=${{ env.EMSDK }}

CMakeLists.txt

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -316,7 +316,12 @@ else()
316316
add_link_options(${DYNAMIC_ANALYSIS_OPTIONS})
317317
endif()
318318
if(MATERIALX_BUILD_JS)
319-
add_compile_options(-fexceptions)
319+
if (CMAKE_BUILD_TYPE MATCHES Debug)
320+
add_compile_options(-fexceptions)
321+
else()
322+
add_compile_options(-fexceptions -Os -flto)
323+
add_link_options(-flto)
324+
endif()
320325
endif()
321326
endif()
322327

@@ -465,6 +470,10 @@ add_subdirectory(source/MaterialXFormat)
465470
# Add shader generation subdirectories
466471
add_subdirectory(source/MaterialXGenShader)
467472
if(MATERIALX_BUILD_GEN_GLSL OR MATERIALX_BUILD_GEN_OSL OR MATERIALX_BUILD_GEN_OSL_NETWORK OR MATERIALX_BUILD_GEN_MDL OR MATERIALX_BUILD_GEN_MSL)
473+
if(MATERIALX_BUILD_GEN_GLSL OR MATERIALX_BUILD_GEN_MSL)
474+
add_subdirectory(source/MaterialXGenHw)
475+
endif()
476+
468477
if (MATERIALX_BUILD_GEN_GLSL)
469478
add_definitions(-DMATERIALX_BUILD_GEN_GLSL)
470479
add_subdirectory(source/MaterialXGenGlsl)

CONTRIBUTING.md

Lines changed: 102 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -189,7 +189,96 @@ in the ASWF Slack or in TSC meetings before any PR is submitted, in order to
189189
solicit feedback, build consensus, and alert all stakeholders to be on the
190190
lookout for the eventual PR when it appears.
191191

192-
### Coding Conventions
192+
### Developer Guidelines
193+
194+
The following guidelines represent coding standards that we strive to follow
195+
in the MaterialX project. While not all existing code may adhere to these
196+
standards yet, we encourage all new contributions to follow these practices,
197+
and we welcome incremental improvements to bring existing code into alignment
198+
with these guidelines.
199+
200+
#### Naming Conventions
201+
202+
Class names should use PascalCase, as in `NodeGraph` or `ShaderGenerator`.
203+
Method names should use camelCase starting with a lowercase letter, for
204+
example `getNode` or `setName`. Protected and private member variables should
205+
use an underscore prefix, such as `_name` or `_parent`. Constants should be
206+
written in UPPER_CASE with underscores separating words, as in `EMPTY_STRING`
207+
or `CATEGORY`. Type aliases should append appropriate suffixes to indicate
208+
their purpose, using `Ptr` for pointers, `Vec` for vectors, `Map` for maps,
209+
and `Set` for sets.
210+
211+
#### Static Constants and Class Organization
212+
213+
Class members should be organized in order of decreasing visibility: public,
214+
protected, then private. Static constants should be placed at the end of their
215+
respective visibility section. String constants should be defined in implementation
216+
files rather than headers to avoid One Definition Rule violations. The
217+
`EMPTY_STRING` constant should be used instead of empty string literals (`""`)
218+
for clarity and consistency.
219+
220+
#### Smart Pointer Conventions
221+
222+
Heap-allocated objects in the public API should always use `shared_ptr` for
223+
memory management. Type aliases should be defined for all shared pointers,
224+
following the pattern of `ElementPtr` for `shared_ptr<Element>`. Both mutable
225+
and const versions of these type aliases should be provided, e.g. `ElementPtr`
226+
and `ConstElementPtr`. Raw pointers should be avoided except when representing
227+
non-owning references within implementation details.
228+
229+
#### Const Correctness
230+
231+
Methods that do not modify an object's state should be marked as `const`.
232+
Accessor methods should provide const versions to enable their use on const
233+
objects. Type aliases following the pattern `ConstElementPtr` should be used to
234+
indicate read-only access through shared pointers. Parameters that should not
235+
be modified within a function should be declared as const.
236+
237+
#### Parameter Passing and Return Values
238+
239+
Strings and complex objects should be passed by `const&` to avoid unnecessary
240+
copies. Shared pointers should be passed by value since they are designed to
241+
be cheap to copy. When returning shared pointers, they should be returned by
242+
value rather than by reference. Methods should be marked as `const` whenever
243+
they do not modify the object's state.
244+
245+
#### Exception Handling
246+
247+
Exceptions should be used for exceptional conditions rather than for normal
248+
control flow. Custom exception types should be defined by inheriting from
249+
`Exception` to represent specific error categories. Exception messages should
250+
be descriptive and include relevant context to aid in debugging. All exceptions
251+
that may be thrown by a method should be documented using the `@throws` tag in
252+
the method's documentation. When catching exceptions, specific exception types
253+
should be caught rather than generic exceptions whenever possible.
254+
255+
#### Header Includes
256+
257+
Header includes should be written with angle brackets, with paths relative to
258+
the root source folder (e.g. `#include <MaterialXCore/Element.h>`). This
259+
ensures consistent include paths across the entire codebase, regardless of the
260+
location of the referencing file.
261+
262+
Each implementation file should include its corresponding header file first,
263+
so the first include in `Element.cpp` should be `Element.h`. This ensures that
264+
the header file is self-contained and doesn't accidentally depend on includes
265+
from other headers.
266+
267+
After the corresponding header, include blocks should be ordered hierarchically,
268+
with high-level modules listed before low-level modules (e.g.
269+
`MaterialXGenShader`, followed by `MaterialXFormat`, followed by
270+
`MaterialXCore`). This maximizes opportunities to catch missing dependencies in
271+
the high-level modules, which might otherwise be hidden at build time. Within
272+
include blocks, individual includes should be ordered alphabetically, providing
273+
a simple canonical order that is straightforward for developers to check.
274+
275+
In the interest of avoiding include cycles, developers are free to leverage
276+
forward declarations of classes that are trivially referenced within another
277+
header. In the interest of clarity and efficiency, developers are free to
278+
leverage transitive header includes, where low-level headers that have already
279+
been included by a high-level header do not need to be restated individually.
280+
281+
#### Coding Style
193282

194283
The coding style of the MaterialX project is defined by a
195284
[clang-format](.clang-format) file in the repository, which is supported by
@@ -200,7 +289,18 @@ file to automatically align the code to MaterialX conventions. When modifying
200289
existing code, follow the surrounding formatting conventions so that new or
201290
modified code blends in with the current code.
202291

203-
### Unit Tests
292+
#### Documentation Standards
293+
294+
All classes and methods in the public API should be documented with Doxygen
295+
comments. Classes should be documented with the `@class` tag, and structs with
296+
the `@struct` tag, followed by a brief description and any detailed
297+
documentation. Method documentation should include `@param`, `@return`, and
298+
`@throws` tags where applicable. Related methods should be grouped together
299+
using `/// @name GroupName` sections to improve readability. File-level
300+
documentation should be placed immediately after the copyright header using
301+
the `/// @file` directive.
302+
303+
#### Unit Tests
204304

205305
Each MaterialX module has a companion folder within the
206306
[MaterialXTest](source/MaterialXTest) module, containing a set of unit tests

javascript/MaterialXTest/browser/karma.conf.js

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -33,5 +33,15 @@ module.exports = function (config)
3333
'karma-mocha',
3434
'karma-mocha-reporter',
3535
],
36+
customLaunchers: {
37+
ChromeHeadlessGL: {
38+
base: 'Chrome',
39+
flags: [
40+
'--headless=new',
41+
'--enable-gpu',
42+
'--enable-webgl',
43+
],
44+
},
45+
},
3646
});
3747
};

javascript/MaterialXTest/browser/shaderGenerator.spec.js

Lines changed: 24 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,10 @@ function createStandardSurfaceMaterial(mx)
1212
shaderElement.setType('surfaceshader');
1313
shaderElement.setNodeName(ssName);
1414
expect(doc.validate()).to.be.true;
15+
// Release local wrappers
16+
shaderElement.delete();
17+
smNode.delete();
18+
ssNode.delete();
1519
return doc;
1620
}
1721

@@ -94,13 +98,32 @@ describe('Generate Shaders', function ()
9498
console.error("--- PIXEL SHADER END ---");
9599
}
96100
expect(gl.getShaderParameter(glPixelShader, gl.COMPILE_STATUS)).to.equal(true);
101+
// Cleanup GL shaders
102+
gl.deleteShader(glVertexShader);
103+
gl.deleteShader(glPixelShader);
97104
}
105+
// Cleanup shader wrapper
106+
mxShader.delete();
98107
}
99108
catch (errPtr)
100109
{
101110
console.error("-------- Failed code generation: ----------------");
102-
console.error(mx.getExceptionMessage(errPtr));
111+
if (typeof mx.getExceptionMessage === 'function')
112+
{
113+
console.error(mx.getExceptionMessage(errPtr));
114+
}
115+
else
116+
{
117+
console.error(errPtr);
118+
}
103119
}
120+
// Cleanup per-generator wrappers
121+
stdlib.delete();
122+
genContext.delete();
123+
gen.delete();
104124
}
125+
// Cleanup element and document
126+
elem.delete();
127+
doc.delete();
105128
});
106129
});

javascript/MaterialXTest/codeExamples.spec.js

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -76,6 +76,12 @@ describe('Code Examples', () =>
7676

7777
// // Validate the value of roughness in the context of this material.
7878
// expect(roughness.getBoundValue(material).getValueString()).to.equal('0.5');
79+
// Cleanup wrappers
80+
nodeDefs.forEach(nd => nd.delete());
81+
output.delete();
82+
image.delete();
83+
nodeGraph.delete();
84+
doc.delete();
7985
});
8086

8187
it('Traversing a Document Tree', async () =>
@@ -101,6 +107,7 @@ describe('Code Examples', () =>
101107
}
102108
}
103109
expect(imageCount).to.greaterThan(0);
110+
doc.delete();
104111
});
105112

106113
it('Building a MaterialX Document', async () =>
@@ -133,5 +140,6 @@ describe('Code Examples', () =>
133140

134141
// expect(materialCount).to.equal(0);
135142
// expect(shaderInputCount).to.equal(0);
143+
doc.delete();
136144
});
137145
});

0 commit comments

Comments
 (0)