[osg-users] Retrieve Wold matrix while animating
Hello. I try to create a multi pass algorithm and i am stuck. I use my own view and projection matrix for an absoluted positioned camera. But i cant figure out how to handle the World matrix. Glsl gives me gl_ModelViewMatrix but i need only the model matrix for the current vertex being processed. How can i retrieve it in osg and pass it in the shader as uniform ? thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lock the aspect ratio while allowing the window to be resized
Hi Ethan, I think this should do the trick: camera-setProjectionResizePolicy(osg::Camera::FIXED); Laurens. On 1/21/2013 4:14 PM, Ethan Fahy wrote: Hello, Is there any way to set up an osgViewer::Viewer with a locked aspect ratio that still allows the user to adjust the window size by dragging the bottom-right corner of the view window? Thanks, -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52054#52054 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OS/X 10.6.8 with CMake 2.8.8 broken
Hi Adrian, I used 10.8/7 and have same issue like you. I added something like that: set(CMAKE_OSX_DEPLOYMENT_TARGET 10.7) set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk CACHE STRING FORCE) Cheers, Remo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52063#52063 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Retrieve Wold matrix while animating
Hi most straightforward way is to use gl_ModelViewMatrix * osg_ViewMatrixInverse Cheers. 22.01.2013, 13:16, Peterakos hay...@gmail.com: Hello. I try to create a multi pass algorithm and i am stuck. I use my own view and projection matrix for an absoluted positioned camera. But i cant figure out how to handle the World matrix. Glsl gives me gl_ModelViewMatrix but i need only the model matrix for the current vertex being processed. How can i retrieve it in osg and pass it in the shader as uniform ? thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to extend my screen space handling to z-direction?
Hi osg-community,
I am working on a stereoscopic renderer which can receive mouse and
on-screen-touch-events to handle translations of the scene. Now I want to
extend this to handle gestures of the Xbox-Kinect camera. I already got it
working for the x and y on-screen translation. Unfortunatly I don't know how to
handle movements of the z-direction (towards/into the screen). I already ensure
that my coordinates from my kinect-camera are scaled from -1 to 1 for all
directions.
Here is the code that is already working for X and Y directions. I have tried
to extend (commented out) it for the Z direction but couldn't get it to work.
Maybe someone has any idea how to do it. My implementation for the z-direction
was a complete guess, so it is possible that I am way off.
Code:
double dist = opencover::cover-getViewerScreenDistance();
//
// The center is (0.5, 0.5) only if the viewer position is exactly in the
middle
// of the screen
// On the table, we are way more nearer to the bottom, thus, the center is
calculated
// dynamically. This way, head-tracking is possible
//
double horzFrustum = this-frustum.right + fabsf(this-frustum.left );
double vertFrustum = this-frustum.top + fabsf(this-frustum.bottom);
//double forwardFrustum = fabsf(this-frustum.zfar) +
fabsf(this-frustum.znear);
//
// For stereo, we are interacting on the screen surface and not on the near
plane,
// thus calculate the motion on the surface
//
double surfaceRight = (horzFrustum / 2.0f) * dist / this-frustum.znear;
double surfaceTop = (vertFrustum / 2.0f) * dist / this-frustum.znear;
//double surfaceFar = (forwardFrustum / 2.0f) * dist /
this-frustum.znear;
double screenCenterX = this-frustum.right / horzFrustum;
double screenCenterY = this-frustum.top / vertFrustum;
//double screenCenterZ = this-frustum.zfar / forwardFrustum;
//
// Compute x0 and y0 in world coords using the theorem on intersecting lines
//
double x0 = (cur.down.x() - screenCenterX) * 2.0 * surfaceRight;
double y0 = (cur.down.y() - screenCenterY) * 2.0 * surfaceTop;
//double z0 = (cur.down.z() - screenCenterZ) * 2.0 * surfaceFar;
//
// Compute xc and yc in world coords using the theorem on intersecting lines
//
double xc = (cur.curr.x() - screenCenterX) * 2.0 * surfaceRight;
double yc = (cur.curr.y() - screenCenterY) * 2.0 * surfaceTop;
//double zc = (cur.curr.z() - screenCenterZ) * 2.0 * surfaceFar;
//
// Compute translation
//
osg::Vec3 direction = Vec3(xc-x0, zc-z0, yc-y0);
//
// Get the viewer position
//
osg::Vec3 viewerPosition = opencover::cover-getViewerMat().getTrans();
//
// Compute new transform matrix
//
osg::Matrix transform =
this-rootTransform
* osg::Matrix::translate(-viewerPosition)
* osg::Matrix::translate(direction)
* osg::Matrix::translate(viewerPosition);
//
// Apply the new transformation matrix -- if it's valid
//
if (transform.valid())
{
opencover::VRSceneGraph::instance()-getTransform()-setMatrix(transform);
}
variable cur.down is where the cursor of mouse started clicking / touch on
the screen first appeared / kinect started captureing the skeleton
variable cur.curr is the current position of the corresponding cursor
(mouse/touch/kinect).
I hope someone can help!
Thank you!
Cheers,
Charma
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52065#52065
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lock the aspect ratio while allowing the window to be resized
Hi Laurens, I tried setting the resize policy as you suggested for the osgViewer::Viewer default camera as well as the rtt camera and hud camera that are in my project, but I was still able to freely resize my viewer window without it locking. I didn't get any errors, it just didn't lock the window size. Perhaps there is a difference between projection size and window size. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52066#52066 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in osgGA::GUIEventHandler in OSG 3.0.1 release (fixed in current trunk).
Hi guys, Our software uses OSG for displaying a modelview for our muscular-skeletal simulation software. In our latest beta-version we have switched to OSG 3.0.1, but we just yesterday found a bug related to osgGA::GUIEventHandler, which we use for handling mouse events in our modelview. If we create a new OSG graph but keep the drawing context, the osgGA::GUIEventHandler for the view would sometimes not receive the usual (MOVE, MOVE, ..., MOVE, MOVE, PUSH, RELEASE, FRAME) sequence of osgGA::GUIEventAdapter's when pressing a mousebutton in the view. If the modelview was left open for a period of time (tens of seconds to minutes), the next mousebutton push would trigger and send any saved up event to the GUIEventHandler. We previously used OSG 2.9.11, where this issue doesn't seem to occur, and I have just tested our software with a fresh OSG 3.1.4 built from svn trunk, and it also seems to work correctly. My question is if this is a known bug from the OSG release version which has been fixed, and if there's any plan for either a new official release version of OSG or at least a developer release in the short term future (1-2 months)? Best regards, and thanks Jesper D. Thomsen AnyBody Technology ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in osgGA::GUIEventHandler in OSG 3.0.1 release (fixed in current trunk).
Hi Jesper, I'm just wrapping up some work and plan to make a developer release this week. I don't have an schedule for the next stable release, but would like to get one out in the next few months. Robert. On 22 January 2013 14:32, Jesper D. Thomsen j...@anybodytech.com wrote: Hi guys, Our software uses OSG for displaying a modelview for our muscular-skeletal simulation software. In our latest beta-version we have switched to OSG 3.0.1, but we just yesterday found a bug related to osgGA::GUIEventHandler, which we use for handling mouse events in our modelview. If we create a new OSG graph but keep the drawing context, the osgGA::GUIEventHandler for the view would sometimes not receive the usual (MOVE, MOVE, …, MOVE, MOVE, PUSH, RELEASE, FRAME) sequence of osgGA::GUIEventAdapter’s when pressing a mousebutton in the view. If the modelview was left open for a period of time (tens of seconds to minutes), the next mousebutton push would trigger and send any “saved up” event to the GUIEventHandler. We previously used OSG 2.9.11, where this issue doesn’t seem to occur, and I have just tested our software with a fresh OSG 3.1.4 built from svn trunk, and it also seems to work correctly. My question is if this is a known bug from the OSG release version which has been fixed, and if there’s any plan for either a new official release version of OSG or at least a developer release in the short term future (1-2 months)? Best regards, and thanks Jesper D. Thomsen AnyBody Technology ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lock the aspect ratio while allowing the window to be resized
My last question was pretty naive after doing a bit of google searching. The osg window is OS-dependent and appears to be completely separate from the projection matrix. I think I'll worry about getting the projection matrix set correctly first then worry about making sure that the view window matches the aspect ratio of that projection matrix regardless of resizing events. I'll also need to make sure that the window view isn't stretched. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52070#52070 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lock the aspect ratio while allowing the window to be resized
Hi Ethan, I did not understand your question correctly. Setting the camera to camera-setProjectionResizePolicy(osg::Camera::FIXED) will fix the projection, not the window. As the version you want is not implemented in osg, you will need to catch resize attempts and force the window to resize while preserving the aspect ratio. the osgviewer application has a viewer.addEventHandler(new osgViewer::WindowSizeHandler); You probably should replace that with a new handler, allowing only to resize with fixed aspect ratio. Laurens. On 1/22/2013 2:10 PM, Ethan Fahy wrote: Hi Laurens, I tried setting the resize policy as you suggested for the osgViewer::Viewer default camera as well as the rtt camera and hud camera that are in my project, but I was still able to freely resize my viewer window without it locking. I didn't get any errors, it just didn't lock the window size. Perhaps there is a difference between projection size and window size. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52066#52066 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifier key mask not working under OS X
Hi François, I don't have an Mac or OSX expertise to help with this particular issue, I'll have to defer to others with relevant systems and expertise. One thing I'd add is that it would checking to see how the osgkeyboard runs on your system, and also could you tell us whether you've built using Carbon or Cocoa? The later is now the preferred option. Resolution of this issue will have to be down to member of the OSG community that have OSX expertise, hopefully they will chime in with this thread. Robert. On 15 January 2013 14:53, François Génolini fgenol...@hotmail.com wrote: I have just checked out OpenSceneGraph trunk and built it on my mac. osgversion: OpenSceneGraph Library 3.1.4 uname -a: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 XCode: Version 4.5.2 (4G2008a) I am trying to get some software working: chapter 2 example from the OpenSceneGraph 3 cookbook (http://www.packtpub.com/openscenegrap-3-for-advanced-3d-programming-using-api-cookbook/book). In this example, I cannot pick the sphere or the cube as long as the code expects to see modifierKeyMask osgGA::GUIEventAdapter::MODKEY_CTRL If I remove this condition (any left mouse click allows the method to continue), then the software works as designed. Neither Control (left / right) nor Alt modifiers (left / right) are reported. Shift (left / right) and Command (left / right) are reported. Key combinations (Shift + Control) are not reported (even though, on its own, Shift is reported). Here is a reference to an old discussion on the mailing list: [osg-users] Modifier key mask not working under OS X, by Adrian Egli OpenSceneGraph (3D) 3dhelp at gmail.com, dated Thu Feb 21 22:23:05 PST 2008 This is either a bug that was never fixed or a regression. What would be the way forward to address this? Regards, François Génolini ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lock the aspect ratio while allowing the window to be resized
I also misunderstood the question. Apparently, you want to allow the window to be resized, but only in such a way that the window's aspect ratio is always the same. This really has little to do with OSG (except that you might use an osgGA event handler to capture the resize events and do the appropriate thing). And you're right, the projection matrix is independent of the window, so you should not need to change the projection matrix at all. -Paul On 1/22/2013 8:22 AM, Laurens Voerman wrote: Hi Ethan, I did not understand your question correctly. Setting the camera to camera-setProjectionResizePolicy(osg::Camera::FIXED) will fix the projection, not the window. As the version you want is not implemented in osg, you will need to catch resize attempts and force the window to resize while preserving the aspect ratio. the osgviewer application has a viewer.addEventHandler(new osgViewer::WindowSizeHandler); You probably should replace that with a new handler, allowing only to resize with fixed aspect ratio. Laurens. On 1/22/2013 2:10 PM, Ethan Fahy wrote: Hi Laurens, I tried setting the resize policy as you suggested for the osgViewer::Viewer default camera as well as the rtt camera and hud camera that are in my project, but I was still able to freely resize my viewer window without it locking. I didn't get any errors, it just didn't lock the window size. Perhaps there is a difference between projection size and window size. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52066#52066 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Most efficient way to get a single pixel RGBA from an FBO texture
Hello, I have an rtt camera that renders float32 values to an FBO. I use osgCompute to process this FBO and output to the screen without copying anything back to CPU memory. I would like to add a HUD that shows the float32 value at the center of the FBO texture (if there are an odd number of pixels in the x and y direction then use the exact center, if even then round down to the nearest pixel to the center, accuracy isn't too important). If I wanted the entire FBO contents I believe I'd have to create an osg::Image and attach the FBO to that image such that the entire contents of the FBO texture would be copied from GPU to CPU memory every frame. Since I only need the center pixel this seems wasteful, but I can't think of any way to access the contents of the FBO texture without writing the whole thing back to CPU memory. Anyone have any tips on this? I've seen other posts that were related to this but none that had a satisfying solution. Thanks, and if I'm mangling the term inology feel free to set me straight since a lot the terms I just used are relatively new to me. -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52076#52076 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifier key mask not working under OS X
Hi, Configured CMake to target Xcode, cmake automatically selected OSG_WINDOWING_SYSTEM to be Cocoa and CMAKE_OSX_ARCHITECTURES is set to x86_64. This pretty much excludes legacy Carbon (although cmake does find CARBON_LIBRARY). OSG libs then built using the XCode GUI. Reading the various forums it looks like the OSX event handler combines CTRL+left-mouse-click at a low level and replaces it with right-mouse-click, a throwback of the traditional Apple single-button mouse. I have not yet read about the ALT+left-mouse-click combination, and why CTRL+SHIFT+left-mouse-click is not reported either. ... Thank you! Cheers, Francois -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52079#52079 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VBO as default
I don't think this has been asked in a while. Is it time to switch Drawables to use VBOs instead of Display Lists by default? I *always* switch it manually, except for a couple exceptional situations. I think VBOs are at least as fast as Display Lists and sometimes much faster on modern hardware. Would this cause a lot of trouble? -- Terry Welsh www.reallyslick.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
