Closed fire closed 3 years ago
One option to consider is the TextureBaker class in MaterialXRenderGlsl, which generates baked textures from procedural MaterialX files. Essentially it generates the corresponding GLSL for the material graph and then renders it out to textures at the specified resolution. Our example script for this class is written in Python, but naturally it's available in the C++ library as well:
https://github.com/materialx/MaterialX/blob/main/python/Scripts/baketextures.py
I want to modify MaterialX Viewer to be MaterialX Exporter.
Would that also work?
That approach is fine as well, since MaterialXView leverages the TextureBaker class when you hit the 'B' key to request texture baking, You could create a simplified version of the viewer that runs texture baking and then exits:
https://github.com/materialx/MaterialX/blob/main/source/MaterialXView/Viewer.cpp#L2001
Both MATERIALX_BUILD_VIEWER need to be enabled but I can't see any .openxr or .png.
Any comments?
I'm not quite clear on your question, but are you asking how to bake textures from the MaterialX viewer? There's a 'B' hotkey in the viewer that requests texture baking, and the full set of viewer hotkeys is documented here:
I was able to bake using the B key.
This is enough for output. Will check output path, a width and height option to the cli command. Will try to make a pr.
Trying to devise a matching for the glTF2 PBR material and glTF2 material with sheen, clearcoat and transmission.
Posted https://github.com/materialx/MaterialX/pull/651 for review.
Good to hear that you got this approach to work!
I might recommend maintaining this as an independent project based on MaterialX, rather than making it part of the MaterialX repository itself, since we already maintain texture baking code in Python and in the Viewer.
Keep us posted on how this project progresses, and we're always interested in hearing about core improvements that could be worthwhile to contribute back to MaterialX main.
I was thinking a single executable without python and with the stdlib materials embedded would make materialx easier to use as part of this standard repo.
The current requirements to install python or to press b in the viewer is not obvious and a side effects of publishing a single executable is now we have something to put in linux repositories for unix style chain-ability.
Frankly, I can embed this only into my Godot Engine project but it would make materialx more popular and more usable to have this embedded bake.
Have you considered the alternative approach of extending MaterialXView itself to allow command-line invocation for the purposes of material baking? This would eliminate all of the duplicated code between MaterialXView and MaterialXBaker, and would open the door to additional command-line usage of the viewer in the future (e.g. performing shader translation).
That's an approach that I could see becoming a contribution to MaterialX once it's been fully vetted, and we could integrate it into our test suite across platforms.
Sure.
If you can suggest a rename of MaterialXView to something more inclusive, that'll help advertise the expanded featureset.
In case you'd like to give that approach a try, I'll note that there's some initial precedent for the idea of invoking MaterialXView as a command-line tool for quick material renders:
https://github.com/materialx/MaterialX/blob/main/.github/workflows/main.yml#L163
In this example, we're calling MaterialXView with arguments to request a cloud-based render of a simple material on Linux.
My design is to add to the arguments.
" --width [INTEGER] Specify the width of the image in pixels "
"(defaults to 2048)\n"
" --height [INTEGER] Specify the height of the image in pixels "
"(defaults to 2048)\n"
" --outputFilename [FILENAME] Specify the filename to which the "
"output file should be written\n"
" --hdr [BOOLEAN] Specify if hdr should be baked.\n"
# Something about png vs tiff vs exr vs hdr
You would likely need to make these arguments more specific, since there are already "width" and "height" arguments supported by MaterialXView. One option would be to prefix texture baking arguments with "bake", e.g. "bakeWidth" and "bakeHeight".
More design discussion would likely be needed here, but it's an approach to consider.
Posting for feedback.
" --bakeWidth [INTEGER] Specify the width of the image in pixels "
"(defaults to 2048)\n"
" --bakeHeight [INTEGER] Specify the height of the image in pixels "
"(defaults to 2048)\n"
" --bakeFilename [FILENAME] Specify the filename to which the "
"output file should be written\n"
" --bakeFormat [FORMAT] Specify the format to be baked.\n "
"(defaults to png)\n"
That looks like a good starting point to me. For the default resolution of baked images, I would recommend using the computed maximum resolution of all images in the source document (see the existing logic that's invoked by the 'B' key in the viewer). If the user needs to override this with a specific resolution, then they can optionally specify the bakeWidth and bakeHeight they need.
That's a good idea to use the computed max resolution. Will do.
" --bakeWidth [INTEGER] Specify the width of the image in pixels "
"(defaults to computed max resolution)\n"
" --bakeHeight [INTEGER] Specify the height of the image in pixels "
"(defaults to computed max resolution)\n"
" --bakeFilename [FILENAME] Specify the filename to which the "
"output file should be written\n"
" --bakeFormat [FORMAT] Specify the format to be baked.\n "
"(defaults to png)\n"
How does https://github.com/materialx/MaterialX/pull/651 look?
Need to do some basic QA now.
.\MaterialXView.exe --bakeFilename test --material ..\resources\Materials\Examples\StandardSurface\standard_surface_brass_tiled.mtlx --bakeFormat png --bakeWidth 512 --bakeHeight 512 Wrote baked image: NG_brass1_out_roughness_SR_brass1_baked.png Wrote baked image: NG_brass1_out_color_SR_brass1_baked.png Wrote baked document:
I trying to make a compact way to convert materialx to output rasters images.
What do you suggest?