GeezerVison

I cannot find the new screenshots. Do I need to whitelist the new examples/mesh dir somewhere?

📚 Docs preview built and uploaded! https://www.fastplotlib.org/ver/mesh

Good start!

_graphic_methods_mixin.py is meant to be auto-generated, so we should make a SurfaceGraphic that probably just subclasses MeshGraphic.

Working on figuring out how to make the surface data dynamically settable so we can have a data @property. I think all the properties should be mutable like the other graphics where it make sense.

For general mesh:

• positions
• indices
• mapcoords
• cmap
• colors

For surface:

• data (which under the hood computes positions, indices, mapcoords)
• cmap
• colors

Seems like the normals have to be re-computed if using phong material when positions change. No difference with basic. Edit: Can just set the material.map again. Is there a flag for this we can set?

Anyways, I think we can make the basic material mode as the default and also allow phong and slice. Nah phong default seems best for most functions.

Are morph targets useful for this? Or just setting the position directly is the way to go?

I'm not sure if any of the existing "2D" selectors are useful here, in the future we could make a "cube selector", maybe based on the pygfx gizmo example using an expandable cube that can be used to select the triangles inside the cube?

Other than that that #545 might be useful here when it's available, and we could also make a selector that just allows selecting faces on a mesh (I think pygfx has an example for this, but we could maybe make a easy way to Cntrl + Click to build a selection?). Anyways not a priority for now, just thoughts.

I'm going to add a few commits to this branch based on #953 (comment)

I cannot find the new screenshots. Do I need to whitelist the new examples/mesh dir somewhere?

example dirs for tests are listed here:

Did you automate finding them in pygfx?

Similarly for docs that dir needs a readme, making these changes in #954

This relies more on PyGfx colormap mechanics. I am not sure why fastplotlib 'renders' its own colormap into vertex colors for lines and scatter.

pygfx.cm.create_colormap() didn't exist when we implemented lines and scatter, is this what you mean?

Edit: I see LineMaterial.map which can be a TextureMap. Is it possible to apply what we call a "cmap transform" as well, for instance in this example it samples from the colormap using the y-values of a sine function: https://www.fastplotlib.org/ver/dev/_gallery/line/line_cmap.html#sphx-glr-gallery-line-line-cmap-py

But this can be arbitrary, we often use it to indicate things like velocity along a 2d trajectory.

I cannot find the new screenshots. Do I need to whitelist the new examples/mesh dir somewhere?

a comma was also missing, added it , slipped by in the vectors PR

pygfx.cm.create_colormap() didn't exist when we implemented lines and scatter, is this what you mean?

Edit: I see LineMaterial.map which can be a TextureMap. Is it possible to apply what we call a "cmap transform" as well, for instance in this example it samples from the colormap using the y-values of a sine function: https://www.fastplotlib.org/ver/dev/_gallery/line/line_cmap.html#sphx-glr-gallery-line-line-cmap-py

Ah, create_colormap() not existing at the time explains it. Though it would be nice if fpl could simply leverage Pygfx's colormap support, by setting geometry.texcoords and material.map.

If I understand correctly, the current line's geometrytexcoords are simply the vertex indices, and map_transform is used to map that to real values. So in fact, the current map_transform is the mapcoords. Which is good news, I guess, because it means moving to pygfx doing the colormapping should be relatively easy (in a different pr).

edit: easy as in not that complex. Still quite a bit of work, I imagine.

If I understand correctly, the current line's geometrytexcoords are simply the vertex indices, and map_transform is used to map that to real values. So in fact, the current map_transform is the mapcoords. Which is good news, I guess, because it means moving to pygfx doing the colormapping should be relatively easy (in a different pr).

Yes! Thanks I understand it better now :)

@almarklein I think this is done 🥳 . Let me know what you think

I was getting ready to update the buffer resizing logic for the poly data, but saw you already fixed that too. Awesome! Ready from my end then! 👍