Humble request for FEM

[drei]

Would it be possible to add an option in the preferences to set the view of certain objects as false?

I've noticed that I really don't need to visualize the flags that show the location of forces or restricted faces, and my machine lags really bad if I work with objects of large sizes.

Either that or could we change how this is visualized? Perhaps an option to set how many items to display in a certain area, the spacing, color, etc.

I understand the need for visual feedback but consider how much resources are used just to render those elements (the round/cylindrical flags).

Regards,
Isaac

[sgrogan]

Would it be possible to add an option in the preferences to set the view of certain objects as false?

I've noticed that I really don't need to visualize the flags that show the location of forces or restricted faces, and my machine lags really bad if I work with objects of large sizes.

Either that or could we change how this is visualized? Perhaps an option to set how many items to display in a certain area, the spacing, color, etc.

I understand the need for visual feedback but consider how much resources are used just to render those elements (the round/cylindrical flags).

Regards,
Isaac

I think they're working on it:
viewtopic.php?f=18&t=10489#p84361

[PrzemoF]

My proposition for the options:
A numeric filed "Maximum number of supports shown per face" set to default 100
A numeric filed "Maximum number of force arrows shown per face" set to default 100

The numbers will be used in a similar way as here: viewtopic.php?f=18&t=10489#p84374
except instead of a fixed limit per direction it will try to spread them evenly.

The supports/arrows can be hidden/shown, but it's not in the right click menu - you have to select a force/constraint and hit "space" key instead.

[wmayer]

In the first place the rendering itself must be fixed. There are a couple of things to check to speed it up and from a quick look at the code all this is done very inefficiently.
And from a simple change I could fix a 50MB memory leak only for Bernd's simple cantilever example. git commit 618192f

[wmayer]

See also here: viewtopic.php?f=18&t=10489&start=10#p84750

1. It could be checked if using SoGroup instead of SoSeparator speeds it up
2. It could be checked if for every little indicator a new sub-graph is created or if only one instance is created with a different translation node
3. It could be checked if using SoMultipleCopy node can be used
4. It could be checked if display lists or other OpenGL tricks can be applied

Unfortunately, point 2.) is true which is a waste of memory. Even it wouldn't reduce rendering time but to reduce memory usage we could re-use the same instance of an indicator and show it in different places instead of creating thousands of indicators.
Also, I tested the use of display lists (by using sep->renderCaching = SoSeparator::ON) but this is only a minor improvement.

[PrzemoF]

A temporary patch that limit number of support/force marks on large faces:

Code: Select all

diff --git a/src/Mod/Fem/App/FemConstraint.cpp b/src/Mod/Fem/App/FemConstraint.cpp

index 565167e..8280106 100644
--- a/src/Mod/Fem/App/FemConstraint.cpp
+++ b/src/Mod/Fem/App/FemConstraint.cpp
@@ -203,6 +203,10 @@ const bool Constraint::getPoints(std::vector<Base::Vector3d> &points, std::vecto
                 stepsu = (int)round(lu / 10);
             else
                 stepsu = 2;
+            if (stepsu > 20)
+                stepsu = 20;
+            if (stepsv > 20)
+                stepsv = 20;
             double stepv = (vlp - vfp) / stepsv;
             double stepu = (ulp - ufp) / stepsu;
             // Create points and normals

[wmayer]

The issue is completely solved with git commit 2dc1890.
The actual bottleneck was that a transparency of 10% was set which caused this extreme slow-down and needed extra memory of 800MB (!!!). The fix also uses SoMultipleCopy to reduce the number of nodes.