|
|
|
|
|
decomposed_tetWedge_render_01.png (27,128 bytes) |
|
|
decomposed_tetWedge_render_02.png (23,965 bytes) |
|
|
This is odd... I know I saw yesterday the decomposed tetWedge had a better render than the polyhedron render... but it looks like whatever I saw was either a fluke or I messed up the decomposed cell selection... Anyway, attached at the following the images "decomposed_tetWedge_render_*.png" (using ParaView 5.0.1), which show two slightly different perspectives for two representations of the decomposed tetWedge: - On the left is a representation for when the 4 cells (2 pyramids and 2 tets) as a single mesh entity; which is pretty much the same exact render as given with the single polyhedral cell or the VTK_WEDGE with a collapsed edge. - On the right is the representation of two groups of cells: 3 cells are separated from the 4th cell, because the 4th cell is the one that is used for rendering the collapsed face of the tetWedge. - This may give a little bit better representation of the original cell, but this 4th cell is actually a warped prism, which is why the blue edge goes into the grey surface on this representation. Therefore, the only real benefit of decomposing a tetWedge, instead of using VTK_WEDGE with a collapsed edge, is that it will also fix the issue of the triangles showing up inside the mesh when the mesh is decomposed. |
|
|
Should this approach be applied to all cell which have collapsed edges? Or should the mesher guarantee that collapsed edges are removed from the mesh? During mesh-motion collapsed edges could be generated and removal would require topology change which otherwise might not be needed. How small an edge should be collapsed? What is the minimum edge-length that VTK can handle and render the corresponding face correctly? |
|
|
On the point about maintaining support for cell-decomposition rather than replacing it with VTK_POLYHEDRON is that the current situation is partly historical and partly that VTK_POLYHEDRON is (was?) rather restrictive requiring the cells to be convex which cannot be guaranteed, even with foamyHexMesh with edge collapse. Do you know if VTK_POLYHEDRON has been generalized yet or is it still restricted to convex shapes? |
|
|
> Should this approach be applied to all cell which have collapsed edges? The only reason (that I've seen so far) as why to not use "VTK_WEDGE" to represent a "tetWedge", is mostly just to avoid future reports of "there's some weird triangles inside my mesh" and also to reduce maintenance for this particular cell render, as done so far. The only specific problem with edge collapsing is related to how the 5 vertex "tetWedge" is fitted into the 6 vertex "VTK_WEDGE". The limitation is on the ParaView/VTK rendering side, not on OpenFOAM's side. The perfect solution would be to have a dedicated cell shape that could be used in ParaView/VTK to represent these "tetWedge" cells, so that they would be properly rendered in ParaView/VTK. That would probably also sort out some other rendering limitations in there as well. Unfortunately, that's beyond my current capabilities/time-frame. I did some research into what ParaView/VTK is currently able to handle and the only/closest related detail to the "tetWedge" that I could find was a diagnostic algorithm that was extracted from a software named VERDICT, which in turn refers to this cell shape as "knife": https://github.com/Kitware/VTK/blob/master/ThirdParty/verdict/vtkverdict/V_KnifeMetric.cpp - at least it's what it looks like from the description. > Do you know if VTK_POLYHEDRON has been generalized yet or is it still restricted to convex shapes? Quoting from the VTK code documentation: http://www.vtk.org/doc/nightly/html/classvtkPolyhedron.html#details The class does not require the polyhedron to be convex. However, the polygonal faces must be planar. Non-planar polygonal faces will definitely cause problems, especially in severely warped situations. This is consistent with what I've seen so far: - tetWedge does have one face that is not planar and therefore it's not rendered properly, no matter which strategy is used... or at least I haven't found one yet. - I saw some complex polyhedrons on the meshes from issue #2099 which were not rendered properly, also due to non-planar faces. > On the point about maintaining support for cell-decomposition [...] Sorry, I formed my sentence(s) on this topic incorrectly. What I meant to say is that given we have VTK_POLYHEDRON as an option, it can be used when detailed diagnosing of the mesh is needed, instead of relying on the VTK_WEDGE render for the tetWedge. Support for cell-decomposition should be kept in and support maintained for it, at the very least as a fail-safe measure, because several of the post-processing algorithms in ParaView/VTK still have problems handling polyhedron cells, many of which lead to crashes. Progress has been made in recent versions, but last time I checked, it's still not bullet-proof. |
|
|
> The only specific problem with edge collapsing is related to how the 5 vertex "tetWedge" is fitted into the 6 vertex "VTK_WEDGE". The limitation is on the ParaView/VTK rendering side, not on OpenFOAM's side. Understood, but collapsed edges may occur for any cell-shape presumably generating the same problem; how should it be handled in general? > However, the polygonal faces must be planar There is no way we can guarantee planar faces without tet-decomposition. |
|
|
> Understood, but collapsed edges may occur for any cell-shape presumably generating the same problem; how should it be handled in general? OK, now I finally managed to understand the line of thought on what you wrote. And I can't believe I missed that the "wedge" is represented as a "VTK_HEXAHEDRON" with a collapsed edge... I looked at the code so many times the past few days and I always overlooked that detail. That was why I wasn't being able to see from that perspective. I ran the tutorial case "mesh/foamyHexMesh/flange" and I believe I finally saw what you've written about. On the surface, after using "collapseEdges", there are several holes in the surface of the mesh, specifically due to these "wedge" cells. (Oh... wow... I remembered to look inside the mesh... and there are a ton of floating triangles inside it...) From what I can see, there is at least one vertex that is incorrectly assigned as well, when doing "wedge" -> "VTK_HEXAHEDRON", as what happened for #1633, but a similar fix would not solve this issue either, namely the triangles inside the mesh. I still have to test this, but "VTK_POLYHEDRON" should be able to take over this particular cell representation, although the collapsed face might look as incorrect as the one on "tetWedge", i.e. it flattens part of the face. Hopefully the decomposition of the "wedge" cell will preserve the overall representation... but I still need to test that as well. As for "when should edges be collapsed": I did a test with "combustion/engineFoam/kivaTest", by setting the parameters in "constant/engineGeometry" to result in the piston going farther into the top of the chamber; as long as the cells didn't overlapped each other, ParaView/VTK was able to render the nearly flat cells without artefacts. The positions of the vertexes were roughly 5e-6 m apart from each other (if I remember correctly). It did not have render problems, because the vertexes were defined as independent positions; the problems usually occur after cleaning up the mesh, i.e. when collapsing small edges, as you've mentioned. > There is no way we can guarantee planar faces without tet-decomposition. I still need to figure out what should be the correct representation for the non-planar faces. ParaView/VTK does have a few situations where it renders a face with omitted edges on its surface, since it's bending said surface... but still... it doesn't look right either way. |
|
|
I've changed this from status "assigned" to "new", until I or anyone else can look better into this. I'll look into this in the upcoming weekend. |
|
|
I haven't yet found time and inspiration to look better into this, but I do bring interesting news on the topic of concave cells and their rendering in ParaView. The following email thread: http://public.kitware.com/pipermail/paraview/2016-October/thread.html#38267 - demonstrates that the current OpenGL2 implementation that ParaView is using in 5.2 is giving fair results when compared with OpenGL, as shown in the first email of the thread: http://public.kitware.com/pipermail/paraview/2016-October/038267.html This means that OpenGL2 has helped to get better rendering results for the more complex shapes, although I don't know yet what are its limitations on this. |
|
|
Uploaded a 1 cell testcase which displays funny. Guess this is related to the discussion. |
|
|
@MattijsJ: Many thanks! @Henry: I'm suspending this issue for now. This can be revisited after the various VTK IO capabilities are consolidated. |
- Anonymous
