Skip to content

Conversation

@AlejandroFernandezLuces
Copy link
Collaborator

@AlejandroFernandezLuces AlejandroFernandezLuces commented Feb 6, 2026

Plotly example results:
image

PyVista example results:
image

@github-actions github-actions bot added the enhancement New features or code improvements label Feb 6, 2026
@AlejandroFernandezLuces AlejandroFernandezLuces linked an issue Feb 6, 2026 that may be closed by this pull request
@moe-ad
Copy link
Contributor

moe-ad commented Feb 8, 2026

Thanks for this @AlejandroFernandezLuces. I pushed 9626ba9 to support the parallel work going on in ansys/pydpf-core#2881.

You may want to tweak the method names or argument types a bit such that they are even more generic. But they work fine for pydpf-core in their current state. Let me know what you think.

@AlejandroFernandezLuces
Copy link
Collaborator Author

Thanks for the contribution @moe-ad! A couple of comments regarding your changes:

  • I'm not fully sure why the need for add_mesh method. This is covered by plot, thats the whole point of the method, to add meshes from different backend. Could you clarify the need for this method?
  • Also not sure if the clear() method would add any value. Not really against it, but following the current status of the visualization tool, after a show() it is expected that you shouldn't use that Plotter instance again. In PyVista, after showing a plot, you cannot use that instance again, so we have to adapt to that. Having this into consideration, what would be the use case of clear()?
  • I would say that add_point_label is a PyVista concept, rather than a generic API. What is the difference between adding a point label and adding text in one specific position?

Also, examples for public APIs and tests needs to be added to your changes. Since this is still ongoing from my end, may I ask to move your changes to another PR and discuss there to not block here?

@moe-ad
Copy link
Contributor

moe-ad commented Feb 9, 2026

Hi @AlejandroFernandezLuces:

  • Apologies for this one, I agree that add_mesh shouldn't be present in ansys-tool-visualization-interface truly. It skipped my mind that plot could have been used, thanks for catching that.
  • For clear, it has been quite useful for building a scene interactively. Say I created a plotter, added some mesh, and then decided I would like to swap that with a different one (prior to "showing" the plot of course), I can just call clear on the already created plotter rather than having to create a new one.
  • Three reasons served as motivation for wanting add_point_labels (of course besides wanting to make my life easier in pydpf-core... 😁):
    • Adding text to a world coordinate currently uses pv.Text3D which does something completely different from pv.Plotter.add_point_labels from what I understand. pv.Text3D creates an actual pv.PolyData mesh behind the scenes, meaning it becomes increasingly more expensive to render the labeling for large datasets as will be the case for a library like pydpf-core. Being an actual mesh also implies no autoscaling as you zoom in and out of the scene, meaning harder to read text. So I would say pv.Text3D is not suitable for annotating the nodes of a mesh. (This answers "What is the difference between adding a point label and adding text in one specific position" by the way)
    • I wanted a more abstracted API to which I could just pass a list of point data and a list of labels for those points for the annotation. Like I mentioned, maybe add_point_labels isn't necessarily the name to call such a method in viz.
    • I also recognized that the current implementation of add_text with pv.Text3D might have some other interesting use cases, and maybe adding a new API and not updating add_text is a good way to proceed.

The reason why I added changes directly to this PR is that I am already plugging into methods you implemented, like add_points and add_lines, and I thought it was more straightforward to add any additional APIs needed here and then point your branch from the pydpf-core PR.

Thinking about it, I can probably move my changes to a separate PR truly and then target yours as the base branch (at least till you merge).

@moe-ad moe-ad force-pushed the feat/customization-api branch from 7480408 to 7aed2b6 Compare February 9, 2026 15:01
@moe-ad
Copy link
Contributor

moe-ad commented Feb 9, 2026

@AlejandroFernandezLuces moved to #466.

@github-actions github-actions bot added the testing Anything related to testing label Feb 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New features or code improvements testing Anything related to testing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Backend-agnostic APIs for customization

3 participants