autodesk-forks / materialx Goto Github PK

If a has a which is using a "nodegraph" and "output" reference and the "output" is one of a set of outputs (multi-output), then shader generation does not appear to recognize that connection and ignores it silently.
The following is an example:

<material name="Shader">
    <shaderref name="Shader" node="standard_surface">
      <bindinput name="base_color" type="color3" output="GraphInst_base_color_output" />
      <bindinput name="specular_roughness" type="float" nodegraph="GraphInst" output="specular_roughness_output" />
    </shaderref>
  </material>
  <MtlxShader name="GraphInst" type="multioutput">
  </MtlxShader>
  <output name="GraphInst_base_color_output" type="color3" nodename="GraphInst" output="base_color_output" />
  <output name="GraphInst_specular_roughness_output" type="float" nodename="GraphInst" output="specular_roughness_output" />

The "base_color" connection is not recognized but if there is an output which references the multi-output output then it is (in the case of the "specular_roughness" mapping.

The workaround for now is to have explicit s created for each multioutput output to use for a .

This can include the following:

• A way to do side-by-side comparisons between GLSL and OSL
• More TBD.

Update #432.
AcademySoftwareFoundation#222

Open in MURAL
MaterialX Triage Items - Autodesk DCP

Shader code can have inputs which are matrix33. OGS does not support this, thus
we need to publish inputs as matrix44 and convert back to matrix33 within the shader.

TBD destination. Perhaps to resources/Examples/Lights.

Open in MURAL
MaterialX Priority Items - Autodesk DCP

This is a short proposal to be able to store direct connections between the members of a node to the members of an Input or Parameter.

1. Assumptions
As with any other feature in the specification (such as implicit output swizzling) it is not a required to support these configurations directly.

Any configuration possible here is possible to store using with one or more existing standard library nodes.

2. Specification Modifications
Add the ability to specify optional child “members” connections for an input or parameter.

The basic syntax is:

<input … [ <member name=”<name>” type=”<type>” nodename=”<nodename> [channels=”<channel>”] ] </input>

where the name attribute defines which members being written to. The contents of the name string can be interpreted the same as for the channels string. This includes the ability to perform swizzle operations.

The order of evaluation is to perform the assignment and then if present perform the input’s member assignments.

3. Examples

Example showing the “rgb” members of “in1” being assign the contents of the node “constant2”, and the “a” member being assigned the contents of the node “constant1”

<add name="add1" type="color4">
   <input name="in1" type="color4" />
     <member name="rgb" type="color3" nodename="constant2" />
     <member name="a" type="float" nodename="constant1" />
   </input>
   <input name="in2" type="color4" value="0.0, 0.0, 0.0, 0.0" />
 </add>

Example showing the “rgb” members of “in1” being assigned with the contents of “constant2” after applying the swizzle pattern “r1b”. “a” is assigned the the “x” member of constant1. The resulting value of in1 would be “0.1, 1.0, 0.7, 0.3”.

<nodegraph name="component_combine" type="">
    <constant name="constant1" type="float2">
       <parameter name="value" type="float2" value="0.3, 0.0" />
    </constant>
    <constant name="constant2" type="color3">
       <parameter name="value" type="color3" value="0.1,0.0,0.7" />
    </constant>
    <add name="add1" type="color4">
       <input name="in1" type="color4" />
         <member name="rgb" type="color3" nodename="constant2" channels="r1b" />
         <member name="a" type="float" nodename="constant1" channels=”x” />
       <input name="in2" type="color4" value="0.0, 0.0, 0.0, 0.0" />
    </add>
    <output name="out" type="color4" nodename="add1" />
 </nodegraph>

There appear to be issues with back-facing geometry when the shader is marked as being transparent (via a cutout so that you can see the back-facing geometry). Example snapshot:

Seems we need to add double-sided lighting support. Can be a generation. Depending on frequency of changes can be a shader input option.

Open in MURAL
MaterialX Triage Items - Autodesk DCP

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Resolving / finalizing the PBR library and standard surface in MaterialX which will be referenced as a submodule.

Open in MURAL
MaterialX Priority Items - Autodesk DCP

"Finalized" design

Currently nodegraph inputs and outputs are supported but these are not.
The fix is to generate the same addition CM code as noderaph inputs.

After migration these tests can be run as part of CI which runs Gen* tests by default. Render* are not run in CI at the current time.

There is the possibility for undefined divide by 0 results with the current implementations for GLSL and OSL

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Colour arrays
The specification refers to colour arrays but they are not implemented in the library.

How Arnold works around it

We need this for the ramp shader so what we do is that we define RGB/RGBA arrays as
a float array. When we encounter it we know Arnold expects a colour so we divide the
number of values by the number of expected colour components.

Parent Issue: #389

Missing relative to GLSL and OSL was "mirror" and "default".
Both are natively supported in OSL so no code generation changes are required.
For GLSL a mapping to an address mode which is used at render time also requires no update. The actual texture bind wrap modes have been updated to provide the correct settings as well as default color ("black" now sets a black color as expected, versus using the default color which was a defect).

Open in MURAL
MaterialX Priority Items - Autodesk DCP

We don’t currently support this either. We are waiting to discuss this with ILM but we may need
to drive this ourselves as it’s unlikely that they see this as a high priority. Maybe we should try to
come up with a convention that works for us and then push to include that in the standard

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Generalize the injected pre-processing math for uv streams

1. There is already the mx_get_target_uv() function which get's replaced with different versions depending on a global v-flip.
2. This can be extended to actually have arguments or just modify the internal code to chose which flip to perform. In addition scale+offset can be added.
3. The image source can be tokenized at the argument level or just inside the code. The second is easier.
4. To have control a new ImageNode.cpp node class is required which will get the source code, replace the tokens and emit the code.

Adding "smarter" global functions can be a way to have something akin to OSL stream globals.

Currently an exception is thrown but not caught which halts the test suite from continuing.

It seems when inserting a CM transform node the upstream output ports connection to the downstream input is not being broken properly. Need to break the input connection + the output connection to the input.
Added in unit test case to catch this.

Move to stdlib but rename it to <normal_map>.

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Currently GenOptions on the GenContext is mutable. Since the GenContext might be reused for successive generation runs we should make this immutable to avoid side-effects from tapering with these options.

• GLSL smoothstep does no adhere to spec when values are <= min or >= max range.
• Port OSL logic for hsv<->rgb for GLSL implementations.

For a clamp graph like this for vec2:

    <max name="ND_max_vector2_3" type="vector2">
      <input name="in1" type="vector2" interfacename="val" />
      <input name="in2" type="vector2" interfacename="i_min" />
    </max>
    <min name="ND_min_vector2_4" type="vector2">
      <input name="in1" type="vector2" nodename="ND_max_vector2_3" />
      <input name="in2" type="vector2" interfacename="i_max" />
    </min>
    <output name="out" type="vector2" nodename="ND_min_vector2_4" />
  </nodegraph>

The nodedef is this:

    <input name="val" type="vector2" value="0, 0" uiname="Value" />
    <input name="i_min" type="vector2" value="0, 0" uiname="Min" />
    <input name="i_max" type="vector2" value="1, 1" uiname="Max" />
  </nodedef>

The OSL produced looks like this:

(
    float dummy = 0.0,
    vector2 val = {0, 0},
    vector2 i_min = {0, 0},
    vector2 i_max = {1, 1},
    output vector2 out = {0.0, 0.0}
)
{
    vector2 ND_max_vector2_3_out = max(val, i_min);
    vector2 ND_min_vector2_4_out = min(ND_max_vector2_3_out, i_max);
    out = ND_min_vector2_4_out;
}

This is the scene.xml file used:

<World>
   <Camera eye="0, 0, 4"  dir="0,0,-1"  fov="70" />

   <!-- Background clear
   0.4 0.4 0.4 : is the background color
   -->
   <ShaderGroup>
      color Cin 0.4 0.4 0.4;
      shader constant_color_background layer1;
   </ShaderGroup>

   <Background resolution="1024" />

   <!-- Shader graph for routing to output layer:
   input_shader_parameter_overrides : are parameter overrides for the input shader
   NG_algclamp_vector2_out : type of an input shader to feed into the output shader.
   out : name of output argument on input shader.
   constant_vector2: type of the output shader used to render with
   Cin : name of input argument on output shader.
   -->
   <ShaderGroup>
      
      shader NG_algclamp_vector2_out inputShader;
      shader constant_vector2 outputShader;
      connect inputShader.out outputShader.Cin;
   </ShaderGroup>
   <Sphere center="0,0,0" radius="1.0" />

</World>

which uses this util shader:

surface 
constant_vector2
    [[ string description = "Simple closure for constant color surface rendering" ]]
(
    vector2 Cin = {0.0, 0.0}
        [[  string description = "Input color to modulate emission with" ]]
)
{
    Ci = color(Cin.x, Cin.y, 0.0) * emission(); 
}

Clamp {0,0} to {0,0}->{1,1} should give you {0,0} which gets converted into {0,0,0}*emission() = 0.
Result is current green with std distribution of OSL using testrender.

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Under discussion.

Updates #446

The option is part of generation options so we need to handle when a flip is set and
insert a v-flip checker in the correct places.

OSL background() rendering is the target for placement matching.

Currently we only get full paths out which makes libraries non-portable.

Add an option to GenOptions for generating a pure function instead of a complete shader.

Create node definitions and implementations (nodegraph) support for both.
Placement is to be determined.

This placeholder is to add in namespace support for look development. This includes:

1. Adding namespacing to existing definitions as needed.
2. Providing namespacing support for utilities which publish new definitions.
3. Support namespacing when managing definition libraries.

Issues:

1. Currently there are issues with importLibrary(). If this is called then the namespace is embedded into the imported Element names and the namespace qualifier is maintained. If imported again qualifier will be applied a second time resulting in multiple of the same namespace being applied. A symptom is that nodedef/nodegraph associations may be "lost".

• Issue was resolved as part of the 1.38 release.

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Open in MURAL
MaterialX Priority Items - Autodesk DCP

Includes:

• Filename building at bind vs shader time
• Wrap modes and related meta data.
• 3D vs 2D.

General issue to cover library, palette and preset support.

Cleanup / fix issues in RTS

Current spec allows combinations which it should not.
Spec fixes need to be reflected in implementation and shadergen.

You can only delete images to unbind then. Hence once the slots are filled you cannot load any more images in. There needs to be an way to unbind after usage. e.g. unit test example image.mtlx no longer loads images properly.

There are still some implicit casts. Need to fix to avoid compile time errors for some versions of GLSL.

This warning:
Below uniform is declared within a GLSL source block.: u_sheenAlbedo[0]
appears when trying to use shaders generated by compiled OGSFX code for standard surface.
@feldstj, @niklasharrysson this occurs for even the stock examples.

Lookup for additional uniforms needs to be fixed up.

For some reason the matrix value bindings related to 3d marble are not stable and will change based on some state. TBD if this is an integration issue or a code generation issue,