Terms
Description
The TriangleScene.compute_paths method is getting more and more complex as we are adding features to it, making it non-trivial to understand how to properly use it, but also difficult to extend it.
I suggest that we split it into two separate method: trace_paths for exact (but with optional approximate visibility) path tracing and launch_paths for ray launching-like methods. Moreover, maintaining one Paths class (and its SBRPaths subclass) all possible cases makes little sense since different techniques have different outputs, and SBRPaths cannot represent all ray launching-like paths. One good example is if we implement an interception-plane technique, then we actually don't use the receivers' location. I believe it would be more appropriate to also create different classes for the different methods. Methods that will consume those classes will need to handle to different cases themselves.
Finally, I think that it would be great to use a config class to configure the various path solver. E.g., trace_paths(solver=ExhaustivePathSolver()), and also allow to pass string literal to refer to the default configuration of a given solver.
Screenshots
No response
Additional information
No response
Terms
Description
The
TriangleScene.compute_pathsmethod is getting more and more complex as we are adding features to it, making it non-trivial to understand how to properly use it, but also difficult to extend it.I suggest that we split it into two separate method:
trace_pathsfor exact (but with optional approximate visibility) path tracing andlaunch_pathsfor ray launching-like methods. Moreover, maintaining onePathsclass (and itsSBRPathssubclass) all possible cases makes little sense since different techniques have different outputs, andSBRPathscannot represent all ray launching-like paths. One good example is if we implement an interception-plane technique, then we actually don't use the receivers' location. I believe it would be more appropriate to also create different classes for the different methods. Methods that will consume those classes will need to handle to different cases themselves.Finally, I think that it would be great to use a config class to configure the various path solver. E.g.,
trace_paths(solver=ExhaustivePathSolver()), and also allow to pass string literal to refer to the default configuration of a given solver.Screenshots
No response
Additional information
No response