Cloverleaf placement appears incorrect

[kwokcb]

Issue

If you create a cloverleave node and try and center it it will not be placed where expected. If you use the same placement inputs for circle or hexagon it does.

I'm unsure if there is any upgrade issue as channels is used in the implementation nodegraph or just is pre-existing ?

Test Data

Output on a 2d plane. BTW a center of 1,1 places it in the center for some reason ?

File used:

<?xml version="1.0"?>
<materialx version="1.39" colorspace="lin_rec709">
  <surfacematerial name="surfacematerial_material1" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="convert_surfaceshader1" />
    <input name="displacementshader" type="displacementshader" value="" />
  </surfacematerial>
  <tiledcloverleafs name="tiledcloverleafs_color4" type="color3">
    <input name="texcoord" type="vector2" value="0,0" />
    <input name="uvtiling" type="vector2" value="1,1" />
    <input name="uvoffset" type="vector2" value="0,0" />
    <input name="size" type="float" value="0.5" />
    <input name="staggered" type="boolean" value="false" />
  </tiledcloverleafs>
  <convert name="convert_surfaceshader1" type="surfaceshader">
    <input name="in" type="color3" nodename="tiledcloverleafs_color4" />
  </convert>
  <surfacematerial name="surfacematerial_material2" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="convert_surfaceshader2" />
    <input name="displacementshader" type="displacementshader" value="" />
  </surfacematerial>
  <cloverleaf name="cloverleaf_float1" type="float">
    <input name="texcoord" type="vector2" value="0,0" />
    <input name="center" type="vector2" value="0.5,0.5" />
    <input name="radius" type="float" value="0.25" />
  </cloverleaf>
  <convert name="convert_surfaceshader2" type="surfaceshader">
    <input name="in" type="float" nodename="cloverleaf_float1" />
  </convert>
  <circle name="circle_float1" type="float">
    <input name="texcoord" type="vector2" value="0,0" />
    <input name="center" type="vector2" value="0.5,0.5" />
    <input name="radius" type="float" value="0.25" />
  </circle>
  <convert name="convert_surfaceshader3" type="surfaceshader">
    <input name="in" type="float" nodename="circle_float1" />
  </convert>
  <surfacematerial name="surfacematerial_material3" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="convert_surfaceshader3" />
    <input name="displacementshader" type="displacementshader" value="" />
  </surfacematerial>
  <surfacematerial name="surfacematerial_material4" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="convert_surfaceshader4" />
    <input name="displacementshader" type="displacementshader" value="" />
  </surfacematerial>
  <convert name="convert_surfaceshader4" type="surfaceshader">
    <input name="in" type="float" nodename="hexagon_float1" />
  </convert>
  <hexagon name="hexagon_float1" type="float">
    <input name="texcoord" type="vector2" value="0,0" />
    <input name="center" type="vector2" value="0.5,0.5" />
    <input name="radius" type="float" value="0.25" />
  </hexagon>
</materialx>

[kwokcb]

Leaving a ping for @ashwinbhat as I believe you and Roberto worked on these ?

[dbsmythe]

I had similar observations about several of the Shape nodes, wondering if they should be updated to be more consistent, predictable and complete:

• Should the default value for "center" in <circle>, <cloverleaf> and <hexagon> be (0.5, 0.5) and not the currrent (0,0)? That would make the pattern default to being centered in the 0-1 space rather than cut off in the corner.
• For <cloverleaf>, the pattern is currently centered if "center" is 1,1, and is placed in the upper-right if "center" is 2,2. I think "center" input value should be internally multiplied by 2 so the user sees input values of 0-1 with 0.5 in the center.
• Should <hexagon> have a rotation angle input to make it more general?
• In <tiledcircles> with "staggered" turned on, the pattern is not the specified uvtiling height. It looks like this was done so the circles are exactly on equilateral triangle vertices? If so, should there be a boolean input to switch between "circles on equilateral triangle vertices" mode vs "fit the uvtiling size in U and V"?

[kwokcb]

Yes.

• To me it's strange that the default places the pattern so it's 1/4 cropped at 0,0. DCCs AFAIK center the pattern. It would be nicer IMO to have the patterns centered normalized UV space by default,
• The line pattern is quite stange to me as well as it's a line that is diagonal from the 0,0 to 1.1
  • it looks like a a line with 2 circles at the end ?
  • center is 0,0 which actually places it centered at 0.5, 0.5 so is also inconsistent
  • radius I believe is thickness of the line., but I guess referes to the radius of the circles at the end points.
  • I have no idea if I can get a vertical or horizontal line without circles.. This is the best I could do.

but it's a lot of work to offset the line to handle the radius. Also can't get rid of the circles ?

[dbsmythe]

<Line> actually makes sense to me: the point1 and point2 positions are the centers of the endpoints of the line, and radius is the half-thickness of the line, so all pixels that are within "radius" pixels of the (infinitesimally-thin) line between point1 and point2 are "on". The only addition I would suggest is like I mentioned at the TSC meeting, to have a "color3" variant of <line> as well as float, which would have a pair of color inputs to define the "in the line" and "not in the line" colors. And same for all other Shape nodes: have both float-output and a color3-output variants of all of them rather than "some output float, some output color3". Though maybe better choices for the two color inputs would be "colorfg" and "colorbg" rather than color1/color2 so it's more clear which color input drives the color of the pattern and which is the non-pattern background color.

[kwokcb]

• For radius, I guess what I was looking for was a rectangle for a line with a width / height or a single thickness. Perhaps a different primitive to add.
• Having center is still weird to me. If you set it to 0.5, 0.5 then just offsets the entire line so may it should be called offset ?
• Having color variants would be good. I have been creating graphs to remap to colors.

[zicher3d]

The circles on the line ends is because we are using a signed distance field formula. If we use rectangles we will have issues connecting lines together. I guess we could have option or another line node for rectangle ends. I haven't thought about that.

[zicher3d]

Regarding circles, hexagon, or cloverleaf position. The initial position is consitent but yes, looks like the offset for cloverleaf needs to be multiplied by 2. That should be fixed. But the tiled version works ok, maybe there it's compensated somehow. if we fix one we need to probably "unfix" the other.