Thanks! Can you please add a test for this? I think that maybe your example could be a good one.

Note that this is adding a 3D version oftripcolor functionality. That does at need to be specified in the docs somewhere so that users of 2Dtripcolor wanting to move to 3D can search for it and end up here. Also, in the 2Dtripcolor the argument is calledC (the array of color values) which is probably a better choice thanvalues here on the grounds of consistency.

[N/A] New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).

This appears to be a new feature; I'm not sure why you marked it as N/A.

Note that this is adding a 3D version oftripcolor functionality. That does at need to be specified in the docs somewhere so that users of 2Dtripcolor wanting to move to 3D can search for it and end up here. Also, in the 2Dtripcolor the argument is calledC (the array of color values) which is probably a better choice thanvalues here on the grounds of consistency.

It is not really the same behavior as intripcolor. In the 2Dtripcolor theC allows to define colors directly for each vertex or face. Here in my PR, the specifiedvalues are first color-mapped and then the faces are colored with the result.

• I agree that aC argument specifying individual face colors manually is a good idea and is a missing feature in the implementation.
• Thevalues allow specifying values at each vertex, which are then used to determine colors at each face via the colormap. This is different, but I believe it is still a very convenient and needed feature. Often we know point-data on the vertices and wanna colorize it accordingly. We just need to decide a name for thekeyword argument. I agree thatvalues is not a good name. Suggestions?

Note that this is adding a 3D version oftripcolor functionality. That does at need to be specified in the docs somewhere so that users of 2Dtripcolor wanting to move to 3D can search for it and end up here. Also, in the 2Dtripcolor the argument is calledC (the array of color values) which is probably a better choice thanvalues here on the grounds of consistency.

It is not really the same behavior as intripcolor. In the 2Dtripcolor theC allows to define colors directly for each vertex or face. Here in my PR, the specifiedvalues are first color-mapped and then the faces are colored with the result.

* I agree that a `C` argument specifying individual face colors manually is a good idea and is a missing feature in the implementation.* The `values` allow specifying values at each vertex, which are then used to determine colors at each face via the colormap. This is different, but I believe it is still a very convenient and needed feature. Often we know point-data on the vertices and wanna colorize it accordingly. We just need to decide a name for the `keyword` argument. I agree that `values` is not a good name. Suggestions?

Should it useC for both options? WhenC is shape(n,3/4) use it as colors directly and if shape is(n,) map it first? Actuallyscatter does it this way, there it's a smallc, though.

[N/A] New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).

This appears to be a new feature; I'm not sure why you marked it as N/A.

I though the change is so small, that it cannot really be called a new feature, but okay, will add it to whats new.

Thank you all for the input. I did some changes to the PR:

• the new keyword argument for custom data used for color-coding is now calledc, as inplt.scatter(..). It is on purpose not calledC as intripcolor, because there we give colors directly, not values to be mapped to colors. The data inc can be one value per vertex OR one value per face. Which of these options applies is determined based on the shape - as intripcolor. If no colormap is specified, thenc is interpreted as a row-wise rgb/rgba color matrix, again either in terms of vertex colors (averaged on face) or face colors. This then resembles the behavior ofC intripcolor.
• I have written two test cases
• There is now a What's New article
• There is also an example file
• As intriplot there is also a new keyword argument calledfacecolors, which can be used to directly set the face colors as RGB or RGBA values.

It is on purpose not calledC as intripcolor, because there we give colors directly, not values to be mapped to colors.

Look again!

importmatplotlib.pyplotaspltx= [0,1,1,0]y= [0,0,1,1]C= [0,1,2,3]fig,ax=plt.subplots()mappable=ax.tripcolor(x,y,C)fig.colorbar(mappable,ax=ax)plt.show()

Oh, okay. You are right. I have not tried it, just read the documentation herehttps://matplotlib.org/3.1.1/api/_as_gen/matplotlib.pyplot.tripcolor.html

There it says thatC must be color values or I got the text wrong. It is a bit misleading there in the documentation. I will update the documentation oftripcolor and rename myc toC okay?

This is the warning in the failing doc-build:

/home/circleci/project/doc/gallery/mplot3d/trisurf3d_3.rst:24: WARNING: Title overline too short.

I think that you may need to create a new branch as there are changes on the main branch that are required to make the tests pass and since you have used your main branch, it is not really possible (in an easier way) to sort it out. Something like:

git branch trisurfcustomcolorgit reset --hard HEAD~7git pull upstream maingit checkout trisurfcustomcolorgit rebase maingit push origin trisurfcustomcolor

And then open a new PR with thetrisurfcustomcolor branch.

You may have to set upstream if it complains in the third step:

git remote add upstream git@github.com:matplotlib/matplotlib.git

Here is a more general description:https://stackoverflow.com/questions/1628563/move-the-most-recent-commits-to-a-new-branch-with-git

I think the casing c vs C is not consistent in our docs. In general, we tend to use uppercase for 2D arrays (thinkX, Y = np.meshgrid(x, x)), e.g. pcolormesh. I suspect that the tripcolor uppercase C leaked from there.

@aaarne Do you plan to come back to this? Let us know in case you need any help.