Article

Improved Efficiency: Under The Hood of RocFall3’s Performance Driven Update

Published on: Mar 04, 2025 Updated on: Mar 04, 2025 Read: 4 minutes
Author:
  • Grace Huang, Geomechanics Product Manager

Overview of Performance Improvements in RocFall3


Version 1.015

Version 1.017 (with performance improvements)

Model 1 (10,000 rocks, 17,439 mesh triangles, 298 m average runout distance, 50s average travel time)

Saved file size with results

21,678,366 KB

469,649 KB

File Saving Time

20 m 20 s

12 s

File Loading Time

19 m 24 s

18 s

Viewport Interaction

Substantial Lag

No Lag

With extensive performance profiling, we have found that performance improvements can be achieved by reducing the volume of rock path data. Rock data volume is the result of not only the total number of rock paths but also the small steps needed to visualize and interpret the full extent of each path. In response, we have provided the following solutions to be released in RocFall3 version 1.017 for early March 2025:

  • Expose the interpolation time step used to interpret rock path results

We are offering greater user control in the resolution at which rock path results are interpolated. How does this feature reduce the overall amount of rock path data? Every rock path computation involves finding the critical points of contact with the slope and barriers. Rock path details in between the critical points are interpolated at an increment defined by the interpolation time step (see Figure 1). In RocFall3 versions 1.016 and older, a default interpolation time step of 0.016s was used. This time step is now exposed to users so they can use a larger time step to reduce the overall amount of rock path data. Note that a new default time step of 0.16s is provided, so you should automatically see an improvement in the file saving and loading speeds and a reduction in the saved file sizes using the latest version of RocFall3.

Figure 1. Rock path results interpolated using a time step of (a) 0.016s and (b) 0.16s.

As the interpolation time step is now editable, it’s important to understand the ramifications of changing this value. The interpolation time step can affect the interpretation of some results, as follows.

Results not affected:

  • Barrier results
  • Runout distances
  • Heatmaps of endpoints and impact points

Results affected:

  • Heatmaps of kinetic energies and heights (maximum, mean, and percentiles)
  • Path details (total number of entries per rock path)
  • Exported path results (total number of entries per rock path)
  • Resolution of rock path contours

Some results are affected by the interpolation time step because they depend on the amount of available rock path data. Heatmaps of kinetic energies and heights are statistically calculated using the rock path data directly above each grid in the heatmap. Using a larger time step reduces the available data above each grid and thus can affect the statistical outcomes. For this reason, we recommend a default interpolation time step of 0.16s – it helps to reduce rock path data, allows heatmap values to fall within 10% of past results (i.e., via a time step of 0.016s), and approximately maintains the heatmap colouring. Backward compatibility can always be achieved by setting the interpolation time step to 0.016s as was used in earlier versions. Path details, exported path results, and rock path contours are also affected by the interpolation time step because path entries are reported/visualized at the time step increment. This means coarser granularity for larger time steps.

Figure 2. Sample heatmaps of 95% Translational Kinetic Energy (top row)and 90% Height (bottom row).
  • Option to hide rock path visibility when interacting with the viewport

Any lag experienced when rotating, panning, or zooming the viewport when many rock path data points are visualized can be resolved by hiding the rock path visibility when interacting with the viewport. This is now a part of Display Options that is enabled by default to hide rock paths during viewport interactions.

  • Saving in binary format

You should now see a substantial reduction in the overall saved model file size due to the combined effect of saving in binary format and reducing the total amount of rock data by using a larger interpolation time step. For many data types, binary representations are much more space-efficient than text-based .xml types utilized by older versions of RocFall3.

Key Takeaways

Your feedback continues to drive our product innovation and improvements. Should you have any feedback, we are always open to hearing from you. For more tips, read this article on strategies for improving model performance in RocFall3.

Looking to take your Rockfall analysis to 3D?

Start a free trial of RocFall3 today!

Free Trial
Back to top