Geant4 Workshop, CERN - 1 October 2002 Joseph Perl

1. Graphics Requirements for G4 Trajectories(draft: hastily prepared for trajectories parallel session) Geant4 Workshop, CERN - 1 October 2002 Joseph Perl

2. Problem with Existing Trajectories • Graphics drivers have access to detailed information about geometry since the sceneHandler has access to physical volume, etc. and can present this information to the end user through labels on graphics objects or through picking. • Graphics drivers have no access to detailed information about trajectories (or sensitive detector hits). The sceneHandler only sees this data as graphics primitives (no pointer back to the trajectory). • Graphics drivers have no access to auxiliary points. These points are not persisted long enough for graphics to use them, hence we can’t draw smooth trajectories. Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

3. Auxiliary Points • On this topic, I only know what I’ve learned from John Allison. See his mail of 5 Sept 2002: Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

4. Effect of lack on information: Example T01 Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

5. Picking on Detector Volumes Gives Detailed Attributes Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

6. Picking on Trajectory Gives No Details Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

7. Picking on Trajectory if Graphics Drivershad Better Access to Trajectory Information Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

8. Proposal for Better Graphics from Trajectories • Give sceneHandler a DrawTrajectories method with pointer back to Trajectory • Persist Auxiliary Points long enough for sceneHandler to use them to draw smooth trajectories • Allow attachment of arbitrary attributes to Trajectories and Trajectory Points (and sensitive detector hits) • A successful scheme for such arbitrary attributes has been used in HepRep for several years • The proposal is NOT for G4 to depend on HepRep • The proposal is only for G4 to incorporate two small classes that hold “HepRep-style” attributes. • The HepRep attribute classes are just two simple classes used in HepRep, they are not the entire HepRep design. Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

9. The HepRep Attribute Classes Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

10. The HepRep Attribute Classes HepRepAttDef HepRepAttValue AttDefName: StringValue: AnyShowLabel: Int Name: StringDesc: StringCategory: StringExtra: String In C++, the “any” is handled as a String that is interpreted according to an extra member of the AttDef called valueType. G4AttDef G4AttValue AttDefName: StringValue: StringShowLabel: Int Name: StringDesc: StringCategory: StringExtra: StringValueType: String Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

11. G4AttDef.h now in graphics_reps Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

12. G4AttValue.h now in graphics_reps Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

13. HepRep is Well Documented Elsewhere • For details on the exact use of HepRep Attributes, see the HepRep Home Page at: http://heprep.freehep.org • In particular, see the detailed HepRep2 writeup at:http://heprep.freehep.org/heprep2/Complete.ppthttp://heprep.freehep.org/heprep2/Complete.pdf Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

14. Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

15. Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

16. The Way Forward • Give sceneHandler a DrawTrajectories method with pointer back to Trajectory • Persist Auxiliary Points long enough for sceneHandler to use them to draw smooth trajectories • Allow user to define arbitrary attributes in G4AttDef objects contained in a G4AttDefStore (map<string,G4AttDef> wrapped in a singelton) instantiated by the runManager. • Allow attachment of G4AttValue attributes to Trajectories and Trajectory Points (and sensitive detector hits) • G4AttValues do not contain a pointer to the relevant G4AttDef. The G4AttDef and G4AttValue association is done through a common string AttDefName. This simplifies many aspects of attribute use (AttValue user doesn’t need any way to get pointer, serialization is simpler, etc.). Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

17. Extra Slidemore implementation details We will have a singleton G4AttDefStore instantiated by the run manager. Each trajectory (or trajectory point, hit, etc.) can call a method on this G4AttDefStore to tell it to add an attDef, where first argument is name of type of objects that will have this attribute (trajectory, trajectory point, hit, etc.), and other arguments define the attDef.The G4AttDefStore will just ignore this def if it has already been created for some other trajectory (or trajectory point, etc.). The trajectory (or trajectory point, hit, etc.) will have a set of G4AttValues.The AttValues are linked to the AttDefs by att def name, rather than by a pointer, thus the trajectory itself doesn't have to have any way to get a pointer to the particular attDef.We already rely on this weak form of association (association by name rather than pointer) in our xml serialization of the HepRep. At the end of the run, the run manager will destory the G4AttDefStore. Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services