1 | \chapter{Visualisation} |
---|
2 | \label{OOChapVis} |
---|
3 | |
---|
4 | \section{Design Philosophy} |
---|
5 | |
---|
6 | The visualisation category consists of the classes required to display |
---|
7 | detector geometry, particle trajectories, tracking steps, and hits. It also |
---|
8 | provides visualisation drivers, which are interfaces to external graphics |
---|
9 | systems. |
---|
10 | |
---|
11 | A wide variety of user requirements went into the design of the visualisation |
---|
12 | category, for example: |
---|
13 | \begin{itemize} |
---|
14 | \item very quick response in surveying successive events, |
---|
15 | \item high-quality output for presentation and documentation, |
---|
16 | \item flexible camera control for debugging detector geometry and physics, |
---|
17 | \item selection of visualisable objects, |
---|
18 | \item interactive picking of graphical objects for attribute editing or |
---|
19 | feedback to the associated data, |
---|
20 | \item highlighting incorrect intersections of physical volumes, |
---|
21 | \item co-working with graphical user interfaces. |
---|
22 | \end{itemize} |
---|
23 | Because it is very difficult to respond to all of these requirements |
---|
24 | with only one built-in visualiser, an abstract interface was developed |
---|
25 | which supports several complementary graphics systems. Here the term |
---|
26 | {\bf graphics system} means either an application running as a |
---|
27 | process independent of {\sc Geant4} or a graphics library to be |
---|
28 | compiled with {\sc Geant4}. A concrete implementation of the |
---|
29 | interface is called a {\bf visualisation driver}, which can use a |
---|
30 | graphics library directly, communicate with an independent process via |
---|
31 | pipe or socket, or simply write an intermediate file for a separate |
---|
32 | viewer. |
---|
33 | |
---|
34 | \section{The Graphics Interfaces} |
---|
35 | |
---|
36 | \begin{itemize} |
---|
37 | |
---|
38 | \item {\bf G4VVisManager} All user code writes to the graphics systems |
---|
39 | through this pure abstract interface. It contains Draw methods for |
---|
40 | all the graphics primitives in the graphics\_reps category |
---|
41 | (G4Polyline, G4Circle, etc.), geometry objects (through their base |
---|
42 | classes, G4VSolid, G4PhysicalVolume and G4LogicalVolume) and hits and |
---|
43 | trajectories (through their base classes, G4VHit and G4VTrajectory). |
---|
44 | |
---|
45 | Since this is an abstract interface, all user code must check that |
---|
46 | there exists a concrete instantiation of it. A static method is |
---|
47 | provided, so a typical user code fragment is: |
---|
48 | \begin{verbatim} |
---|
49 | G4VVisManager* pVVisManager = G4VVisManager::GetConcreteInstance(); |
---|
50 | if(pVVisManager) { |
---|
51 | pVVisManager->Draw(G4Circle... |
---|
52 | ... |
---|
53 | \end{verbatim} |
---|
54 | Note that this allows the building an application without a concrete |
---|
55 | implementation, for example for a batch job, even if some code, like |
---|
56 | the above, is still included. Most of the novice examples can be |
---|
57 | built this way if G4VIS\_NONE is specified. |
---|
58 | |
---|
59 | The concrete implementation of this interface is hereafter |
---|
60 | referred to as the {\bf visualisation manager.} |
---|
61 | |
---|
62 | \item {\bf G4VGraphicsScene} The visualisation manager must also |
---|
63 | provide a concrete implementation of the subsidiary interface, |
---|
64 | G4VGraphicsScene. It is only for use by the kernel and the modeling |
---|
65 | category. It offers direct access to a ``scene handler'' through a |
---|
66 | reference provided by the visualisation manager. It is described in |
---|
67 | more detail in the section on extending the toolkit functionality. |
---|
68 | |
---|
69 | \end{itemize} |
---|
70 | |
---|
71 | The Geant4 distribution includes implementations of the above |
---|
72 | interfaces, namely {\bf G4VisManager} and {\bf G4VSceneHandler} |
---|
73 | respectively, and their associated classes. These define further |
---|
74 | abstract base classes for visualisation drivers. Together they form |
---|
75 | the {\bf Geant4 Visualisation System}. A variety of concrete |
---|
76 | visualisation drivers are also included in the distribution. Details |
---|
77 | of how to implement a visualisation driver are given in Chapter |
---|
78 | \ref{ExtendChapVis} in Part III. Of course, it is always possible for |
---|
79 | a user to implement his or her own concrete implementations of |
---|
80 | G4VVisManager and G4VGraphicsScene replacing the Geant4 Visualisation |
---|
81 | System altogether. |
---|
82 | |
---|
83 | \section{The Geant4 Visualisation System} |
---|
84 | |
---|
85 | The Geant4 Visualisation System consists of |
---|
86 | |
---|
87 | \begin{itemize} |
---|
88 | |
---|
89 | \item {\bf G4VisManager} An implementation of the G4VVisManager |
---|
90 | interface. It manages multiple graphics systems and defines three |
---|
91 | more concepts -- the {\bf scene} (G4Scene), the {\bf scene handler} |
---|
92 | (base class G4VSceneHandler, itself a sub-class of G4VGraphicsScene) |
---|
93 | and the {\bf viewer} (base class G4VViewer) -- see below. |
---|
94 | G4VisManager is a singleton and an abstract class, requiring the |
---|
95 | user to derive from it a concrete visualisation manager |
---|
96 | (G4VisExecutive is provided -- see below). Roles and structure of |
---|
97 | the visualisation manager are described in Chapter 8 of the User's |
---|
98 | Guide for Application Developers. |
---|
99 | |
---|
100 | \item {\bf G4VisExecutive} A concrete visualisation manager that |
---|
101 | implements the virtual functions RegisterGraphicsSystems and |
---|
102 | RegisterModelFactories. These functions must be in the users' |
---|
103 | domain, since the graphics systems and models that are instantiated |
---|
104 | by them are, in many cases, provided by the user (graphics |
---|
105 | libraries, etc.). It is therefore implemented as a .hh-.icc |
---|
106 | combination that is designed to be included in the users' code. Of |
---|
107 | course, the user may write his or her own. |
---|
108 | |
---|
109 | \item {\bf G4Scene} The scene is a list if models for physical |
---|
110 | volumes, axes, hits, trajectories, etc.\@ -- see Section |
---|
111 | \ref{secModeling}. They are distinguished according to their |
---|
112 | lifetime -- ``run-duration'' for physical volumes, etc., |
---|
113 | ``end-of-event'' for hits and trajectories, etc. The end-of-event |
---|
114 | models are only to be used when the Geant4 state indicates the end |
---|
115 | of event has been reached. The scene has an {\bf extent} |
---|
116 | (G4VisExtent), which is updated by the scene when a new model is |
---|
117 | added (each model itself has an extent), and a ``standard'' target |
---|
118 | point; these are used to define the standard view -- see |
---|
119 | below. In addition, the scene keeps flags which indicate whether |
---|
120 | end-of-event objects should be accumulated or refreshed for each |
---|
121 | event or run. |
---|
122 | |
---|
123 | \item {\bf G4VGraphicsSystem} This is an abstract base class for scene |
---|
124 | handler and viewer factories. It is used by the visualisation |
---|
125 | manager to create scene handlers and viewers on request. |
---|
126 | |
---|
127 | \item {\bf G4VSceneHandler} A sub-class of G4VGraphicsScene, itself an |
---|
128 | abstract base class for specific scene handlers, whose job is to |
---|
129 | convert the scene into graphics-system-specific code for the viewer. |
---|
130 | For example, the scene handler may create a graphical database, |
---|
131 | taking care to separate run-duration (persistent) and end-of-event |
---|
132 | (transient) information (this is described further in Section |
---|
133 | \ref{Transients}, Transients, in Part III). |
---|
134 | |
---|
135 | \item {\bf G4VViewer} An abstract base class for specific viewers. |
---|
136 | Its job is to create windows or files and identify where and how the |
---|
137 | final view should be rendered. It has {\bf view parameters} |
---|
138 | (G4ViewParameters) which specify viewpoint direction, type of |
---|
139 | rendering (wireframe or surface), etc. It is the view's |
---|
140 | responsibility, noting the scene's extent and target point, to |
---|
141 | choose a camera position and magnification that ensures that the |
---|
142 | scene is automatically and comfortably rendered in the viewing |
---|
143 | window. This is then the {\bf standard view}, and any further |
---|
144 | operations requested by the user -- zoom, pan, etc.\@ -- are |
---|
145 | relative to this standard view. The class G4ViewParameters has |
---|
146 | utility routines to assist this procedure; it is strongly advised |
---|
147 | that toolkit developers writing a viewer should study the |
---|
148 | G4ViewParameters class, whose header file contains much useful |
---|
149 | information (also preserved in the Software Reference Manual). |
---|
150 | |
---|
151 | The viewer is messaged by the vis manager when the user issues |
---|
152 | commands, such as {\tt /vis/viewer/refresh}. This invokes methods |
---|
153 | such as SetView, ClearView and DrawView. A detailed description of |
---|
154 | the call sequences is given in Sections |
---|
155 | \ref{Actions}-\ref{ProcessScene} in Part III. |
---|
156 | |
---|
157 | \end{itemize} |
---|
158 | |
---|
159 | Note there is no restriction on the number or type of scene handlers |
---|
160 | or viewers. There may be several scene handlers processing the same |
---|
161 | or different scenes, each with several viewers (for example, the same |
---|
162 | scene from differing viewpoints). |
---|
163 | |
---|
164 | By defining a set of three C++ classes inheriting from the virtual |
---|
165 | base classes -- G4VGraphicsSystem, G4VSceneHandler and G4VViewer -- an |
---|
166 | arbitrary graphics system can easily be plugged in to {\sc Geant4}. |
---|
167 | The plugged-in graphics system is then available for visualising |
---|
168 | detector simulations. Together, this set of three concrete classes is |
---|
169 | called a "visualisation driver". The DAWN-File driver, for example, |
---|
170 | is the interface to the Fukui Renderer DAWN, and is implemented by the |
---|
171 | following set of classes: |
---|
172 | \begin{enumerate} |
---|
173 | \item G4DAWNFILE : public G4VGraphicsSystem\newline |
---|
174 | for creation of the scene handlers and viewers |
---|
175 | \item G4DAWNFILESceneHandler : public G4VSceneHandler\newline |
---|
176 | for modeling 3D scenes |
---|
177 | \item G4DAWNFILEView : public G4VView\newline |
---|
178 | for rendering 3D scenes |
---|
179 | \end{enumerate} |
---|
180 | Several visualisation drivers are distributed with Geant4. They are |
---|
181 | complementary to each other in many aspects. For details, see Chapter 8 of |
---|
182 | the User's Guide for Application Developers. |
---|
183 | |
---|
184 | |
---|
185 | \section{Modeling sub-category} |
---|
186 | \label{secModeling} |
---|
187 | |
---|
188 | \begin{itemize} |
---|
189 | \item {\bf G4VModel} - a base class for visualisation models. A model is a |
---|
190 | graphics-system-independent description of a Geant4 component. |
---|
191 | |
---|
192 | The sub-category visualisation/modeling defines how to model a 3D |
---|
193 | scene for visualisation. The term "3D scene" indicates a set of |
---|
194 | visualisable component objects put in a 3D world. A concrete class |
---|
195 | inheriting from the abstract base class G4VModel defines a "model", |
---|
196 | which describes how to visualise the corresponding component object |
---|
197 | belonging to a 3D scene. G4ModelingParameters defines various |
---|
198 | associated parameters. |
---|
199 | |
---|
200 | For example, G4PhysicalVolumeModel knows how to visualise |
---|
201 | a physical volume. It describes a physical volume |
---|
202 | and its daughters to any desired depth. G4HitsModel knows |
---|
203 | how to visualise hits. G4TrajectoriesModel |
---|
204 | knows how to visualise trajectories. |
---|
205 | |
---|
206 | The main task of a model is to describe itself to a 3D scene by |
---|
207 | giving a concrete implementation of the following virtual |
---|
208 | method of G4VModel: |
---|
209 | \begin{verbatim} |
---|
210 | virtual void DescribeYourselfTo (G4VGraphicsScene&) = 0; |
---|
211 | \end{verbatim} |
---|
212 | |
---|
213 | The argument class G4VGraphicsScene is a minimal abstract |
---|
214 | interface of a 3D scene for the {\sc Geant4} kernel defined in the |
---|
215 | graphics\_reps category. Since G4VSceneHandler and its concrete |
---|
216 | descendants inherit from G4VGraphicsScene, the |
---|
217 | method DescribeYourselfTo() can pass information of a 3D scene |
---|
218 | to a visualisation driver. |
---|
219 | |
---|
220 | It is easy for a toolkit developer of {\sc Geant4} to add a new kind |
---|
221 | of visualisable component object. It is done by implementing a |
---|
222 | new class inheriting from G4VModel. |
---|
223 | |
---|
224 | \item {\bf G4VTrajectoryModel} - an abstract base class for trajectory drawing models. |
---|
225 | |
---|
226 | A trajectory model governs how an individual trajectory is drawn. Concrete models inheriting from G4VTrajectoryModel must implement two pure virtual functions: |
---|
227 | |
---|
228 | \begin{verbatim} |
---|
229 | virtual void Draw(const G4VTrajectory&, G4int i_mode = 0) const = 0; |
---|
230 | virtual void Print(std::ostream& ostr) const = 0; |
---|
231 | \end{verbatim} |
---|
232 | |
---|
233 | See for example G4TrajectoryDrawByParticleID. |
---|
234 | |
---|
235 | \item {\bf G4VModelFactory} - an abstract base class for factories creating models and associated messengers. |
---|
236 | |
---|
237 | It is not necessary to generate messengers for a trajectory model that will be constructed and configured directly in compiled code. If the user requires model creation and configuration features through interactive commands, however, there must be a mechanism to generate both models and their associated messengers. This is the role of G4VModelFactory. Concrete factories inheriting from G4VModelFactory are responsible for creating a concrete model and concrete messengers. To help ensure a type safe messenger to model interaction on the command line, the messengers should inherit from G4VModelCommand. |
---|
238 | |
---|
239 | Concrete factories must implement one pure virtual function: |
---|
240 | |
---|
241 | \begin{verbatim} |
---|
242 | virtual ModelAndMessengers |
---|
243 | Create(const G4String& placement, const G4String& modelName) = 0; |
---|
244 | \end{verbatim} |
---|
245 | |
---|
246 | where placement indicates which directory space the commands should occupy. |
---|
247 | See for example G4TrajectoryDrawByParticleIDFactory. |
---|
248 | |
---|
249 | \end{itemize} |
---|
250 | \section{View parameters} |
---|
251 | View parameters such as camera parameters, drawing styles |
---|
252 | (wireframe/surface etc) are held by G4ViewParameters. Each |
---|
253 | viewer holds a view parameters object which can be changed |
---|
254 | interactively and a default object (for use in the |
---|
255 | \verb+/vis/viewer/reset+ command). |
---|
256 | |
---|
257 | If a toolkit developer of {\sc Geant4} wants to add entries of view |
---|
258 | parameters, he should add fields and methods to G4ViewParameters. |
---|
259 | |
---|
260 | \section{Visualisation Attributes} |
---|
261 | |
---|
262 | All drawable objects (should) have a method: |
---|
263 | \begin{verbatim} |
---|
264 | const G4VisAttributes* GetVisAttributes() const; |
---|
265 | \end{verbatim} |
---|
266 | |
---|
267 | A drawable object might be: |
---|
268 | \begin{itemize} |
---|
269 | \item a "visible" (i.e., inheriting G4Visible), such as a polyhedron, |
---|
270 | polyline, circle, etc. (note that text is a slightly special case |
---|
271 | - see below) or |
---|
272 | \item a solid whose vis attributes are held in its logical volume. |
---|
273 | \end{itemize} |
---|
274 | |
---|
275 | \subsection{Finding the applicable vis attributes} |
---|
276 | |
---|
277 | This is an issue for all scene handlers. The scene handler is where |
---|
278 | the colour, style, auxiliary edge visibility, marker size, etc., of |
---|
279 | individual drawable objects are needed. |
---|
280 | |
---|
281 | \subsubsection{Visibles} |
---|
282 | |
---|
283 | If the vis attributes pointer is zero, drivers should pick up the |
---|
284 | default vis attributes from the viewer: |
---|
285 | \begin{verbatim} |
---|
286 | const G4VisAttributes* pVisAtts = visible.GetVisAttributes(); |
---|
287 | if (!pVisAtts) |
---|
288 | pVisAtts = fpViewer->GetViewParameters().GetDefaultVisAttributes(); |
---|
289 | \end{verbatim} |
---|
290 | where visible denotes any visible object (polyhedron, circle, etc.). |
---|
291 | |
---|
292 | There is a utility function G4VViewer::GetApplicableVisAttributes |
---|
293 | which does this, so an alternative is: |
---|
294 | \begin{verbatim} |
---|
295 | const G4VisAttributes* pVisAtts = |
---|
296 | fpViewer->GetApplicableVisAttributes(visible.GetVisAttributes()); |
---|
297 | \end{verbatim} |
---|
298 | |
---|
299 | Confusingly, there is a utility function G4VSceneHandler::GetColour |
---|
300 | which also does this, so if it's only colour you need, the following |
---|
301 | suffices: |
---|
302 | \begin{verbatim} |
---|
303 | const G4Colour& colour GetColour(visible); |
---|
304 | \end{verbatim} |
---|
305 | |
---|
306 | but equally well: |
---|
307 | \begin{verbatim} |
---|
308 | const G4VisAttributes* pVisAtts = |
---|
309 | fpViewer->GetApplicableVisAttributes(visible.GetVisAttributes()); |
---|
310 | const G4Colour& colour pVisAtts->GetColour(); |
---|
311 | \end{verbatim} |
---|
312 | |
---|
313 | or even: |
---|
314 | \begin{verbatim} |
---|
315 | const G4VisAttributes* pVisAtts = visible.GetVisAttributes(); |
---|
316 | if (!pVisAtts) |
---|
317 | pVisAtts = fpViewer->GetViewParameters().GetDefaultVisAttributes(); |
---|
318 | const G4Colour& colour pVisAtts->GetColour(); |
---|
319 | \end{verbatim} |
---|
320 | |
---|
321 | \subsubsection{Text} |
---|
322 | |
---|
323 | Text is a special case because it has its own default vis attributes: |
---|
324 | \begin{verbatim} |
---|
325 | const G4VisAttributes* pVisAtts = text.GetVisAttributes(); |
---|
326 | if (!pVisAtts) |
---|
327 | pVisAtts = fpViewer->GetViewParameters().GetDefaultTextVisAttributes(); |
---|
328 | const G4Colour& colour pVisAtts->GetColour(); |
---|
329 | \end{verbatim} |
---|
330 | |
---|
331 | and there is a utility function G4VSceneHandler::GetTextColour: |
---|
332 | \begin{verbatim} |
---|
333 | const G4Colour& colour GetTextColour(text); |
---|
334 | \end{verbatim} |
---|
335 | |
---|
336 | \subsubsection{Solids} |
---|
337 | |
---|
338 | For specific solids, the G4PhysicalVolumeModel that provides the |
---|
339 | solids also provides, via PreAddSolid, a pointer to its vis |
---|
340 | attributes. If the vis attribites pointer in the logical volume is |
---|
341 | zero, it provides a pointer to the default vis attributes in the |
---|
342 | model, which in turn is (currently) provided by the viewer's vis |
---|
343 | attributes (see G4VSceneHandler::CreateModelingParameters). So the |
---|
344 | vis attributes pointer is guaranteed to be pertinent. |
---|
345 | |
---|
346 | If the concrete driver does not implement AddSolid for any particular |
---|
347 | solid, the base class converts it to primitives (usually a |
---|
348 | G4Polyhedron) and again, the vis attributes pointer is guaranteed. |
---|
349 | |
---|
350 | \subsubsection{Drawing style} |
---|
351 | |
---|
352 | The drawing style is normally determined by the view parameters but |
---|
353 | for individual drawable objects it may be overridden by the forced |
---|
354 | drawing style flags in the vis attributes. A utility function |
---|
355 | G4ViewParameters::DrawingStyle G4VSceneHandler::GetDrawingStyle is |
---|
356 | provided: |
---|
357 | \begin{verbatim} |
---|
358 | G4ViewParameters::DrawingStyle drawing_style = GetDrawingStyle(pVisAtts); |
---|
359 | \end{verbatim} |
---|
360 | |
---|
361 | \subsubsection{Auxiliary edges} |
---|
362 | |
---|
363 | Similarly, the visibility of auxiliary/soft edges is normally |
---|
364 | determined by the view parameters but may be overridden by the forced |
---|
365 | auxiliary edge visible flag in the vis attributes. Again, a utility |
---|
366 | function G4VSceneHandler::GetAuxEdgeVisible is provided: |
---|
367 | \begin{verbatim} |
---|
368 | G4bool isAuxEdgeVisible = GetAuxEdgeVisible (pVisAtts); |
---|
369 | \end{verbatim} |
---|
370 | |
---|
371 | \subsubsection{LineSegmentsPerCircle} |
---|
372 | |
---|
373 | Also, the precision of rendering curved edges in the polyhedral |
---|
374 | representation of volumes is normally determined by the view |
---|
375 | parameters but may be overridden by a forced attribute. A utility |
---|
376 | function that respects this, G4VSceneHandler::GetNoOfSides, is |
---|
377 | provided. For example: |
---|
378 | \begin{verbatim} |
---|
379 | G4Polyhedron::SetNumberOfRotationSteps (GetNoOfSides (pVisAttribs)); |
---|
380 | \end{verbatim} |
---|
381 | |
---|
382 | |
---|
383 | \subsubsection{Marker size} |
---|
384 | |
---|
385 | These have nothing to do with vis attributes; they are an extra |
---|
386 | property of markers, i.e., objects that inherit G4VMarker (circles, |
---|
387 | squares, text, etc.). However, the algorithm for the actual size is |
---|
388 | quite complicated and a utility function |
---|
389 | G4VSceneHandler::GetMarkerSize is provided: |
---|
390 | \begin{verbatim} |
---|
391 | MarkerSizeType sizeType; |
---|
392 | G4double size = GetMarkerSize (text, sizeType); |
---|
393 | \end{verbatim} |
---|
394 | |
---|
395 | sizeType is world or screen, signifying that the size is in world |
---|
396 | coordinates or screen coordinates respectively. |
---|
397 | |
---|
398 | |
---|
399 | \section{Status of this chapter} |
---|
400 | |
---|
401 | 27.06.05 partially re-organized and section on design philosophy added (from |
---|
402 | Geant4 general paper) by D.H. Wright \\ |
---|
403 | 13.10.05 Section on vis attributes added by John Allison. \\ |
---|
404 | 06.01.06 Re-write of ``Design Philosphy'' and introduction of ``The Graphics |
---|
405 | Interfaces'' and ``The Geant4 Visualisation System'' by John Allison. |
---|