Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fem: Partial transparency fix in FemPostObject display modes #12918

Merged
merged 2 commits into from Mar 13, 2024

Conversation

marioalexis84
Copy link
Member

This pull request is an attempt to fix #6996:

The transparency type used by the scene graph is SORTED_OBJECT_SORTED_TRIANGLE_BLEND. This transparency mode works well with polygons using a SoMaterial with multiple colors but does not handle points and lines correctly: In this mode with transparency enabled, lines and points are rendered using only the first color in the color array (current behavior) .
According to the Coin documentation, these objects should be passed in the SORTED_OBJECT_BLEND mode, but in order to be effectively drawn with transparency respecting the color array, it is necessary to enable this mode explicitly, for example, by using a SoTransparencyType object within the shape separator.
Doing that still doesn't work correctly because the order on the screen doesn't respect the z-value of the shape elements (the back lines and dots are rendered on top of the front objects seemingly randomly). (see figure 1).
The shapes are drawn in the correct order if the transparency mode is BLEND (fig. 2), but the problem with this mode is that if there is another shape behind the transparent object, the background color is visible (fig. 3).
To mitigate this issue, the buffer depth test is disabled if the object is completely transparent.

Another unreported issue is fixed with the first commit.
Currently it is necessary to activate the backlight to work with Fem Pipeline objects.
This occurs because the nodes of the Fem mesh are exported to the VTK array in wrong order (nodes of the SMSH elements do not respect the same order as the VTK cells points).
Sorting the nodes correctly fixes this problem and the backlight is no longer necessary.

fig1
fig1.

fig2
fig2.

fig3
fig3.

@github-actions github-actions bot added the WB FEM Related to the FEM Workbench label Mar 13, 2024
@marioalexis84
Copy link
Member Author

@FEA-eng

@FEA-eng
Copy link
Contributor

FEA-eng commented Mar 13, 2024

Nice, I tested this and it's working properly. It's great to also get rid of the annoying red warning text about the recommended backlight usage.

@chennes Can you merge this?

@marioalexis84
Copy link
Member Author

#6996 could be closed and replaced with an issue explaining why this pull request does not resolve the issue completely and also report the issue in the Coin repository.

@FEA-eng
Copy link
Contributor

FEA-eng commented Mar 13, 2024

#6996 could be closed and replaced with an issue explaining why this pull request does not resolve the issue completely and also report the issue in the Coin repository.

Right, it makes sense. Fortunately, the remaining issue is IMO really minor from the FEM postprocessing perspective.

@chennes chennes merged commit 843f6e8 into FreeCAD:main Mar 13, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WB FEM Related to the FEM Workbench
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] [FEM] adding transparency destroys mesh result coloring
3 participants