1. Geant4 Workshop, CERN - 1 October 2002 Joseph Perl
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.
1 October 2002
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:
1 October 2002
Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

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

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

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

7. Picking on Trajectory if Graphics Drivers had Better Access to Trajectory Information
1 October 2002
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.
1 October 2002
Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

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

10. The HepRep Attribute Classes
HepRep AttDef
HepRep AttValue
Name: String Desc: String Category: String Extra: String
AttDefName: String Value: Any ShowLabel: Int
In C++, the “any” is handled as a String that is interpreted according to an extra member of the AttDef called valueType.
G4 AttDef
G4 AttValue
Name: String Desc: String Category: String Extra: String ValueType: String
AttDefName: String Value: String ShowLabel: Int
1 October 2002
Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

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

12. G4AttValue.h now in graphics_reps
1 October 2002
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:
In particular, see the detailed HepRep2 writeup at:
1 October 2002
Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

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

15. 1 October 2002
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.).
1 October 2002
Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services

17. Extra Slide more 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.
1 October 2002
Graphics Requirements for G4 Trajectories Joseph Perl, SLAC Computing Services