Output stats

[mariuszhermansdorfer]

@philipbelesky, @BarusXXX do you see any value at all in outputting stats about how fast certain parts of the code were executed? It was good for debugging purposes, but IMHO could be safely removed now.

With the new CutFill analysis mode, we started presenting more meaningful information through this channel. Any other suggestions for what we could spit out here?

[philipbelesky]

Agree that it shouldn't be user-facing. It's probably worth keeping in as a development aid though. In Groundhog/Caribou I just check if the compiler built for release or debug and hide the messages for the former. E.g.

#if DEBUG
            logger.Say();
#endif

No great ideas for other stats at the moment. The only thing that comes to mind might be the highest point and lowest point? But even that is probably not worth the lookup overhead and could be done downstream easily enough. I imagine the waterflow analysis could have some useful output stats.

[mariuszhermansdorfer]

Like the idea of keeping it for Debug builds. Let's add it to SandWorm as well!

[BarusXXX]

@philipbelesky what should we look at outputting from waterflow in terms of stats?

Currently we are depositing X units of water each frame at a modifiable density.

Given that the rate of flow is something we can tweak to make the animation trade off accuracy for faster animation. What would be a useful measurable output?

The ability to identify flow paths and back on request the geometry for them would be a nice addition.

[philipbelesky]

At a first guess, the end-of-flow path volume and per-triangle saturation levels, per this component would be useful for data visualisation. But I'm not sure those make sense if the flow analysis isn't based on a gradient descent method.

It might be worth experimenting with a per-cell output of similar data. But the Sandworm mesh is so dense that any numeric output is probably going to take a while to output and might be too complex to process into color or to apply to the mesh in native GH components. Maybe we can discuss/test in #14 as that progresses?

[BarusXXX]

@mariuszhermansdorfer Could we output the analysis type with the stats, or expose it somehow so one can dynamically get the current selected analysis and do something down the line with that?

[mariuszhermansdorfer]

Could we output the analysis type with the stats, or expose it somehow so one can dynamically get the current selected analysis and do something down the line with that?

We could for sure just spit out a string in the stats, but what use case would this serve? Should it be visible only to official SandWorm components, or any generic GH component as well?

[mariuszhermansdorfer]

Implemented @philipbelesky's suggestion to differentiate stats output between debug/release versions. Pushed to the latest SandWorm2-0 branch:

Elevation analysis:

CutFill analysis: