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