> quote from http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt
> The following attributes are supported by wglCreatePbufferARB:
>
> WGL_PBUFFER_LARGEST_ARB If this attribute is set to a
> non-zero value, the largest
> available pbuffer is allocated
> when the allocation of the pbuffer
> would otherwise fail due to
> insufficient resources. The width
> or height of the allocated pbuffer
> never exceeds <iWidth> and <iHeight>,
> respectively. Use wglQueryPbufferARB
> to retrieve the dimensions of the
> allocated pbuffer.
It notifies the user when the size is not as requested, but I could find no way for the program to detect this. I've added two lines to write the new size back into the _traits, I think this is appropriate, but I am not absolutely sure.
In PixelBufferX11 was no support, so I've added GLX_LARGEST_PBUFFER(_SGIX) support, with the same writeback to the _trais.
I have tested the GLX_LARGEST_PBUFFER version on linux and the WGL_PBUFFER_LARGEST_ARB with windows, all tested with the modified autocapture I just submitted.
"autocapture --pbuffer --window 100 100 18192 18192 cow.osg.\[0,0,-22.7\].trans"
gives me a 4096x4096 image on my windows machine,
and a 8192x8192 image on linux."
I found very useful to have a control whether osgView::setCameraManipulator does or does not reset camera to home position.
I extended method signature as follows:
void setCameraManipulator(osgGA::MatrixManipulator* manipulator, bool resetPosition = true);
keeping the current usage intact (default parameter), while enabling user to disable the position reset. That can be useful in the situation when manipulator position was already loaded, for example from a file (user specification), or defined any other way, while we do not want to be reset to home position. Other usability is usage of two manipulators in a modeling program (orbiting around the model, walking on the model) and changing between them while we want to preserve the position of a camera in the change. Games may benefit from it as well when we change from user-defined helicopter manipulator to soldier manipulator because the user escaped the helicopter. The camera will change manipulator but the position is expected to be kept in the transition (provided that user makes the state transition between the two manipulators himself).
"
osg::GraphicsContext, in order to give good integration with the
application's GUI toolkit. This works really well.
However, I need to share OpenGL texture resources with the standard
osgViewer GraphicsContext implementations, in particular the
PixelBuffers. This is essential for my application to conserve graphics
memory on low-end hardware. Currently the standard osg implementations
will not share resources with another derived osg::GraphicsContext,
other than the pre-defined osgViewer classes e.g. PixelBufferX11 is
hardcoded to only share resources with GraphicsWindowX11 and
PixelBufferX11 objects, and no other osg::GraphicsContext object.
To address this in the cleanest way I could think of, I have moved the
OpenGL handle variables for each platform into a small utility class,
e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11
and any other derived osg::GraphicsContext class can inherit from
GraphicsHandleX11 to share OpenGL resources.
I have updated the X11, Win32 and Carbon implementations to use this.
The changes are minor. I haven't touched the Cocoa implmentation as
I'm not familiar with it at all and couldn't test it - it will work
unchanged.
Without this I had some horrible hacks in my application, this greatly
simplifies things for me. It also simplifies the osgViewer
implementations slightly. Perhaps it may help with other users'
desires to share resources with external graphics contexts, as was
discussed on the user list recently."
Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
In Scene::updateSceneGraph(), change:
if (getSceneData())
{
updateVisitor.setImageRequestHandler(getImagePager());
getSceneData()->accept(updateVisitor);
}
if (getDatabasePager())
{
// synchronize changes required by the DatabasePager thread to the scene graph
getDatabasePager()->updateSceneGraph((*updateVisitor.getFrameStamp()));
}
to
if (getDatabasePager())
{
// synchronize changes required by the DatabasePager thread to the scene graph
getDatabasePager()->updateSceneGraph((*updateVisitor.getFrameStamp()));
}
if (getSceneData())
{
updateVisitor.setImageRequestHandler(getImagePager());
getSceneData()->accept(updateVisitor);
}
That is, just swap the positions of two 'if () {...}' segments.
While working on a paged terrain, I need to collect every newly allocated PagedLODs and make them temporarily unrenderable in the next frame, which are all done in a update callback. But I found that these PagedLODs will always be shown before collecting them, because of the unsuitable sequence in Scene::updateSceneGraph(). DatabasePager is synchronized AFTER the user updating traversal, that is, user cannot IMMEDIATELY find out changes made by DatabasePager.
"
For example, when running FlightGear, I want the window to always have no title, so it opens full-screen without using the --full-screen option, which would prevent other windows from moving above the osg window.
I am attaching a patch I made to fix this problem."
The modification consists only in including osgGA::GUIEventAdapter::DOUBLECLICK in the list of "pointerEvent" events.
Test done to reproduce the problem and check the fix: in any osg application or example with an HandleInput function, break on events with a double-click event type. Without the changes, the event's buttonMask does not contain the double-clicked button. With the changes, it does.
Only simple tests (running some examples and playing with the mouse) were done to check that the changes do not break anything, since double-click is not used thoroughly in OSG.
Modification done against current SVN Trunk version (r10753).
As this is a fix, I do not wish to keep my copyright on this submission and assign it over to the project lead.
"
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.
"
Moved the handling of DisplaySettings into Traits constructor.
Added support for s/getGLContextVersion(), s/getGLContextFlags() and s/getGLContextProfileMask() to osg::DisplaySettings.
Added command line and env var support for setting the GLContextVersion, GLContextFlags and GLContextProfileMask to osg::DisplaySettings.
GraphicsWindowCocoa-implementation, which enhances multithreaded
stability, it ensures that modifications to the size of an openglcontext
is done only from one thread.
"
Therefore I have changed all the occurances of atof by asciiToFloat or
asciiToDouble.
I believe that it is safe to do so at least for all the plugins.
Included here are also asciiToFloat conversion of environment variables. One
might argue that these should be locale dependent. But IMO these should be
set and interpreted by osg independent of the current locale.
"
proper functioning when running the osgViewer run-loop in a secondary
thread (e.g. when embedding GraphicsWindowCocoa-windows in a full blown
cocoa application).
OS X is picky when you want to change the user-interface from another
thread than the main thread, not all UI stuff is thread-safe. So now
window closes and showing / hiding the menu bar is done in the main
thread via Cocoa's performSelectorOnMainThread-mechanism.
These changes don't affect the normal osgViewer usage pattern."
First Submission email from Gustav:
"This submission adds a --cache option to osgconv and osgviewer that enables setObjectCacheHint(osgDB::Options::CACHE_ALL); It greatly reduces memory usage when a .osg file has lots of external references with ProxyNode:s that points to the same file.
Options are also added to the osg plugin. The code was already mostly implemented but there was no way to change the options.
includeExternalReferences
writeExternalReferenceFiles
A counter is added to keep track if an external file has already been written down to avoid writing the same file over and over again. If it has already been written once then it is not written again.
The counter is added to the Output class in osgDB.
"
Second Submission email from Gustav:
"This is a continuation to my previous submission.
I noticed that the same problem that I fixed in ProxyNode.cpp for the osg plugin (external files being written over and over again) also existed in the ive plugin. I attached a submission where the ive plugin remembers which external files that have already been written and do not write them again."
Changes to the above done by Robert Osfield,
changed command line parameter to --enable-object-cache
changed set/get methods in osgDB::Output and ive/DataOutputStream.cpp to be s/getExternalFileWritten(const std::string&)
cleaned up set up of osgDB::Options.
of these methods in src/osgViewer/Renderer.cpp to make sure that the draw thread keeps references to all in scene graph Cameras
that are being used by the drawing threads, to keep the Camera's alive even when the main thread removes these Cameras from the scene graph.
