I have code that we are migrating from G4 v10 to G4 v11, this includes a utility adapted from GAMOS’s GmGeometryTools, which can take the name of a PV as input and return a Touchable for it (so it can be passed to other places, with the transforms, etc.). The utility creates an internal container (for us, it’s CDMSTouchable, for GAMOS it’s GmTouchable), which used to inherit from G4VTouchable.
That inheritance likely won’t work properly any more, because the “G4VTouchable” type is now just an alias for the concrete G4TouchableHistory. Is there a public interface available to construct a G4TouchableHistory? In G4Navigator, you have to give it a position in global coordinates (which isn’t available in this use case; it’s before any tracking).
I’ve copied you into Issue #277. Since the year dot, G4VTouchable has been a virtual base class. What else does the ‘V’ stand for? G4PhysicalVolumeModel in vis/modeling has exploited it for years. If they take virtual away, I don’t see an easy - nay, any possible - way out for vis. It’s a crisis. Some examples crash.
I’ve finally realized, after working through how I “might” implement something myself, that my original question, “create a touchable from a PV,” is not well posed. It’s not possible to create a unique Touchable just from a leaf-node PV, or from any PV below a direct placement in the world. The PV has a pointer to its mother LV, but that LV might have gotten placed itself multiple times.
Without a specific global coordinate, there’s no way to work through the series of placements uniquely. And with a global coordinate, G4Navigator::LocateGlobalPointAndUpdateTouchable() provides the necessary interface.
That sounds like a good solution for you, Mike. That’s great. The vis system does its own geometry hierarchy navigation and it has no problem finding touchables. This allows us to change the representation (colour, wireframe,…) of individual touchables. (See /vis/touchable/findPath, /vis/set/touchable and /vis/touchable/set/.... The first gives a list of all touchables with a given PV.)
The problem comes only for parameterised volumes, when the material and colour are set in ComputeMaterial(G4VPhysicalVolume* physVol, const G4int iz, const G4VTouchable* parentTouch). For that I need to provide a G4VTouchable that provides access to the vis navigation, so I need the base class with virtual functions.