You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Medium priority optimization
Drawing speed:
When drawing around 1000 basic shapes (I.e lines) the simulation computation speed drops significantly. In some cases, this can cause misinterpretations in algorithm performance and the developer needs to be mindful at the drawing speed of something that seems relatively simple.
There could be a few suggestions for solving this:
Group shapes together that are similar (for example, if there are 100 small line segments lined up end to end, it can be grouped together into a single long line.)
Limit the number of drawn shapes.
Camera occlusion/ frustum culling, where only shapes in the camera view is rendered (not sure if this is already implemented)
Levels of detail, where it limits the levels of detail being rendered when they are outside a certain range from the camera.
The text was updated successfully, but these errors were encountered:
This is a major undertaking. SCRIMMAGE ideally, would not be used for rendering anything and we would use something like OpenSceneGraph, Unity, or Unreal for rendering.
This is a challenging problem. SCRIMMAGE currently uses VTK for its viewer and I don't know if there is a simple solution following any of the paths you have proposed. We are considering moving to a Cesium-based SCRIMMAGE viewer that may take care of some of this, see Michael's comment above.
Medium priority optimization
Drawing speed:
When drawing around 1000 basic shapes (I.e lines) the simulation computation speed drops significantly. In some cases, this can cause misinterpretations in algorithm performance and the developer needs to be mindful at the drawing speed of something that seems relatively simple.
There could be a few suggestions for solving this:
The text was updated successfully, but these errors were encountered: