Re: [osg-users] Generating multitouch events
Hi. Just to make sure I understand the structure of the current osgGA multi-touch support... If I have a touch system that collects touch events in a callback, in my case TUIO events, I will likely need to use a timer to store up a bunch of events, bundle them into a single GUIEventAdapter, and then send them into the EventQueue, correct? In my case I have a home-made touch surface that detects finger presses and creates a listener thread for individual TUIO events. So far I've written a conversion class that can handle single touches fine, but won't work for multiple touches. Thanks for the clarification. -Len -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44388#44388 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] [build] building osgAndroidExampleGLES* on Ubuntu 10.04 with android-ndk-r7
I followed the instructions on the wiki for building the android osg examples, but with ndk7 I kept getting linker errors for anything in libstdc++ until I added another libdir (android-ndk/sources/cxx-stl/gnu-libstdc++/libs/armeabi) to the linker flags. Is this a known problem / is this the correct solution / should this fix go into trunk? See the diff to Android.mk below: Code: Index: jni/Android.mk === --- jni/Android.mk (revision 12892) +++ jni/Android.mk (working copy) @@ -4,7 +4,7 @@ LOCAL_MODULE:= osgNativeLib ### Main Install dir -OSG_ANDROID_DIR:= type your install directory +OSG_ANDROID_DIR:= /home/jbohren/source/OpenSceneGraph LIBDIR := $(OSG_ANDROID_DIR)/obj/local/armeabi ifeq ($(TARGET_ARCH_ABI),armeabi-v7a) @@ -62,6 +62,7 @@ -losgAnimation \ -losgUtil \ -losg \ --lOpenThreads +-lOpenThreads\ +-L/usr/local/android/android-ndk/sources/cxx-stl/gnu-libstdc++/libs/armeabi include $(BUILD_SHARED_LIBRARY) Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44414#44414 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting OpenGL state manually then rendering via OSG
Hi, I'm a little stuck on solving an issue related to integrating a standalone OpenGL-based API with a simple OSG demo. The OpenGL library sets some states in the background, specifically: framebuffer object, multisampling, stencil tests, scissor tests and viewport settings. How do I tell OSG to use these default settings when it runs? The OpenGL library essentially dictates to my application N view points to render the scene from, so it passes back to me projection and modelview matrices and assumes that I don't change certain states after that point (which include the ones I described above). After I pass the matrices to the current Camera class object, how/where would I tell OSG not to change the bound framebuffer, mess with enabling/disabling multisampling, and the other OpenGL states I mentioned? I've read that you can integrate OSG into an existing OpenGL application that creates its own window and sets state, but I can't seem to find an example to show me how to do what I need. Thank you! Cheers, Sean -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44482#44482 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Writing to the Depth Buffer (Kinect)
Hi, I am working on an augmented reality project using the Kinect. I am trying to occlude geometry based on the depth image produced by Kinect. To do this I thought I'd write the depth image (after scaling the depth values appropriately) to the depth buffer. It looks as though I'd use glDrawPixels() with GL_DEPTH_COMPONENT if I was doing it in OpenGL, but how do I achieve this in OSG? I'm also open to a better way of using the Kinect to occlude geometry if anyone has any ideas. Cheers, Sam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44352#44352 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Writing to the Depth Buffer (Kinect)
On 12/12/2011 3:35 PM, Sam Corbett-Davies wrote: I am working on an augmented reality project using the Kinect. I am trying to occlude geometry based on the depth image produced by Kinect. To do this I thought I'd write the depth image (after scaling the depth values appropriately) to the depth buffer. It looks as though I'd use glDrawPixels() with GL_DEPTH_COMPONENT if I was doing it in OpenGL, but how do I achieve this in OSG? You would use osg::DrawPixels. See the osg/DrawPixels header file. You might get better performance by converting the depth data from the Kinect into a texture map. glDrawPixels() will do the same thing for you, but you can almost always do a better job with your own code. (Performance might not be your major concern anyhow, as you will almost certainly be bottlenecked by reading data from the Kinect.) If you want to use texture mapping, the method is straightforward. Mask off the color buffer, then draw a full screen quad (triangle pair). Assign a fragment shader to the quad StateSet. The fragment shader would simply look up depth values from the texture and set gl_FragDepth from those values. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting OpenGL state manually then rendering via OSG
Required background reading for this topic comes from a June 16 2010 post by Tim Moore with subject line: articles on StateSet, State, and StateGraph. Check out these two URLs: http://www.bricoworks.com/articles/stateset/stateset.html http://www.bricoworks.com/articles/stategraph/stategraph.html That might not answer your questions, but it's required reading and quite informative. I'd also advise you to review the RenderStage.cpp source code, which is where OSG sets much of the state that you're concerned with. -Paul On 12/27/2011 10:06 AM, Sean O'Connell wrote: Hi, I'm a little stuck on solving an issue related to integrating a standalone OpenGL-based API with a simple OSG demo. The OpenGL library sets some states in the background, specifically: framebuffer object, multisampling, stencil tests, scissor tests and viewport settings. How do I tell OSG to use these default settings when it runs? The OpenGL library essentially dictates to my application N view points to render the scene from, so it passes back to me projection and modelview matrices and assumes that I don't change certain states after that point (which include the ones I described above). After I pass the matrices to the current Camera class object, how/where would I tell OSG not to change the bound framebuffer, mess with enabling/disabling multisampling, and the other OpenGL states I mentioned? I've read that you can integrate OSG into an existing OpenGL application that creates its own window and sets state, but I can't seem to find an example to show me how to do what I need. Thank you! Cheers, Sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Issues when creating seamless panorama using multiple cameras with arbitrary FOVs
Hi all, I'm (very) new to OSG, though do have some prior graphics experience (which could use brushing up, I'll admit). However, I just can't seem to determine the best solution to this problem. I'm working on an application where, in one window, an aircraft HUD view is being rendered. Originally, a single osg::Viewer with one camera was being used, which works fine. However, I'm trying to implement what are essentially peripheral views which are rendered to the same viewport as the same view, on the left and right sides (I'm not using a single camera as these peripheral views will be compressed horizontally and will allow the user to set an arbitrary FOV for these views, stretching up to 180 degrees across all three views). There is no issue with this part, per se - the problem arises from the fact that there are jarring issues at the seams between viewports. Objects which are partially drawn on each viewport have slight, though very clear, slight issues in offset and scale, such that when they're crossing the boundary, scale and immersion is broken. I've attempted two solutions to compare them. Currently, all views have the same field of view and are drawn with equal size in the viewport. In one method, I add two slave cameras to the viewer, which has its rotation set via a manipulator (this was the implementation before I started the project) with a view offset rotation of +/- main camera's horizontal field of view about the Y-axis (gained by multiplying the vertical FOV by the aspect ratio, all retrieved via getProjectionMatrixAsPerspective()) passed in as an argument. From my understanding, as the main camera's view matrix is post-multiplied by the slave's offset to get the final slave view matrix, this should be a rotation about the local axis and give the correct result. In fact, in this case, not only is there a slight scale/position issue, but there are odd issues with the angle of the horizon getting slightly more off as the roll increases (though the rotation itself seems to be about the correct axis, and tests with other axes are proven to be definitely incorrect). I've used both matrix and quaternion rotations in case there are precision/accuracy differences with no change in results. I've taken a look at setUpViewFor3DSphericalDisplay() which seems to use a very similar method (though I don't quite get the rotation about the Z-axis). In my other (naive, first) implementation, I use a composite viewer with three identical cameras each with their own manipulator, set each to identical rotations each frame, and calculate pitch and azimuth offsets for the peripheral views based on the aircraft roll which is also calculated each frame. This actually seems to work better than the single viewer solution, but is not what I want and certainly doesn't seem to be the correct solution. I'll add code if/when I can (need to clean it up quite a bit, as I've tried this about twenty different ways) and will add information as often as I can. Thanks for any help you can give! -Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44488#44488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PowerVR OpenGL ES on Linux
On Fri, Dec 23, 2011 at 11:21:37AM -0700, Chris 'Xenon' Hanson wrote:
Trying to run OSG/osgviewer (and the GLES2 osgvertexattributes test
program) on Linux,
under Ubuntu with the PowerVR emulator.
It's not clear why eglChooseConfig is failing.
This post:
http://www.imgtec.com/forum/forum_posts.asp?TID=1378
The Nokia N900 (Maemo Linux) has a PowerVR and I had to make some
changes for it to get to initialize OpenGL ES there. At one point in
time I had the hang glider up. I included the patches related to
GraphicsWindowX11.cpp and skipped the rest. I haven't looked at them
in a while, so I'm not sure exactly what the status of them is. I
don't expect some of them to make any difference for you, like the one
preventing osgviewer from going full screen or the one relating to
input, I just included them in case the later patches failed without
them applied. You might not apply the last patch, it might work
better without it. These are off svn revision 12737.
Please Cc: me on any replies.
--
David Fries da...@fries.netPGP pub CB1EE8F0
http://fries.net/~david/
From a6699b411eccca28bbe497d690fc4dca26c4f60d Mon Sep 17 00:00:00 2001
From: David Fries da...@fries.net
Date: Fri, 22 Jan 2010 12:16:42 -0600
Subject: [PATCH 08/23] osgviewer changes to not go full screen
It is very annoying for it to startup full screen and when you resize
it doesn't add the window handles.
---
include/osgViewer/Viewer|2 +-
src/osgViewer/GraphicsWindowX11.cpp | 20 ++--
src/osgViewer/Viewer.cpp| 14 --
src/osgViewer/ViewerBase.cpp|7 ---
4 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/include/osgViewer/Viewer b/include/osgViewer/Viewer
index 998e249..6b46efd 100644
--- a/include/osgViewer/Viewer
+++ b/include/osgViewer/Viewer
@@ -120,8 +120,8 @@ class OSGVIEWER_EXPORT Viewer : public ViewerBase, public osgViewer::View
virtual void viewerInit() { init(); }
osg::observer_ptrosg::Camera _cameraWithFocus;
-
+bool _grabFocus;
};
diff --git a/src/osgViewer/GraphicsWindowX11.cpp b/src/osgViewer/GraphicsWindowX11.cpp
index d9eef95..c46e483 100644
--- a/src/osgViewer/GraphicsWindowX11.cpp
+++ b/src/osgViewer/GraphicsWindowX11.cpp
@@ -485,7 +485,11 @@ bool GraphicsWindowX11::setWindowRectangleImplementation(int x, int y, int width
checkAndSendEventFullScreenIfNeeded(display, x, y, width, height, _traits-windowDecoration);
-XMoveResizeWindow(display, _window, x, y, width, height);
+// Let the window manager specify the position if x and y are -1.
+if(x==-1 y==-1)
+XResizeWindow(display, _window, width, height);
+else
+XMoveResizeWindow(display, _window, x, y, width, height);
XFlush(display);
XSync(display, 0);
@@ -911,6 +915,16 @@ bool GraphicsWindowX11::createWindow()
}
}
+// How do you specify the window settings on startup? Hack it for now.
+if(_traits-x == 0 _traits-y == 0
+ _traits-width == 3200 _traits-height == 1200)
+{
+ _traits-x = -1;
+ _traits-y = -1;
+ _traits-width = 320;
+ _traits-height = 200;
+}
+
_window = XCreateWindow( _display, _parent,
x,
y,
@@ -937,7 +951,9 @@ bool GraphicsWindowX11::createWindow()
sh.flags = 0;
sh.flags |= USSize;
sh.flags = 0x7;
-sh.flags |= USPosition;
+// Let the window manager specify the position if x and y are -1.
+if(_traits-x!=-1 || _traits-y!=-1)
+sh.flags |= USPosition;
sh.flags = 0xB;
sh.x = _traits-x;
sh.y = _traits-y;
diff --git a/src/osgViewer/Viewer.cpp b/src/osgViewer/Viewer.cpp
index 7469268..7ce47ed 100644
--- a/src/osgViewer/Viewer.cpp
+++ b/src/osgViewer/Viewer.cpp
@@ -34,6 +34,7 @@ using namespace osgViewer;
Viewer::Viewer()
{
_viewerBase = this;
+_grabFocus = false;
constructorInit();
}
@@ -41,6 +42,7 @@ Viewer::Viewer()
Viewer::Viewer(osg::ArgumentParser arguments)
{
_viewerBase = this;
+_grabFocus = false;
constructorInit();
@@ -121,6 +123,15 @@ Viewer::Viewer(osg::ArgumentParser arguments)
int x = -1, y = -1, width = -1, height = -1;
while (arguments.read(--window,x,y,width,height)) {}
+
+if(const char *ptr = getenv(OSG_GRAB))
+{
+if(!strcmp(ptr, OFF))
+_grabFocus=false;
+else if(!strcmp(ptr, ON))
+_grabFocus=true;
+}
+while (arguments.read(--grab)) { _grabFocus=true; }
bool ss3d = false;
bool wowvx20 = false;
@@ -519,8 +530,7 @@ void Viewer::realize()
// attach contexts to _incrementalCompileOperation if attached.
if (_incrementalCompileOperation) _incrementalCompileOperation-assignContexts(contexts);
-bool grabFocus = true;
-if (grabFocus)
+if (_grabFocus)
{
for(Contexts::iterator citr = contexts.begin();
citr
