AcademySoftwareFoundation / MaterialX

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers.
http://www.materialx.org/
Apache License 2.0
1.85k stars 351 forks source link

Compact executable to take materialx and output rasters #650

Closed fire closed 3 years ago

fire commented 3 years ago

I trying to make a compact way to convert materialx to output rasters images.

What do you suggest?

  1. Raster HDR like openexr
  2. Raster 8 bit like webp or png
  3. Single executable
jstone-lucasfilm commented 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

fire commented 3 years ago

I want to modify MaterialX Viewer to be MaterialX Exporter.

Would that also work?

jstone-lucasfilm commented 3 years ago

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

fire commented 3 years ago

Both MATERIALX_BUILD_VIEWER need to be enabled but I can't see any .openxr or .png.

Any comments?

jstone-lucasfilm commented 3 years ago

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:

https://github.com/materialx/MaterialX/blob/main/documents/DeveloperGuide/Viewer.md#keyboard-shortcuts

fire commented 3 years ago

I was able to bake using the B key.

  1. OpenColorIO defaults to TIFF and EXR
  2. Uniforms can either be nothing or a 4x4 pixel.

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.

fire commented 3 years ago

Posted https://github.com/materialx/MaterialX/pull/651 for review.

jstone-lucasfilm commented 3 years ago

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.

fire commented 3 years ago

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.

jstone-lucasfilm commented 3 years ago

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.

fire commented 3 years ago

Sure.

fire commented 3 years ago

If you can suggest a rename of MaterialXView to something more inclusive, that'll help advertise the expanded featureset.

jstone-lucasfilm commented 3 years ago

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.

fire commented 3 years ago

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
jstone-lucasfilm commented 3 years ago

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.

fire commented 3 years ago

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"
jstone-lucasfilm commented 3 years ago

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.

fire commented 3 years ago

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"
fire commented 3 years ago

How does https://github.com/materialx/MaterialX/pull/651 look?

Need to do some basic QA now.

fire commented 3 years ago

.\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: