OpenSceneGraph/include/osgViewer/ViewerEventHandlers

545 lines
23 KiB
Plaintext
Raw Normal View History

2009-11-19 19:54:15 +08:00
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
2009-11-19 19:54:15 +08:00
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
2009-11-19 19:54:15 +08:00
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
2009-11-19 19:54:15 +08:00
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#ifndef OSGVIEWER_VIEWEREVENTHANDLERS
#define OSGVIEWER_VIEWEREVENTHANDLERS 1
#include <osg/AnimationPath>
#include <osgText/Text>
#include <osgGA/GUIEventHandler>
#include <osgGA/AnimationPathManipulator>
#include <osgViewer/GraphicsWindow>
#include <osgViewer/Viewer>
#include <osgDB/fstream>
namespace osgViewer {
/** Event handler for adding on screen help to Viewers.*/
2009-11-19 19:54:15 +08:00
class OSGVIEWER_EXPORT HelpHandler : public osgGA::GUIEventHandler
{
2009-11-19 19:54:15 +08:00
public:
HelpHandler(osg::ApplicationUsage* au=0);
2009-11-19 19:54:15 +08:00
void setApplicationUsage(osg::ApplicationUsage* au) { _applicationUsage = au; }
osg::ApplicationUsage* getApplicationUsage() { return _applicationUsage.get(); }
const osg::ApplicationUsage* getApplicationUsage() const { return _applicationUsage.get(); }
void setKeyEventTogglesOnScreenHelp(int key) { _keyEventTogglesOnScreenHelp = key; }
int getKeyEventTogglesOnScreenHelp() const { return _keyEventTogglesOnScreenHelp; }
2009-11-19 19:54:15 +08:00
void reset();
osg::Camera* getCamera() { return _camera.get(); }
const osg::Camera* getCamera() const { return _camera.get(); }
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa);
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage& usage) const;
protected:
void setUpHUDCamera(osgViewer::ViewerBase* viewer);
void setUpScene(osgViewer::ViewerBase* viewer);
2009-11-19 19:54:15 +08:00
osg::ref_ptr<osg::ApplicationUsage> _applicationUsage;
int _keyEventTogglesOnScreenHelp;
bool _helpEnabled;
bool _initialized;
osg::ref_ptr<osg::Camera> _camera;
osg::ref_ptr<osg::Switch> _switch;
2009-11-19 19:54:15 +08:00
};
/**
* Event handler for adding on screen stats reporting to Viewers.
*/
2009-11-19 19:54:15 +08:00
class OSGVIEWER_EXPORT StatsHandler : public osgGA::GUIEventHandler
{
2009-11-19 19:54:15 +08:00
public:
StatsHandler();
enum StatsType
{
NO_STATS = 0,
FRAME_RATE = 1,
VIEWER_STATS = 2,
CAMERA_SCENE_STATS = 3,
VIEWER_SCENE_STATS = 4,
LAST = 5
};
2009-11-19 19:54:15 +08:00
void setKeyEventTogglesOnScreenStats(int key) { _keyEventTogglesOnScreenStats = key; }
int getKeyEventTogglesOnScreenStats() const { return _keyEventTogglesOnScreenStats; }
2009-11-19 19:54:15 +08:00
void setKeyEventPrintsOutStats(int key) { _keyEventPrintsOutStats = key; }
int getKeyEventPrintsOutStats() const { return _keyEventPrintsOutStats; }
void setKeyEventToggleVSync(int key) { _keyEventToggleVSync = key; }
int getKeyEventToggleVSync() const { return _keyEventToggleVSync; }
double getBlockMultiplier() const { return _blockMultiplier; }
void reset();
osg::Camera* getCamera() { return _camera.get(); }
const osg::Camera* getCamera() const { return _camera.get(); }
virtual bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa);
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage& usage) const;
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
/** This allows the user to register additional stats lines that will
be added to the graph. The stats for these will be gotten from the
viewer (viewer->getViewerStats()). The stats can be displayed in
either or all of the following ways:
- A numeric time beside the stat name
Requires that an elapsed time be recorded in the viewer's stats
for the "timeTakenName".
- A bar in the top bar graph
Requires that two times (relative to the viewer's start tick) be
recorded in the viewer's stats for the "beginTimeName" and
"endTimeName".
- A line in the bottom graph
Requires that an elapsed time be recorded in the viewer's stats
for the "timeTakenName" and that the value be used as an average.
If you don't want a numeric value and a line in the bottom line
graph for your value, pass the empty string for timeTakenName. If
you don't want a bar in the graph, pass the empty string for
beginTimeName and endTimeName.
@param label The label to be displayed to identify the line in the stats.
@param textColor Will be used for the text label, the numeric time and the bottom line graph.
@param barColor Will be used for the bar in the top bar graph.
@param timeTakenName The name to be queried in the viewer stats for the numeric value (also used for the bottom line graph).
@param multiplier The multiplier to apply to the numeric value before displaying it in the stats.
@param average Whether to use the average value of the numeric value.
@param averageInInverseSpace Whether to average in inverse space (used for frame rate).
@param beginTimeName The name to be queried in the viewer stats for the begin time for the top bar graph.
@param endTimeName The name to be queried in the viewer stats for the end time for the top bar graph.
@param maxValue The value to use as maximum in the bottom line graph. Stats will be clamped between 0 and that value, and it will be the highest visible value in the graph.
*/
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
void addUserStatsLine(const std::string& label, const osg::Vec4& textColor, const osg::Vec4& barColor,
const std::string& timeTakenName, float multiplier, bool average, bool averageInInverseSpace,
const std::string& beginTimeName, const std::string& endTimeName, float maxValue);
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
void removeUserStatsLine(const std::string& label);
protected:
void setUpHUDCamera(osgViewer::ViewerBase* viewer);
osg::Geometry* createBackgroundRectangle(const osg::Vec3& pos, const float width, const float height, osg::Vec4& color);
osg::Geometry* createGeometry(const osg::Vec3& pos, float height, const osg::Vec4& colour, unsigned int numBlocks);
osg::Geometry* createFrameMarkers(const osg::Vec3& pos, float height, const osg::Vec4& colour, unsigned int numBlocks);
osg::Geometry* createTick(const osg::Vec3& pos, float height, const osg::Vec4& colour, unsigned int numTicks);
2009-11-19 19:54:15 +08:00
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
void createTimeStatsLine(const std::string& lineLabel, osg::Vec3 pos,
const osg::Vec4& textColor, const osg::Vec4& barColor, osg::Stats* viewerStats, osg::Stats* stats,
const std::string& timeTakenName, float multiplier, bool average, bool averageInInverseSpace,
const std::string& beginTimeName, const std::string& endTimeName);
void createCameraTimeStats(osg::Vec3& pos, bool acquireGPUStats, osg::Stats* viewerStats, osg::Camera* camera);
void setUpScene(osgViewer::ViewerBase* viewer);
2009-11-19 19:54:15 +08:00
void updateThreadingModelText();
int _keyEventTogglesOnScreenStats;
int _keyEventPrintsOutStats;
int _keyEventToggleVSync;
int _statsType;
bool _initialized;
osg::ref_ptr<osg::Camera> _camera;
2009-11-19 19:54:15 +08:00
osg::ref_ptr<osg::Switch> _switch;
2009-11-19 19:54:15 +08:00
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
osg::ref_ptr<osg::Geode> _statsGeode;
ViewerBase::ThreadingModel _threadingModel;
osg::ref_ptr<osgText::Text> _threadingModelText;
unsigned int _frameRateChildNum;
unsigned int _viewerChildNum;
unsigned int _cameraSceneChildNum;
unsigned int _viewerSceneChildNum;
unsigned int _numBlocks;
double _blockMultiplier;
2009-11-19 19:54:15 +08:00
float _statsWidth;
float _statsHeight;
2009-11-19 19:54:15 +08:00
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
std::string _font;
float _startBlocks;
float _leftPos;
float _characterSize;
float _lineHeight;
From Jean-Sebastien Guay, "For a long time now I've wanted to be able to add custom values into the stats handler's graph. Here is my proposal of how I'd do this. It's surely not perfect and I'm open to suggestions, but I've already made more changes than I wanted to in order to be able to implement this... The user calls statsHandler->addUserStatsLine() providing: - the label they want for that line in the graph - the text and bar colors they want in the graph - the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed. Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph. They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars. Along the way I cleaned up the existing code a bit: * Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats(). * I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning. * The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input. "
2010-11-03 18:04:34 +08:00
struct UserStatsLine
{
std::string label;
osg::Vec4 textColor;
osg::Vec4 barColor;
std::string timeTakenName;
float multiplier;
bool average;
bool averageInInverseSpace;
std::string beginTimeName;
std::string endTimeName;
float maxValue;
UserStatsLine(const std::string& label_, const osg::Vec4& textColor_, const osg::Vec4& barColor_,
const std::string& timeTakenName_, float multiplier_, bool average_, bool averageInInverseSpace_,
const std::string& beginTimeName_, const std::string& endTimeName_, float maxValue_)
: label(label_), textColor(textColor_), barColor(barColor_),
timeTakenName(timeTakenName_), multiplier(multiplier_), average(average_), averageInInverseSpace(averageInInverseSpace_),
beginTimeName(beginTimeName_), endTimeName(endTimeName_), maxValue(maxValue_)
{
}
};
typedef std::vector<UserStatsLine> UserStatsLines;
UserStatsLines _userStatsLines;
2009-11-19 19:54:15 +08:00
};
/** Event handler allowing to change the screen resolution (in windowed mode) and toggle between fullscreen and windowed mode. */
2009-11-19 19:54:15 +08:00
class OSGVIEWER_EXPORT WindowSizeHandler : public osgGA::GUIEventHandler
{
2009-11-19 19:54:15 +08:00
public:
WindowSizeHandler();
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage &usage) const;
void setKeyEventToggleFullscreen(int key) { _keyEventToggleFullscreen = key; }
int getKeyEventToggleFullscreen() const { return _keyEventToggleFullscreen; }
void setToggleFullscreen(bool flag) { _toggleFullscreen = flag; }
bool getToggleFullscreen() const { return _toggleFullscreen; }
void setKeyEventWindowedResolutionUp(int key) { _keyEventWindowedResolutionUp = key; }
int getKeyEventWindowedResolutionUp() const { return _keyEventWindowedResolutionUp; }
void setKeyEventWindowedResolutionDown(int key) { _keyEventWindowedResolutionDown = key; }
int getKeyEventWindowedResolutionDown() const { return _keyEventWindowedResolutionDown; }
void setChangeWindowedResolution(bool flag) { _changeWindowedResolution = flag; }
bool getChangeWindowedResolution() const { return _changeWindowedResolution; }
virtual bool handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa);
protected:
void toggleFullscreen(osgViewer::GraphicsWindow *window);
void changeWindowedResolution(osgViewer::GraphicsWindow *window, bool increase);
unsigned int getNearestResolution(int screenWidth, int screenHeight, int width, int height) const;
int _keyEventToggleFullscreen;
bool _toggleFullscreen;
int _keyEventWindowedResolutionUp;
int _keyEventWindowedResolutionDown;
bool _changeWindowedResolution;
std::vector<osg::Vec2> _resolutionList;
int _currentResolutionIndex;
};
/** Event handler allowing to change the viewer threading model */
2009-11-19 19:54:15 +08:00
class OSGVIEWER_EXPORT ThreadingHandler : public osgGA::GUIEventHandler
{
2009-11-19 19:54:15 +08:00
public:
ThreadingHandler();
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage &usage) const;
void setKeyEventChangeThreadingModel(int key) { _keyEventChangeThreadingModel = key; }
int getKeyEventChangeThreadingModel() const { return _keyEventChangeThreadingModel; }
void setChangeThreadingModel(bool flag) { _changeThreadingModel = flag; }
bool getChangeThreadingModel() const { return _changeThreadingModel; }
void setKeyEventChangeEndBarrierPosition(int key) { _keyEventChangeEndBarrierPosition = key; }
int getKeyEventChangeEndBarrierPosition() const { return _keyEventChangeEndBarrierPosition; }
void setChangeEndBarrierPosition(bool flag) { _changeEndBarrierPosition = flag; }
bool getChangeEndBarrierPosition() const { return _changeEndBarrierPosition; }
bool handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa);
protected:
int _keyEventChangeThreadingModel;
bool _changeThreadingModel;
int _keyEventChangeEndBarrierPosition;
bool _changeEndBarrierPosition;
osg::Timer_t _tickOrLastKeyPress;
bool _done;
};
/**
2008-02-29 04:02:43 +08:00
* Event handler allowing the user to record the animation "path" of a camera. In it's current
* implementation, this handler cannot guarantee the final view matrix is correct; it is
* conceivable that the matrix may be one frame off. Eh--not a big deal! :)
* TODO: Write the file as we go, not when it's all done.
* TODO: Create an osgviewer on-screen indication that animation is taking place.
*/
2007-06-02 00:14:47 +08:00
class OSGVIEWER_EXPORT RecordCameraPathHandler : public osgGA::GUIEventHandler
{
public:
RecordCameraPathHandler(const std::string &filename = "saved_animation.path", float fps = 25.0f);
void setKeyEventToggleRecord(int key) { _keyEventToggleRecord = key; }
int getKeyEventToggleRecord() const { return _keyEventToggleRecord; }
void setKeyEventTogglePlayback(int key) { _keyEventTogglePlayback = key; }
int getKeyEventTogglePlayback() const { return _keyEventTogglePlayback; }
void setAutoIncrementFilename( bool autoinc = true ) { _autoinc = autoinc?0:-1; }
virtual void getUsage(osg::ApplicationUsage &usage) const;
bool handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa);
protected:
std::string _filename;
int _autoinc;
osgDB::ofstream _fout;
int _keyEventToggleRecord;
int _keyEventTogglePlayback;
bool _currentlyRecording;
bool _currentlyPlaying;
double _interval;
double _delta;
osg::Timer_t _animStartTime;
osg::Timer_t _lastFrameTime;
osg::ref_ptr<osg::AnimationPath> _animPath;
osg::ref_ptr<osgGA::AnimationPathManipulator> _animPathManipulator;
osg::ref_ptr<osgGA::CameraManipulator> _oldManipulator;
};
2008-02-29 04:02:43 +08:00
/** Event handler for increase/decreasing LODScale.*/
2009-11-19 19:54:15 +08:00
class OSGVIEWER_EXPORT LODScaleHandler : public osgGA::GUIEventHandler
2008-02-29 04:02:43 +08:00
{
2009-11-19 19:54:15 +08:00
public:
2008-02-29 04:02:43 +08:00
LODScaleHandler();
void setKeyEventIncreaseLODScale(int key) { _keyEventIncreaseLODScale = key; }
int getKeyEventIncreaseLODScale() const { return _keyEventIncreaseLODScale; }
2009-11-19 19:54:15 +08:00
2008-02-29 04:02:43 +08:00
void setKeyEventDecreaseLODScale(int key) { _keyEventDecreaseLODScale = key; }
int getKeyEventDecreaseLODScale() const { return _keyEventDecreaseLODScale; }
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa);
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage& usage) const;
protected:
int _keyEventIncreaseLODScale;
int _keyEventDecreaseLODScale;
2009-11-19 19:54:15 +08:00
};
/** Event handler for toggling SyncToVBlank.*/
class OSGVIEWER_EXPORT ToggleSyncToVBlankHandler : public osgGA::GUIEventHandler
{
public:
ToggleSyncToVBlankHandler();
void setKeyEventToggleSyncToVBlankHandler(int key) { _keyEventToggleSyncToVBlank = key; }
int getKeyEventToggleSyncToVBlankHandler() const { return _keyEventToggleSyncToVBlank; }
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa);
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage& usage) const;
protected:
int _keyEventToggleSyncToVBlank;
2008-02-29 04:02:43 +08:00
};
/** Event handler that will capture the screen on key press. */
class OSGVIEWER_EXPORT ScreenCaptureHandler : public osgGA::GUIEventHandler
{
public:
/** Abstract base class for what to do when a screen capture happens. */
class CaptureOperation : public osg::Referenced
{
public:
virtual void operator()(const osg::Image& image, const unsigned int context_id) = 0;
};
/** Concrete implementation of a CaptureOperation that writes the screen capture to a file. */
class OSGVIEWER_EXPORT WriteToFile : public CaptureOperation
{
public:
enum SavePolicy
{
OVERWRITE,
SEQUENTIAL_NUMBER
// ... any others?
};
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
WriteToFile(const std::string& filename, const std::string& extension, SavePolicy savePolicy = SEQUENTIAL_NUMBER);
virtual void operator()(const osg::Image& image, const unsigned int context_id);
void setSavePolicy(SavePolicy savePolicy) { _savePolicy = savePolicy; }
SavePolicy getSavePolicy() const { return _savePolicy; }
protected:
2009-11-19 19:54:15 +08:00
2009-01-07 18:32:59 +08:00
WriteToFile& operator = (const WriteToFile&) { return *this; }
2009-11-19 19:54:15 +08:00
const std::string _filename;
const std::string _extension;
SavePolicy _savePolicy;
std::vector<unsigned int> _contextSaveCounter;
};
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
/** @param numFrames >0: capture that number of frames. <0: capture all frames, call stopCapture() to stop it. */
ScreenCaptureHandler(CaptureOperation* defaultOperation = 0, int numFrames = 1);
void setKeyEventTakeScreenShot(int key) { _keyEventTakeScreenShot = key; }
int getKeyEventTakeScreenShot() const { return _keyEventTakeScreenShot; }
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
void setKeyEventToggleContinuousCapture(int key) { _keyEventToggleContinuousCapture = key; }
int getKeyEventToggleContinuousCapture() const { return _keyEventToggleContinuousCapture; }
void setCaptureOperation(CaptureOperation* operation);
CaptureOperation* getCaptureOperation() const;
// aa will point to an osgViewer::View, so we will take a screenshot
// of that view's graphics contexts.
virtual bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa);
/** Capture the given viewer's views on the next frame. */
virtual void captureNextFrame(osgViewer::ViewerBase& viewer);
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
/** Set the number of frames to capture.
@param numFrames >0: capture that number of frames. <0: capture all frames, call stopCapture() to stop it. */
void setFramesToCapture(int numFrames);
/** Get the number of frames to capture. */
int getFramesToCapture() const;
/** Start capturing any viewer(s) the handler is attached to at the
end of the next frame. */
void startCapture();
/** Stop capturing. */
void stopCapture();
/** Get the keyboard and mouse usage of this manipulator.*/
virtual void getUsage(osg::ApplicationUsage& usage) const;
protected:
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
bool _startCapture;
bool _stopCapture;
int _keyEventTakeScreenShot;
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
int _keyEventToggleContinuousCapture;
// there could be a key to start taking screenshots every new frame
osg::ref_ptr<CaptureOperation> _operation;
osg::ref_ptr<osg::Camera::DrawCallback> _callback;
void addCallbackToViewer(osgViewer::ViewerBase& viewer);
From Jean-Sebastien Guay, "I've made a change to the ScreenCaptureHandler's addCallbackToViewer method, so that it iterates over GraphicsContexts instead of GraphicsWindows. When the viewer has a pbuffer (for offscreen rendering without a window) then it wouldn't add the WindowCaptureCallback to that context since it wasn't in the list returned by ViewerBase::getWindows(). And anyways, I originally wrote the code, and I didn't see any reason why I did it with windows instead of contexts... I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible. Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as: 0 : don't capture <0 : capture continuously >0 : capture that number of frames then stop I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C'). Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-) I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now. I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line // add the screen capture handler viewer.addEventHandler(new osgViewer::ScreenCaptureHandler); with // add the screen capture handler osgViewer::ScreenCaptureHandler* captureHandler = new osgViewer::ScreenCaptureHandler( new osgViewer::ScreenCaptureHandler::WriteToFile( "screenshot", "jpg", osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER), -1); viewer.addEventHandler(captureHandler); captureHandler->startCapture(); And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts. "
2009-11-19 20:01:49 +08:00
void removeCallbackFromViewer(osgViewer::ViewerBase& viewer);
osg::Camera* findAppropriateCameraForCallback(osgViewer::ViewerBase& viewer);
};
/** InteractiveImage is an event handler that computes the mouse coordinates in an images coordinate frame
* and then passes keyboard and mouse events to it. This event handler is useful for vnc or browser
* surfaces in the 3D scene.*/
class OSGVIEWER_EXPORT InteractiveImageHandler : public osgGA::GUIEventHandler, public osg::Drawable::CullCallback
{
public:
/// Constructor to use when the InteractiveImage is in the 3D scene (i.e. not in a fullscreen HUD overlay).
InteractiveImageHandler(osg::Image* image);
/// Constructor to use when the InteractiveImage is in a fullscreen HUD overlay.
InteractiveImageHandler(osg::Image* image, osg::Texture2D* texture, osg::Camera* camera);
META_Object(osgViewer, InteractiveImageHandler);
2009-11-19 19:54:15 +08:00
virtual bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor* nv);
virtual bool cull(osg::NodeVisitor* nv, osg::Drawable* drawable, osg::RenderInfo* renderInfo) const;
protected:
virtual ~InteractiveImageHandler() {}
2009-11-19 19:54:15 +08:00
InteractiveImageHandler() {}
InteractiveImageHandler(const InteractiveImageHandler&,const osg::CopyOp& = osg::CopyOp::SHALLOW_COPY):
osg::Object(), osgGA::GUIEventHandler(), osg::Drawable::CullCallback(), _fullscreen(false) {}
bool mousePosition(osgViewer::View* view, osg::NodeVisitor* nv, const osgGA::GUIEventAdapter& ea, int& x, int &y) const;
From Jean-Sebastien Guay, "I've been working in the last few days to get QWidgetImage to a point where it can fill a need we have: to be able to use Qt to make HUDs and to display widgets over / inside an OSG scene. --------------- Current results --------------- I've attached what I have at this point. The modified QWidgetImage + QGraphicsViewAdapter classes can be rendered fullscreen (i.e. the Qt QGraphicsView's size follows the size of the OSG window) or on a quad in the scene as before. It will let events go through to OSG if no widget is under the mouse when they happen (useful when used as a HUD with transparent parts - a click-focus scheme could be added later too). It also supercedes Martin Scheffler's submission because it adds a getter/setter for the QGraphicsViewAdapter's background color (and the user can set their widget to be transparent using widget->setAttribute(Qt::WA_TranslucentBackground) themselves). The included osgQtBrowser example has been modified to serve as a test bed for these changes. It has lots more command line arguments than before, some of which can be removed eventually (once things are tested). Note that it may be interesting to change its name or split it into two examples. Though if things go well, the specific QWebViewImage class can be removed completely and we can consolidate to using QWidgetImage everywhere, and then a single example to demonstrate it would make more sense, albeit not named osgQtBrowser... You can try this path by using the --useWidgetImage --useBrowser command line arguments - this results in an equivalent setup to QWebViewImage, but using QWidgetImage, and doesn't work completely yet for some unknown reason, see below. ---------------- Remaining issues ---------------- There are a few issues left to fix, and for these I request the community's assistance. They are not blockers for me, and with my limited Qt experience I don't feel like I'm getting any closer to fixing them, so if someone else could pitch in and see what they can find, it would be appreciated. It would be really nice to get them fixed, that way we'd really have a first-class integration of Qt widgets in an OSG scene. The issues are noted in the osgQtBrowser.cpp source file, but here they are too: ------------------------------------------------------------------- QWidgetImage still has some issues, some examples are: 1. Editing in the QTextEdit doesn't work. Also when started with --useBrowser, editing in the search field on YouTube doesn't work. But that same search field when using QWebViewImage works... And editing in the text field in the pop-up getInteger dialog works too. All these cases use QGraphicsViewAdapter under the hood, so why do some work and others don't? a) osgQtBrowser --useWidgetImage [--fullscreen] (optional) b) Try to click in the QTextEdit and type, or to select text and drag-and-drop it somewhere else in the QTextEdit. These don't work. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operations in b), they all work. e) osgQtBrowser --useWidgetImage --useBrowser [--fullscreen] f) Try to click in the search field and type, it doesn't work. g) osgQtBrowser h) Try the operation in f), it works. 2. Operations on floating windows (--numFloatingWindows 1 or more). Moving by dragging the titlebar, clicking the close button, resizing them, none of these work. I wonder if it's because the OS manages those functions (they're functions of the window decorations) so we need to do something special for that? But in --sanityCheck mode they work. a) osgQtBrowser --useWidgetImage --numFloatingWindows 1 [--fullscreen] b) Try to drag the floating window, click the close button, or drag its sides to resize it. None of these work. c) osgQtBrowser --useWidgetImage --numFloatingWindows 1 --sanityCheck d) Try the operations in b), all they work. e) osgQtBrowser --useWidgetImage [--fullscreen] f) Click the button so that the getInteger() dialog is displayed, then try to move that dialog or close it with the close button, these don't work. g) osgQtBrowser --useWidgetImage --sanityCheck h) Try the operation in f), it works. 3. (Minor) The QGraphicsView's scrollbars don't appear when using QWidgetImage or QWebViewImage. QGraphicsView is a QAbstractScrollArea and it should display scrollbars as soon as the scene is too large to fit the view. a) osgQtBrowser --useWidgetImage --fullscreen b) Resize the OSG window so it's smaller than the QTextEdit. Scrollbars should appear but don't. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operation in b), scrollbars appear. Even if you have floating windows (by clicking the button or by adding --numFloatingWindows 1) and move them outside the view, scrollbars appear too. You can't test that case in OSG for now because of problem 2 above, but that's pretty cool. 4. (Minor) In sanity check mode, the widget added to the QGraphicsView is centered. With QGraphicsViewAdapter, it is not. a) osgQtBrowser --useWidgetImage [--fullscreen] b) The QTextEdit and button are not in the center of the image generated by the QGraphicsViewAdapter. c) osgQtBrowser --useWidgetImage --sanityCheck d) The QTextEdit and button are in the center of the QGraphicsView. ------------------------------------------------------------------- As you can see I've put specific repro steps there too, so it's clear what I mean by a given problem. The --sanityCheck mode is useful to see what should happen in a "normal" Qt app that demonstrates the same situation, so hopefully we can get to a point where it behaves the same with --sanityCheck and without."
2010-06-15 21:57:44 +08:00
bool computeIntersections(osgViewer::View* view, float x,float y, const osg::NodePath& nodePath, osgUtil::LineSegmentIntersector::Intersections& intersections,osg::Node::NodeMask traversalMask = 0xffffffff) const;
void resize(int width, int height);
From Jean-Sebastien Guay, "I've been working in the last few days to get QWidgetImage to a point where it can fill a need we have: to be able to use Qt to make HUDs and to display widgets over / inside an OSG scene. --------------- Current results --------------- I've attached what I have at this point. The modified QWidgetImage + QGraphicsViewAdapter classes can be rendered fullscreen (i.e. the Qt QGraphicsView's size follows the size of the OSG window) or on a quad in the scene as before. It will let events go through to OSG if no widget is under the mouse when they happen (useful when used as a HUD with transparent parts - a click-focus scheme could be added later too). It also supercedes Martin Scheffler's submission because it adds a getter/setter for the QGraphicsViewAdapter's background color (and the user can set their widget to be transparent using widget->setAttribute(Qt::WA_TranslucentBackground) themselves). The included osgQtBrowser example has been modified to serve as a test bed for these changes. It has lots more command line arguments than before, some of which can be removed eventually (once things are tested). Note that it may be interesting to change its name or split it into two examples. Though if things go well, the specific QWebViewImage class can be removed completely and we can consolidate to using QWidgetImage everywhere, and then a single example to demonstrate it would make more sense, albeit not named osgQtBrowser... You can try this path by using the --useWidgetImage --useBrowser command line arguments - this results in an equivalent setup to QWebViewImage, but using QWidgetImage, and doesn't work completely yet for some unknown reason, see below. ---------------- Remaining issues ---------------- There are a few issues left to fix, and for these I request the community's assistance. They are not blockers for me, and with my limited Qt experience I don't feel like I'm getting any closer to fixing them, so if someone else could pitch in and see what they can find, it would be appreciated. It would be really nice to get them fixed, that way we'd really have a first-class integration of Qt widgets in an OSG scene. The issues are noted in the osgQtBrowser.cpp source file, but here they are too: ------------------------------------------------------------------- QWidgetImage still has some issues, some examples are: 1. Editing in the QTextEdit doesn't work. Also when started with --useBrowser, editing in the search field on YouTube doesn't work. But that same search field when using QWebViewImage works... And editing in the text field in the pop-up getInteger dialog works too. All these cases use QGraphicsViewAdapter under the hood, so why do some work and others don't? a) osgQtBrowser --useWidgetImage [--fullscreen] (optional) b) Try to click in the QTextEdit and type, or to select text and drag-and-drop it somewhere else in the QTextEdit. These don't work. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operations in b), they all work. e) osgQtBrowser --useWidgetImage --useBrowser [--fullscreen] f) Try to click in the search field and type, it doesn't work. g) osgQtBrowser h) Try the operation in f), it works. 2. Operations on floating windows (--numFloatingWindows 1 or more). Moving by dragging the titlebar, clicking the close button, resizing them, none of these work. I wonder if it's because the OS manages those functions (they're functions of the window decorations) so we need to do something special for that? But in --sanityCheck mode they work. a) osgQtBrowser --useWidgetImage --numFloatingWindows 1 [--fullscreen] b) Try to drag the floating window, click the close button, or drag its sides to resize it. None of these work. c) osgQtBrowser --useWidgetImage --numFloatingWindows 1 --sanityCheck d) Try the operations in b), all they work. e) osgQtBrowser --useWidgetImage [--fullscreen] f) Click the button so that the getInteger() dialog is displayed, then try to move that dialog or close it with the close button, these don't work. g) osgQtBrowser --useWidgetImage --sanityCheck h) Try the operation in f), it works. 3. (Minor) The QGraphicsView's scrollbars don't appear when using QWidgetImage or QWebViewImage. QGraphicsView is a QAbstractScrollArea and it should display scrollbars as soon as the scene is too large to fit the view. a) osgQtBrowser --useWidgetImage --fullscreen b) Resize the OSG window so it's smaller than the QTextEdit. Scrollbars should appear but don't. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operation in b), scrollbars appear. Even if you have floating windows (by clicking the button or by adding --numFloatingWindows 1) and move them outside the view, scrollbars appear too. You can't test that case in OSG for now because of problem 2 above, but that's pretty cool. 4. (Minor) In sanity check mode, the widget added to the QGraphicsView is centered. With QGraphicsViewAdapter, it is not. a) osgQtBrowser --useWidgetImage [--fullscreen] b) The QTextEdit and button are not in the center of the image generated by the QGraphicsViewAdapter. c) osgQtBrowser --useWidgetImage --sanityCheck d) The QTextEdit and button are in the center of the QGraphicsView. ------------------------------------------------------------------- As you can see I've put specific repro steps there too, so it's clear what I mean by a given problem. The --sanityCheck mode is useful to see what should happen in a "normal" Qt app that demonstrates the same situation, so hopefully we can get to a point where it behaves the same with --sanityCheck and without."
2010-06-15 21:57:44 +08:00
osg::observer_ptr<osg::Image> _image;
osg::observer_ptr<osg::Texture2D> _texture;
From Jean-Sebastien Guay, "I've been working in the last few days to get QWidgetImage to a point where it can fill a need we have: to be able to use Qt to make HUDs and to display widgets over / inside an OSG scene. --------------- Current results --------------- I've attached what I have at this point. The modified QWidgetImage + QGraphicsViewAdapter classes can be rendered fullscreen (i.e. the Qt QGraphicsView's size follows the size of the OSG window) or on a quad in the scene as before. It will let events go through to OSG if no widget is under the mouse when they happen (useful when used as a HUD with transparent parts - a click-focus scheme could be added later too). It also supercedes Martin Scheffler's submission because it adds a getter/setter for the QGraphicsViewAdapter's background color (and the user can set their widget to be transparent using widget->setAttribute(Qt::WA_TranslucentBackground) themselves). The included osgQtBrowser example has been modified to serve as a test bed for these changes. It has lots more command line arguments than before, some of which can be removed eventually (once things are tested). Note that it may be interesting to change its name or split it into two examples. Though if things go well, the specific QWebViewImage class can be removed completely and we can consolidate to using QWidgetImage everywhere, and then a single example to demonstrate it would make more sense, albeit not named osgQtBrowser... You can try this path by using the --useWidgetImage --useBrowser command line arguments - this results in an equivalent setup to QWebViewImage, but using QWidgetImage, and doesn't work completely yet for some unknown reason, see below. ---------------- Remaining issues ---------------- There are a few issues left to fix, and for these I request the community's assistance. They are not blockers for me, and with my limited Qt experience I don't feel like I'm getting any closer to fixing them, so if someone else could pitch in and see what they can find, it would be appreciated. It would be really nice to get them fixed, that way we'd really have a first-class integration of Qt widgets in an OSG scene. The issues are noted in the osgQtBrowser.cpp source file, but here they are too: ------------------------------------------------------------------- QWidgetImage still has some issues, some examples are: 1. Editing in the QTextEdit doesn't work. Also when started with --useBrowser, editing in the search field on YouTube doesn't work. But that same search field when using QWebViewImage works... And editing in the text field in the pop-up getInteger dialog works too. All these cases use QGraphicsViewAdapter under the hood, so why do some work and others don't? a) osgQtBrowser --useWidgetImage [--fullscreen] (optional) b) Try to click in the QTextEdit and type, or to select text and drag-and-drop it somewhere else in the QTextEdit. These don't work. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operations in b), they all work. e) osgQtBrowser --useWidgetImage --useBrowser [--fullscreen] f) Try to click in the search field and type, it doesn't work. g) osgQtBrowser h) Try the operation in f), it works. 2. Operations on floating windows (--numFloatingWindows 1 or more). Moving by dragging the titlebar, clicking the close button, resizing them, none of these work. I wonder if it's because the OS manages those functions (they're functions of the window decorations) so we need to do something special for that? But in --sanityCheck mode they work. a) osgQtBrowser --useWidgetImage --numFloatingWindows 1 [--fullscreen] b) Try to drag the floating window, click the close button, or drag its sides to resize it. None of these work. c) osgQtBrowser --useWidgetImage --numFloatingWindows 1 --sanityCheck d) Try the operations in b), all they work. e) osgQtBrowser --useWidgetImage [--fullscreen] f) Click the button so that the getInteger() dialog is displayed, then try to move that dialog or close it with the close button, these don't work. g) osgQtBrowser --useWidgetImage --sanityCheck h) Try the operation in f), it works. 3. (Minor) The QGraphicsView's scrollbars don't appear when using QWidgetImage or QWebViewImage. QGraphicsView is a QAbstractScrollArea and it should display scrollbars as soon as the scene is too large to fit the view. a) osgQtBrowser --useWidgetImage --fullscreen b) Resize the OSG window so it's smaller than the QTextEdit. Scrollbars should appear but don't. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operation in b), scrollbars appear. Even if you have floating windows (by clicking the button or by adding --numFloatingWindows 1) and move them outside the view, scrollbars appear too. You can't test that case in OSG for now because of problem 2 above, but that's pretty cool. 4. (Minor) In sanity check mode, the widget added to the QGraphicsView is centered. With QGraphicsViewAdapter, it is not. a) osgQtBrowser --useWidgetImage [--fullscreen] b) The QTextEdit and button are not in the center of the image generated by the QGraphicsViewAdapter. c) osgQtBrowser --useWidgetImage --sanityCheck d) The QTextEdit and button are in the center of the QGraphicsView. ------------------------------------------------------------------- As you can see I've put specific repro steps there too, so it's clear what I mean by a given problem. The --sanityCheck mode is useful to see what should happen in a "normal" Qt app that demonstrates the same situation, so hopefully we can get to a point where it behaves the same with --sanityCheck and without."
2010-06-15 21:57:44 +08:00
bool _fullscreen;
osg::observer_ptr<osg::Camera> _camera;
2009-11-19 19:54:15 +08:00
};
}
#endif