This page attempts to list answers to frequently asked questions
(perceived, or real) regarding VP1. It is obviously rather incomplete
at present.
Please send us ideas for what questions needs to be answered in this FAQ!
Overview
- For VP1 users.
- For plugin developers.
Questions and Answers
First thing to check is whether you can launch another x-application such as "glxgears". If you can't, then you probably didn't supply the -X (or -Y from OSX) flag to ssh when login into lxplus or wherever you are trying to launch VP1 from.
If you DO see glxgears popping up, but still has the problem with VP1, then it is quite likely due to a known issue with a conflict between VP1 and the performance monitoring that is sometimes enabled in Athena jobs. Try to disable it somehow and try again (if you enabled VP1 by setting doVP1=True in some standard jobOptions you should contact the responsible of those jobOptions and ask them to make sure that the performance monitoring is automatically disabled when doVP1 is True).
[top]
This is likely a result of poor drivers for your graphics card which is not happy about the way that VP1 uses multiple 3D rendering contexts. Apart from getting better or updated drivers, there is not much to do about this problem apart from abstaining from launching more than one 3D channel at a time.
To avoid accidentally doing so anyway, you can set the environment variable VP1_DISALLOW_MULTIPLE_CHANNELS to 1, for example by the following command in bash:
export VP1_DISALLOW_MULTIPLE_CHANNELS=1
before launching VP1. In that case, VP1 will helpfully prevent you from launching a second channel. You can check that the environment variable is set by trying a
echo $VP1_DISALLOW_MULTIPLE_CHANNELS
which should return "1". You might wish to set the environment variable in your .bashrc (or equivalent for other shells).
[top]
This problem is almost always a sign of some parameter of some object in the scene you are viewing having attained a not-a-number or infinite value. Thus, it is most likely a bug. Before reporting it, you can try to narrow the culprit down by turning on/off different systems in the "General" tab of the controller, and see if it is a given system which causes the problem.
You can also type the word "dumpiv" in the viewer, and you will get a textual representation of your scene in a .iv file in your run directory which you can inspect (or send to the vp1 developers along with your bugreport).
[top]
The usual reason for this is that your plugin did not compile. To make sure that it actually did, look inside the $CMTCONFIG/lib/vp1plugins directory of your InstallArea for .so files. This is basically all that VP1 does, so if your plugins .so does not show up there, VP1 won't find it either.
[top]
In the newest versions,
VP1 has inbuilt functionality which can grab screenshots of specific
channels: Use the snapshot button (the one with a camera) for getting the output as .png image files, and use the print button (the one with a printer) to send the output to a printers, postscript or pdf's.
For standard 3D channels you can add some options such as transparency, output size, etc. by checking some boxes in their controllers.
If you want screenshots of the whole GUI, you should use an external screenshot tool
such as
ksnapshot.
[top]
Even though VP1 can print directly to postscript files, .eps files intended for inclusion in e.g.
LaTeX documents, are best produced by getting a .png snapshot from VP1 and then subsequently converting it
to eps format by an external tool. This is not really a
VP1-specific issue, but since there are so many sub-optimal ways to
perform such conversions, here is a little script which consistenly
produces high-quality (and small filesize) eps files from your bitmapped image files (such
as .png):
image2eps. Download it, make it
executable ("chmod +x image2eps") and simply use it like
this:
./image2eps myvp1screenshot.png myvp1screenshot.eps
[top]
Obviously this may have many answers! Usually it is because Athena (which VP1 is part of) would not have run. In general if "Reco_trf.py
inputESDFile=myESD.pool.root" does not work, then VP1 cannot
either and this is not a VP1 problem.
One of the most common classes of errors are database problems (for example, you might see ERROR messages from "IOVDbSvc" in your logfile). For this,
we suggest you look at the DB documentation
here.
[top]
It is possible to access the cameras viewing
the scenegraph from a given 3D system through a getCameraList() method in the base class
IVP13DSystem. Furthermore, a helper class, VP1CameraHelper, makes it very easy to set up
zooming to a particuler node or sub-tree of your scenegraph. The following example should illustrate its usage:
#include "VP1Base/VP1CameraHelper.h"
//...
void MySystem::userPickedNode(SoNode* pickedNode, SoPath *pickedPath) {
//...
CamList cameras = getCameraList();
for (CamListItr itCam = cameras.begin(); itCam!=cameras.end(); ++itCam) {
VP1CameraHelper::animatedZoomToSubTree(*itCam,m_mySceneRoot,pickedNode,2.0,1.0);
}
//...
}
In this case the zoom to the picked node will take 2.0 seconds, the
final view will be somewhat larger than the object (a slack parameter
of 1.0), and the camerahelper will take care of deleting itself after
it is no longer needed (hence the "true").
[top]
Depending on the method you are reimplementing you might get a pointer to either the event or detector store,
however it is actually possible to get a hold of them (and service/tool locators) from any method by using one of the following methods from the base class:
StoreGateSvc * storeGate() const;
StoreGateSvc * detectorStore() const;
ISvcLocator * serviceLocator() const;
IToolSvc * toolSvc() const
Beware, however, that accessing e.g. storeGate() from systemcreate() could mean trying to
access event data while Athena is still in the initialisation stage. At least its a good
idea to always check that the four methods above dont return NULL (which
they might if you use them at the wrong time).
[top]