ROOT  6.06/09
Reference Guide
TVirtualViewer3D.cxx
Go to the documentation of this file.
1 // @(#)root/base:$Id$
2 // Author: Olivier Couet 05/10/2004
3 
4 /*************************************************************************
5  * Copyright (C) 1995-2004, Rene Brun and Fons Rademakers. *
6  * All rights reserved. *
7  * *
8  * For the licensing terms see $ROOTSYS/LICENSE. *
9  * For the list of contributors see $ROOTSYS/README/CREDITS. *
10  *************************************************************************/
11 
12 /** \class TVirtualViewer3D
13 Abstract 3D shapes viewer.
14 
15 The concrete implementations are:
16 
17  - TViewerX3D : X3d viewer
18  - TGLViewer : OpenGL viewer
19 
20 ## 3D Viewer Infrastructure Overview
21 
22 The 3D Viewer infrastructure consists of:
23 
24  - TVirtualViewer3D interface: An abstract handle to the viewer, allowing
25  client to test preferences, add objects, control the viewer via scripting
26  (to be added) etc.
27  -TBuffer3D class hierarchy: Used to describe 3D objects
28  ("shapes")
29  - filled /added by negotiation with viewer via TVirtualViewer3D.
30 
31 
32 Together these allow clients to publish objects to any one of the 3D viewers
33  (currently OpenGL/x3d,TPad), free of viewer specific drawing code. They allow
34  our simple x3d viewer, and considerably more sophisticated OpenGL one to both
35  work with both geometry libraries (g3d and geom) efficiently.
36 
37 Publishing to a viewer consists of the following steps:
38 
39  1. Create / obtain viewer handle
40  2. Begin scene on viewer
41  3. Fill mandatory parts of TBuffer3D describing object
42  4. Add to viewer
43  5. Fill optional parts of TBuffer3D if requested by viewer, and add again
44  ... repeat 3/4/5 as required
45  6. End scene on viewer
46 
47 ## Creating / Obtaining Viewer
48 
49 Create/obtain the viewer handle via local/global pad - the viewer is always
50 bound to a TPad object at present [This may be removed as a restriction in
51 the future] . You should perform the publishing to the viewer described below
52 in the Paint() method of the object you attach to the pad (via Draw())
53 ~~~ {.cpp}
54 TVirtualViewer3D * v = gPad->GetViewer3D("xxxx");
55 ~~~
56 
57 " xxxx" is viewer type: OpenGL "ogl", X3D "x3d" or
58 Pad "pad" (default). The viewer is created via the plugin manager,
59 attached to pad, and the interface returned.
60 
61 ## Begin / End Scene
62 
63 Objects must be added to viewer between BeginScene/EndScene calls e.g.
64 ~~~ {.cpp}
65 v->BeginScene();
66 .....
67 v->AddObject(....);
68 v->AddObject(....);
69 .....
70 v->EndScene();
71 ~~~
72 
73 The BeginScene call will cause the viewer to suspend redraws etc, and after
74 the EndScene the viewer will reset the camera to frame the new scene and redraw.
75 [x3d viewer does not support changing of scenes - objects added after the
76 first Open/CloseScene pair will be ignored.]
77 
78 
79 ## Filling TBuffer3D and Adding to Viewer
80 
81 The viewers behind the TVirtualViewer3D interface differ greatly in their
82 capabilities e.g.
83 
84  - Some know how to draw certain shapes natively (e.g. spheres/tubes in
85  OpenGL) - others always require a raw tessellation description of points/lines/segments.
86  - Some need the 3D object positions in the global frame, others can cope with
87  local frames + a translation matrix - which can give considerable performance
88  benefits.
89 
90 To cope with these situations the object buffer is filled out in negotiation
91 with the viewer. TBuffer3D classes are conceptually divided into enumerated
92 sections Core, BoundingBox, Raw etc (see TBuffer3D.h for more details).
93 \image html base_tbuffer3d.png
94 
95 The SectionsValid() / SetSectionsValid / ClearSectionsValid() methods of TBuffer3D
96 are used to test/set/clear these section valid flags.
97 
98 The sections found in TBuffer3D (Core/BoundingBox/Raw Sizes/Raw)
99 are sufficient to describe any tessellated shape in a generic fashion.
100 An additional ShapeSpecific section
101 in derived shape specific classes allows a more abstract shape description
102 ("a sphere of inner radius x, outer radius y"). This enables a viewer
103 which knows how to draw (tessellate) the shape itself to do so, which can bring
104 considerable performance and quality benefits, while providing a generic fallback
105 suitable for all viewers.
106 
107 The rules for client negotiation with the viewer are:
108 
109  - If suitable specialized TBuffer3D class exists, use it, otherwise use TBuffer3D.
110  - Complete the mandatory Core section.
111  - Complete the ShapeSpecific section if applicable.
112  - Complete the BoundingBox if you can.
113  - Pass this buffer to the viewer using one of the AddObject() methods - see below.
114 
115 If the viewer requires more sections to be completed (Raw/RawSizes) AddObject()
116 will return flags indicating which ones, otherwise it returns kNone. You must
117 fill the buffer and mark these sections valid, and pass the buffer again. A
118 typical code snippet would be:
119 ~~~ {.cpp}
120 TBuffer3DSphere sphereBuffer;
121 // Fill out kCore...
122 // Fill out kBoundingBox...
123 // Fill out kShapeSpecific for TBuffer3DSphere
124 // Try first add to viewer
125 Int_t reqSections = viewer->AddObject(buffer);
126 if (reqSections != TBuffer3D::kNone) {
127  if (reqSections & TBuffer3D::kRawSizes) {
128  // Fill out kRawSizes...
129  }
130  if (reqSections & TBuffer3D::kRaw) {
131  // Fill out kRaw...
132  }
133  // Add second time to viewer - ignore return cannot do more
134  viewer->AddObject(buffer);
135  }
136 }
137 ~~~
138 
139 ShapeSpecific: If the viewer can directly display the buffer without
140 filling of the kRaw/kRawSizes section it will not need to request client side
141 tessellation. Currently we provide the following various shape specific classes,
142 which the OpenGL viewer can take advantage of (see TBuffer3D.h and TBuffer3DTypes.h)
143 
144  - TBuffer3DSphere - solid, hollow and cut spheres*
145  - TBuffer3DTubeSeg - angle tube segment
146  - TBuffer3DCutTube - angle tube segment with plane cut ends.
147 
148 *OpenGL only supports solid spheres at present - cut/hollow ones will be
149 requested tessellated.
150 
151 Anyone is free to add new TBuffer3D classes, but it should be clear that the
152 viewers require updating to be able to take advantage of them. The number of
153 native shapes in OpenGL will be expanded over time.
154 
155 BoundingBox: You are not obliged to complete this, as any viewer
156 requiring one internally (OpenGL) will build one for you if you do not provide.
157 However to do this the viewer will force you to provide the raw tessellation, and the
158 resulting box will be axis aligned with the overall scene, which is non-ideal
159 for rotated shapes.
160 
161 As we need to support orientated (rotated) bounding boxes, TBuffer3D requires
162  the 6 vertices of the box. We also provide a convenience function, SetAABoundingBox(),
163  for simpler case of setting an axis aligned bounding box.
164 
165 ## Master/Local Reference Frames
166 
167 The Core section of TBuffer3D contains two members relating to reference frames:
168 fLocalFrame & fLocalMaster. fLocalFrame indicates if any positions in the buffer
169 (bounding box and tessellation vertexes) are in local or master (world frame).
170 fLocalMaster is a standard 4x4 translation matrix (OpenGL column major ordering)
171 for placing the object into the 3D master frame.
172 
173 If fLocalFrame is kFALSE, fLocalMaster should contain an identity matrix. This
174 is set by default, and can be reset using SetLocalMasterIdentity() function.
175 
176 ### Logical & Physical Objects
177 
178 There are two cases of object addition:
179 
180  - Add this object as a single independent entity in the world reference frame.
181  - Add a physical placement (copy) of this logical object (described in local reference frame).
182 
183 The second case is very typical in geometry packages, GEANT4, where we have
184 very large number repeated placements of relatively few logical (unique) shapes.
185 Some viewers (OpenGL only at present) are able to take advantage of this by
186 identifying unique logical shapes from the fID logical ID member of
187 TBuffer3D. If repeated addition of the same fID is found, the shape
188 is cached already - and the costly tessellation does not need to be sent again.
189 The viewer can also perform internal GL specific caching with considerable performance gains
190 in these cases.
191 
192 For this to work correctly the logical object in must be described in TBuffer3D
193 in the local reference frame, complete with the local/master translation. The
194 viewer indicates this through the interface method
195 ~~~ {.cpp}
196 PreferLocalFrame()
197 ~~~
198 
199 If this returns kTRUE you can make repeated calls to AddObject(), with TBuffer3D
200 containing the same fID, and different fLocalMaster placements.
201 
202 For viewers supporting logical/physical objects, the TBuffer3D content refers
203 to the properties of logical object, with the fLocalMaster transform and the
204 fColor and fTransparency attributes, which can be varied for each physical
205 object.
206 
207 As a minimum requirement all clients must be capable of filling the raw tessellation
208 of the object buffer, in the master reference frame. Conversely viewers must
209 always be capable of displaying the object described by this buffer.
210 
211 ## Scene Rebuilds
212 
213 It should be understood that AddObject is not an explicit command to the viewer
214  - it may for various reasons decide to ignore it:
215 
216  - It already has the object internally cached .
217  - The object falls outside some 'interest' limits of the viewer camera.
218  - The object is too small to be worth drawing.
219 
220 In all these cases AddObject() returns kNone, as it does for successful addition,
221 simply indicating it does not require you to provide further information about
222 this object. You should not try to make any assumptions about what the viewer did with it.
223 
224 This enables the viewer to be connected to a client which sends potentially
225 millions of objects, and only accept those that are of interest at a certain
226 time, caching the relatively small number of CPU/memory costly logical shapes,
227 and retaining/discarding the physical placements as required. The viewer may
228 decide to force the client to rebuild (republish) the scene (via a TPad
229 repaint at present), and thus collect these objects if the
230 internal viewer state changes. It does this presently by forcing a repaint
231 on the attached TPad object - hence the reason for putting all publishing to
232 the viewer in the attached pad objects Paint() method. We will likely remove
233 this requirement in the future, indicating the rebuild request via a normal
234 ROOT signal, which the client can detect.
235 
236 ## Physical IDs
237 
238 TVirtualViewer3D provides for two methods of object addition:virtual Int_t AddObject(const
239 TBuffer3D & buffer, Bool_t * addChildren = 0)
240 
241 ~~~ {.cpp}
242 virtual Int_t AddObject(UInt_t physicalID, const TBuffer3D & buffer, Bool_t * addChildren = 0)
243 ~~~
244 
245 If you use the first (simple) case a viewer using logical/physical pairs
246 will generate IDs for each physical object internally. In the second you
247 can specify a unique identifier from the client, which allows the viewer to be more
248 efficient. It can now cache both logical and physical objects, and only discard
249 physical objects no longer of interest as part of scene rebuilds.
250 
251 ## Child Objects
252 
253 In many geometries there is a rigid containment hierarchy, and so if the viewer
254 is not interested in a certain object due to limits/size then it will also
255 not be interest in any of the contained branch of descendents. Both AddObject()
256 methods have an addChildren parameter. The viewer will complete this (if passed)
257 indicating if children (contained within the one just sent) are worth adding.
258 
259 ## Recycling TBuffer3D
260 
261 Once add AddObject() has been called, the contents are copied to the viewer
262 internally. You are free to destroy this object, or recycle it for the next
263 object if suitable.
264 */
265 
266 #include "TVirtualViewer3D.h"
267 #include "TVirtualPad.h"
268 #include "TPluginManager.h"
269 #include "TError.h"
270 #include "TClass.h"
271 
273 
274 ////////////////////////////////////////////////////////////////////////////////
275 /// Create a Viewer 3D of specified type.
276 
278 {
279  TVirtualViewer3D *viewer = 0;
280  TPluginHandler *h;
281  if ((h = gPluginMgr->FindHandler("TVirtualViewer3D", type))) {
282  if (h->LoadPlugin() == -1)
283  return 0;
284 
285  if (!pad) {
286  viewer = (TVirtualViewer3D *) h->ExecPlugin(1, gPad);
287  } else {
288  viewer = (TVirtualViewer3D *) h->ExecPlugin(1, pad);
289  }
290  }
291  return viewer;
292 }
const char Option_t
Definition: RtypesCore.h:62
TH1 * h
Definition: legend2.C:5
TPluginHandler * FindHandler(const char *base, const char *uri=0)
Returns the handler if there exists a handler for the specified URI.
Int_t LoadPlugin()
Load the plugin library for this handler.
Long_t ExecPlugin(int nargs, const T &...params)
Abstract 3D shapes viewer.
TVirtualPad is an abstract base class for the Pad and Canvas classes.
Definition: TVirtualPad.h:59
R__EXTERN TPluginManager * gPluginMgr
ClassImp(TVirtualViewer3D) TVirtualViewer3D *TVirtualViewer3D
Create a Viewer 3D of specified type.
int type
Definition: TGX11.cxx:120
#define gPad
Definition: TVirtualPad.h:288