These visualization pipelines are the kind of feature you would get for free if the output of a Ferrite.jl simulation lived on a GeoTables.jl over a Meshes.jl. We support nearly 100 transformations at this point. I understand you might have specific needs that justify spending human resources writing project-specific viz features though.
Not sure why you try to start a discussion in a release announcement thread, but I have to really correct that statement you made that we get the same features for free. We started developing FerriteViz in 2021 as a specialized visualizer for finite elements and we actually tried to get the foundation integrated with GeometryBasics.jl . Meshes.jl has been started in 2024 and I have looked into the package every few months to see where it goes, but there is just not much infrastructure which we can use for our purposes. The library itself is fine, it just does not fit any of our needs. Means, even if we depend on Meshes.jl, which is of course possible, then we still need to roll all the internal infrastructure to handle the mappings and nonlinearities ourselves. Also note that we already rolled the necessary infrastructure and at this point I honestly do not see if there is any gain in refactoring the front-end of our visualizer to fit into different framework just for the purpose of having that other framework as a front-end.
If you want to discuss this with the community, then I would kindly ask to rather open up a separate thread taking up that matter about visualization frameworks, as I do not think that future users/developers/readers/… will search for a discussion about finite element visualization frameworks in the Ferrite release announcement thread.
Sounds good. I wanted to understand the rationale and thought it would be a good idea to comment on this thread. Sorry.
It is not clear to me why Meshes.jl does not fullfill your requirements. I can’t understand how GeometryBasics.jl is preferred in the context of FEM.
Please feel free to ask forum admins to move this discussion to a separate thread. Happy to continue the discussion.
You should understand, if anyone, I bet a lot of people said “just export to VTK and let ParaView handle it” with your project 
It is a reasonable solution if the only objective is to perform the standard set of visualizations. Sometimes, however, people will be interested in filtering, transforming the solution interactively, adding and removing objects from the scene, and that is when Makie.jl recipes come in.
My first comment was about human resources dedicated to a project-specific viewer, which could be saved if all these different projects shared a common Meshes.jl infrastructure 
❯ Do you think Meshes.jl and its visualization would be a good fit for finite element simulation visualization?
● Short answer: no — not as a foundation for FE visualization, though it’s a reasonable interop/geometry library to sit next to one.
Having just looked at where FerriteViz has landed (a FEData dataset + composable filter pipeline: WarpByVector, CrinkleClip, Threshold, Gradient, Refine, AddQuadraturePointData), you’ve essentially adopted the VTK/ParaView data-model. That’s the right abstraction for FE, and it’s a different abstraction than Meshes.jl offers.
Where the mismatch bites:
- No function-space concept. Meshes.jl elements are straight-sided geometric primitives defined by vertices; a SimpleMesh + GeoTable carries data on vertices or on elements, full stop. FE fields are DoF-based: quadratic/serendipity geometry, discontinuous (per-cell-per-node) fields, H(div)/H(curl) interpolations, quadrature-point data. Every one of those has to be tessellated down to linear triangles anyway — which is exactly what tessellation.jl/qptessellation.jl do, straight from Ferrite’s interpolations. Routing through Meshes.jl means losing the interpolation information first and then trying to recover fidelity by refinement.
- viz is a thin Makie recipe. It buys you nothing FerriteViz doesn’t already have via direct
Makie.mesh/ShaderAbstractions access — and it costs you control over shading, per-vertex color observables, and the SpecApi-driven interactive viewer. FE viz needs the low-level path.- Points carry units + CRS. Since the CoordRefSystems.jl integration, Meshes.Point is a georeferenced, unitful thing. That’s excellent for GeoStats and a tax for FE, where you want plain Vec{dim,T}/Tensors coordinates that convert to Point3f with zero ceremony.
- Release cadence. Meshes.jl is the substrate of a fast-moving ecosystem and breaks regularly. FerriteViz’s compat surface is already tight (Ferrite 1, Makie 0.24, GeometryBasics 0.5) — adding a heavy dep whose breaking releases you don’t control makes every Ferrite/Makie bump harder.
Where it would genuinely fit: as an optional extension for geometry operations FerriteViz doesn’t want to own — clipping/boolean ops against arbitrary solids, point-in-cell queries, isosurface/contour extraction, sampling, partitioning. A MeshesExt that converts a tessellated FEData → SimpleMesh for those operations (and back) is cheap and low-risk. That’s interop, not architecture.
If you’re looking for something to lean on more heavily, the more natural candidates are staying with GeometryBasics + Makie directly (status quo, and it’s working), or leaning further into the VTK data-model you’ve already replicated.
Below you can find some replies. Is this coming from an AI agent? Keep in mind that AI agents use your chat history to give very biased answers. If I ask the same question to my ChatGPT, it will say wonders about Meshes.jl and how it should be used instead of reinventing the wheel.
That is by design, like with GeometryBasics.jl. Any function approximation is in the FE scope, not the geometry library. Given well-designed primitives, it shouldn’t be hard to write higher-level constructs, and that is probably what you did in Ferrite.jl on top of GeometryBasics.jl anyways.
It buys you development time. Our recipe works with all kinds of meshes and GIS stuff, with actual coordinates in the real world, and that is very hard to reproduce. If you intend to do FE with models that are actually located in the globe, you will better understand the challenges involved.
I am genuinely curious about this one. Why is it an issue to assume that “meter” units are everywhere? At the end of the day, you are dealing with units implicitly when you use raw numbers. Is it about runtime performance? Type inference?
Depending on your perspective, that could be seen as a good thing. It is actively maintained with issues fixed within 24h on average I would say. We break sometimes because developing a general geometry library is not a trivial thing. We are almost there, but it took a lot of iteration to achieve a design that can encompass non-Euclidean geometry, CRS, etc.