Re: [osg-users] Question about osgViewer::View::EventHandlers
Hi Martin, On Tue, Mar 9, 2010 at 7:22 PM, Martin Beckett m...@mgbeckett.com wrote: On this topic, is there a way of having an eventHandler remove itself? I want a one-shot selection of a point. I can't call removeHandler(this) inside the handler and there is no callback function I can pass to the handler to be triggered when handle() returns true. Any suggestions? You'll need to do the call to remove the event handler from outside the Viewer::eventTraversal() by adding some kind of removal code into the frame loop, or create custom osg::Operation for doing th removal and add this to the viewer via viewer.addUpdateOperation(); You can set up osg::Operation so that they themselves are automatically removed after they have been run. Or... just don't use an event handler, just have you own custom event handling code in your frame loop in addition to the Viewer::eventTraversals(); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Display from buffer
Hi, For displaying any .jpg/.tif file, we create texture and then doing so. Using OSG how to display pixels from a buffer straightaway as it could be done using openGL? Is it possible to by-pass osgDB::readImageFile(..) to read image content from buffer instead of from file? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25439#25439 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Display from buffer
Hi, you can make an osg::Image and point it to existing data in memory. See the setImage function of osg::Image. You need to pass the right pixel format params etc. Also search the mail archives for setImage. jp Akilan Thangamani wrote: Hi, For displaying any .jpg/.tif file, we create texture and then doing so. Using OSG how to display pixels from a buffer straightaway as it could be done using openGL? Is it possible to by-pass osgDB::readImageFile(..) to read image content from buffer instead of from file? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25439#25439 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
Hi Paul, Am 10.03.10 03:25, schrieb Paul Martz: * Anyone out there with Mac OS X experience? Specific things I'd like assistance with would be: - Input on which svn revisions are required to enable support for Mac OS X 10.6. The goal is to be able to build OSG 2.8.3 against the 10.6 SDK. For 10.6 and specifically 64bit you'll need the imageio-plugin, the new cocoa graphicswindow-implementation and the refactored os x specific files (DarwinUtils etc) and the adapted cmakefiles. The cocoa backend is not 10.6 specific, so it can be tested with 10.4 or 10.5 for osgviewer (graphicswindowcarbon/cocoa, pixelbuffercarbon/cocoa, darwinutils.h/.mm) : rev 10887 for the imageio-plugin: 10885 for the quicktime-plugin? i am not sure, i would stick with the latest rev. - Somebody with a Mac that already has 10.6, for testing. I have 10.5 but can upgrade if no one else steps forward. I can do some automated compile-tests on a 10.6 machine here. - An Xcode expert to create appropriate Xcode files for the 2.8.3 release (needs to work with the osgAnimation backport). I'll try to update the xcode-projects, but it will get messy and hairy. And this needs a lot of testing. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Could not find plugin on Mac OS X 10.6.2
Hi Chuck et. al, On Tue, Mar 9, 2010 at 10:06 PM, Chuck Seberino seber...@energid.orgwrote: How about something like: #First check to see if we are running with a native 64-bit compiler (10.6 default) and implicit arch if(NOT CMAKE_OSX_ARCHITECTURES AND CMAKE_SIZEOF_VOID_P EQUAL 8) set(QUICKTIME_FOUND OFF) else() #Otherwise check to see if 64-bit is explicitly called for. list(FIND CMAKE_OSX_ARCHITECTURES x86_64 has64Compile) if(NOT has64Compile EQUAL -1) set(QUICKTIME_FOUND OFF) endif() endif() I can't say whether it'll work or not as I don't have an OSX box to play on but it looks like it might work. To get the ball rolling I've added the following to the end of FindQuickTime.cmake: SET(QUICKTIME_FOUND NO) IF(QUICKTIME_LIBRARY AND QUICKTIME_INCLUDE_DIR) SET(QUICKTIME_FOUND YES) ENDIF() IF(APPLE) #Quicktime is not supported under 64bit OSX build so we need to detect it and disable it. #First check to see if we are running with a native 64-bit compiler (10.6 default) and implicit arch IF(NOT CMAKE_OSX_ARCHITECTURES AND CMAKE_SIZEOF_VOID_P EQUAL 8) SET(QUICKTIME_FOUND NO) ELSE() #Otherwise check to see if 64-bit is explicitly called for. LIST(FIND CMAKE_OSX_ARCHITECTURES x86_64 has64Compile) IF(NOT has64Compile EQUAL -1) SET(QUICKTIME_FOUND NO) ENDIF() ENDIF() ENDIF() The only changes I made were to make the things a bit more consistent style wise with the rest of the FindQuickTime.cmake. I've attached the modified FindQuickTime.cmake and also checked it into svn/trunk. If it's not quite right then we can tweak it. I'm about to check in Nico + Jordi's changes to OpenSceneGraph/CMakeLists.txt for detecting the 10.6 SDK, so all these changes together should hopefully help the OSX build along. Could OSX users try out the latest in svn/trunk? Thanks, Robert. FindQuickTime.cmake Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems about layer rendering
Hi Kai,
Disclaimer: I have not done anything like this. I did think about
implementing such technique, though. And I am deeply interested in the
results You could get. So I will try to provide few unproven suggestions in
hope you will share them later ;-)
1. The way you attach texture layers will not work. This way you will have
only one buffer active. Camera::atach in your usage scenario cause OSG to
set up FBO using
glFramebufferTextureLayer( GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT,
your_tex_array_gl_id, 0, layer ). Layer in this context does not define
FRAMEBUFFER layer but layer of texture 2D array. Effectively you call attach
3 times but two first calls are overriden with third so finally your three
calls:
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 0); //
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 1);
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 2);
are effectively equal to last one:
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 2);
I guess you may want to replace it with following three calls:
shadowCamera-attach(osg::Camera::COLOR_BUFFER0, ta, 0, 0);
shadowCamera-attach(osg::Camera::COLOR_BUFFER1, ta, 0, 1);
shadowCamera-attach(osg::Camera::COLOR_BUFFER2, ta, 0, 2);
this will set up multiple render targets with 3 independent color buffers.
However, I am not sure if this will propely work with gl_Layer produced in
Geometry shader. These OpenGL examples I saw usually set up layered
framebuffer rendering with one glFramebufferTexture call. For example see
this link (its sample code to render 6 faces of cubemap simultaneously)
http://pastie.org/796448: However, this brings another problem:
glFramebufferTexture functinality is not used by OSG yet.
2. Even assuming that you may set each layer as multiple render targets
using above suggestion I see another problem: Shadow maps are generated into
depth maps and hence you should rather set up DEPTH_BUFFERS insted of
COLOR_BUFFERS . I am not sure if support for multiple depth buffer targets
is already available for OpenGL (I know its present in recent Direct3D). You
will have to check it. But even if its available in OpenGL its not yet
supported by OSG.
3. On few forums I saw that people trying to set similar up rendering were
able to get it to work on COLOR_BUFFERS but even then only one DEPTH_BUFFER
layer was used. It looked like bugs in the drivers.
So the prospects are not too bright. I looks like you need to modify OSG FBO
code to get what your are after. I have no idea, how deep these
modifications should be
In one of my concepts, instead of depth buffers I was considering using one
32 floating point color buffer (each channel would represent one depth
layer) with BlendEquation set to RGBA_MIN. This way one could effectively
replicate depth buffer behaviour with color buffer. Early Z -test is gone
though
Dont forget to post your results ;-)
Cheers,
Wojtek Lewandowski
- Original Message -
From: Kai Xia k_...@hotmail.com
To: osg-users@lists.openscenegraph.org
Sent: Monday, March 08, 2010 9:01 AM
Subject: [osg-users] problems about layer rendering
Hi,
I have some problems while using geometry shader and TextureArray to
optimize PSSM shadow, the test code is like following:
C++ code:
osg::TextureArray *ta = new osg::TextureArray;
ta-setTextureSize(1024, 1024, 3); //3 layer texture
...
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 0); //
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 1);
shadowCamera-attach(osg::Camera::COLOR_BUFFER, ta, 0, 2);
Geometry shader code:
#extension GL_EXT_geometry_shader4 : require
varying vec4 color;
void main()
{
//Route to Layer 0
for (int i = 0; i 3; i++)
{
// You will recieve 3 positions since we set the input type to
Triangles
gl_Position = 0.5*gl_PositionIn[i] - vec4(0.5, 0.0, 0.0, 1.0);
gl_FrontColor = vec4(1.0, 0.0, 0.0,1.0);
gl_Layer = 0;
EmitVertex();
}
EndPrimitive();
//Route to Layer 1
for (int i = 0; i 3; i++)
{
gl_Position = 0.5*gl_PositionIn[i];
//Just to see a difference in Layer 1
gl_FrontColor = vec4(0.0, 1.0, 0.0,1.0);
gl_Layer = 1;
EmitVertex();
}
EndPrimitive();
//Route to Layer 2
for (int i = 0; i 3; i++)
{
gl_Position = 0.5*gl_PositionIn[i] + vec4(0.5, 0.0, 0.0, 1.0);
//Just to see a difference in Layer 1
gl_FrontColor = vec4(0.0, 1.0, 0.0,1.0);
gl_Layer = 2;
EmitVertex();
}
EndPrimitive();
}
during the testing , only the 1st layer of texture have avaliable
context(scene with red color), other 2 layers are undefined. Has some one
sucessed in layer rendering? please give some advise, thanks a lot!
Cheers,
xiakai
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25314#25314
___
osg-users mailing
[osg-users] using osg 2.9.7 and manipulators
Hi Robert and other osg-users, I have been using (and testing) osg 2.9.7 in our applications. This version was used also for the re-factored manipulators. Here is some feedback. I had to change some code here and there, for the manipulators and for quad elements with primitive indices. We are using windows 32 and 64 bit (Visual Studio 2005) and linux 32 and 64 bit (gcc Ubuntu 4.4.1-4ubuntu9). manipulator feedback: The re-factored manipulators do make the implementation simpler. I made some subclasses for customization ( and a more model/view like approach ). There are only a few small remarks regarding the manipulators. The line segment intersectors don't intersect with the cylinders when viewed from the side. I used a polytope intersector instead and had to reimplement the entire handle function in the subclass. There are also a lot of notifications: osgManipulator::computeNodePathToRoot(,) taking first parent path, ignoring others. is this because the scene is visualized in multiple viewers? anyway, thanks for the rework on the manipulators and on osg 2.9.7, have a good day, René ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems about layer rendering
On Wed, Mar 10, 2010 at 12:21 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: this will set up multiple render targets with 3 independent color buffers. However, I am not sure if this will propely work with gl_Layer produced in Geometry shader. These OpenGL examples I saw usually set up layered framebuffer rendering with one glFramebufferTexture call. For example see this link (its sample code to render 6 faces of cubemap simultaneously) http://pastie.org/796448: However, this brings another problem: glFramebufferTexture functinality is not used by OSG yet. glFramebufferTexture calls are used in FrameBufferObject.cpp to attach a FrameBufferAttachment. Are you thinking of another use for glFramebufferTexture? Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ScreenShot File name
Hi Danny, I would like to do the following: 1) To disable static counter on the output file name and alway overwrite the last file. 2) Save this file in custom path on hard drive. How can set these option to ScreenCaptureHandler? If you look at the osgViewer/ViewerEventHandlers header, you'll see the ScreenCaptureHandler constructor takes an optional CaptureOperation: ScreenCaptureHandler(CaptureOperation* defaultOperation = 0, int numFrames = 1); You could implement your own CaptureOperation if you wanted, it's really simple, but the one concrete CaptureOperation that is provided should do what you need just by changing some default parameters. Check the ScreenCaptureHandler::WriteToFile class: WriteToFile(const std::string filename, const std::string extension, SavePolicy savePolicy = SEQUENTIAL_NUMBER); So you see, by constructing a WriteToFile with your desired filename (and path) and setting savePolicy to OVERWRITE instead of SEQUENTIAL_NUMBER, you'll get what you want. Then just pass this WriteToFile to the ScreenCaptureHandler constructor. I designed WriteToFile to cater to the most common needs, and your needs seem to fit these. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using osg 2.9.7 and manipulators
Hi René, The re-factored manipulators do make the implementation simpler. I made some subclasses for customization ( and a more model/view like approach ). There are only a few small remarks regarding the manipulators. The line segment intersectors don't intersect with the cylinders when viewed from the side. I used a polytope intersector instead and had to reimplement the entire handle function in the subclass. Interesting how different people run into the same problems but find different solutions. We also wanted the rotation manipulators to be able to be picked from the side of the cylinders, and our solution was to make the derived class generate an invisible cylinder that had a larger thickness (just for picking). But this caused the problem that the rotation code assumes that the picking of the cylinder will happen from the top or bottom, and when it happens on the side sometimes the rotation becomes unpredictable (dragging the mouse by 1 pixel makes the object rotate more than 360 degrees sometimes). We worked around this by capping the maximum rotation speed, but it's not ideal. But then again, using a polytope intersector would likely be too slow for us. So I think we'll keep our present solution. My point is that our solution was probably also easier to adapt to the refactoring of the manipulators that Robert did. I just had to change 3 lines of code and we were up and running on 2.9.7. There are also a lot of notifications: osgManipulator::computeNodePathToRoot(,) taking first parent path, ignoring others. is this because the scene is visualized in multiple viewers? I think it's probably because of the way the old manipulator architecture had to have the Dragger (or is it Selection, it's been too long since I did this) as parent of the geometry you wanted to manipulate, and now it's not necessary. I'm not sure though. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
Paul, Robert was at one time (Novemeber, December) working with removing some more static initializers. We really need to get up to date on OSG, and we need to get rid of the initializers. If Robert was able to complete that (he hadn't had time as of December), it would be a big help. (We want to use the osgViewer library, but the initializers caused problems for us.) Even if he was able to do it, I don't know whether the changes were small enough for your purposes. But for us to take another step on 2.8.x (as stable instead of developer) would be comforting. thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Tuesday, March 09, 2010 9:25 PM To: OpenSceneGraph Users Subject: [osg-users] 2.8.3 release likely, need community assistance Hi folks -- I am 99% certain that I'll be doing a 2.8.3 release in the next few weeks. The release will not be API compatible with 2.8.2. I wanted to let you all know my plans, and also solicit input and assistance if there are any changes you'd like to get into this release. With some community input, I'm sure this release could be valuable to others besides myself. I'm not inclined to incorporate any major changes such as the Notify changes, new text/binary file format, or the weak_ptr-related changes. Large changes increase the complexity of the merge and the odds of me introducing errors as I apply the changes. I'm really just interested in bug fixes and feature changes that affect only a limited portion of OSG as a whole. The work will be done on the existing 2.8 branch. There was a little-publicized 2.8.2b tag, which is just 2.8.2 plus a fix for MSFBO on Mac OS X. So the first change I'll make to the 2.8 branch is to fold in the MSFBO fix from 2.8.2b. Other changes I have in mind: * The biggest change is to backport current svn trunk osgAnimation and the FBX plugin. This will require changes to other parts of OSG, and so far I've identified these: - Changes to osgDB required by FBX. - Un-deprecation of the osgAnimation dotosg wrapper. - r10671 Core changes required for osgAnimation. - r10672 Core changes required for osgAnimation. - r11009 (only the portion applicable to the BVH plugin, so that it is compatible with osgAnimation). (This is a pretty complex change, and it's about as complex as I would want to get. In a test merge, I ran into quite a few merge conflicts that had to be resolved manually, with risk of introducing error. Hopefully everything else will be much simpler to merge over to the 2.8 branch.) * Fix for osgUtil::Optimizer FlattenStaticTransformsVisitor (r11131). * Fix for OcclusionQueryNode (r10933 and r11127). * Mac OS X 10.6 support. Not yet sure which svn revisions. * New Xcode updates for osgAnimation. * A run of genwrappers to support any and all API changes. * Possibly backport some examples such as osganimationviewer, haven't looked at them yet. What I'd like from the community: * Any suggestions for other changes? Ideally, they should be modular, tight changes that merge onto the 2.8 branch with a minimum of conflicts. Please post requests using the specific svn revision number. (Also, please don't suggest anything unless you are willing and able to test the change once it's in on the 2.8 branch.) * Anyone out there with Mac OS X experience? Specific things I'd like assistance with would be: - Input on which svn revisions are required to enable support for Mac OS X 10.6. The goal is to be able to build OSG 2.8.3 against the 10.6 SDK. - Somebody with a Mac that already has 10.6, for testing. I have 10.5 but can upgrade if no one else steps forward. - An Xcode expert to create appropriate Xcode files for the 2.8.3 release (needs to work with the osgAnimation backport). If everything goes well, I see no reason why we can't release by end of March, so I'd like to set this schedule: * All change requests by end of day Friday 12 March. * All code changes in by 17 March. * All Xcode and genwrapper changes in by 22 March. * Release candidate 1, 22 March. * Testing period, 23-30 March. * Release, 31 March. Please give this some thought, and thanks in advance for pitching in. -Paul ___ 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] Playing smoothly a big video
Hi all, We currently need to play a big video (approximately 5500*800) on 4 screens within an OSG application (we use a composite viewer), so we've tried : - Cut the video in 4 parts, but it seems really hard to synchronize the 4 streams. - Decode directly the big file, resulting with a very big texture split on 4 quads (with appropriate texture coords), but even with a powerful computer, it's very slow. Any idea on what's the best approach for this problem ? We're currently making our tests using the ffmpeg plugin, but maybe another plugin would be more appropriate ? Thanks in advance for your help. Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
Hi Andy, On Wed, Mar 10, 2010 at 2:02 PM, Andy Skinner andy.skin...@mathworks.comwrote: Robert was at one time (Novemeber, December) working with removing some more static initializers. We really need to get up to date on OSG, and we need to get rid of the initializers. If Robert was able to complete that (he hadn't had time as of December), it would be a big help. (We want to use the osgViewer library, but the initializers caused problems for us.) I'm afraid I've only done part of the work on replacing the static initializers, the only areas that I've cleaned up the ones that I was tackling during other work. Curiously only yesterday I was starting to think about what's left to do for 3.0 and the static initializers was one of own personally todo items. Do this work as a community task might be appropriate, a different thread would be the place to do this. Even if he was able to do it, I don't know whether the changes were small enough for your purposes. But for us to take another step on 2.8.x (as stable instead of developer) would be comforting. I suspect the changes for static initializers would often be a bit too intrusive as it'll come with other changes. One could possible try and tackle the task for the 2.8 branch and 2.9.x series separately, but.. this comes with more resources needed. If you can dive in a help out then it might make it more possible. My guess is that Paul already has more than enough tasks to do to put 2.8.3 together without other tasks pilling on top. If a set of non intrusive changes can be supplied to Paul in a form that he can easily review and merge without risky stability or portability then it'll have a better chance of making it in. With the 2.9.x series the scope is still more open to more intrusive changes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems about layer rendering
Nope. I meant glFramebufferTexture(..). And no, this particular function is not called there. Go check this. glFramebufferTexture1D(..), glFramebufferTexture2D(..), glFramebufferTexture3D(..), glFramebufferTextureLayer(..) are not the same thing... Wojtek Lewandowski - Original Message - From: Tim Moore To: OpenSceneGraph Users Sent: Wednesday, March 10, 2010 2:05 PM Subject: Re: [osg-users] problems about layer rendering On Wed, Mar 10, 2010 at 12:21 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: this will set up multiple render targets with 3 independent color buffers. However, I am not sure if this will propely work with gl_Layer produced in Geometry shader. These OpenGL examples I saw usually set up layered framebuffer rendering with one glFramebufferTexture call. For example see this link (its sample code to render 6 faces of cubemap simultaneously) http://pastie.org/796448: However, this brings another problem: glFramebufferTexture functinality is not used by OSG yet. glFramebufferTexture calls are used in FrameBufferObject.cpp to attach a FrameBufferAttachment. Are you thinking of another use for glFramebufferTexture? Tim -- ___ 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] Help: how to rotate view camera 90 degrees in relationship to terrain
Hi,
I am having some extreme difficulty in rotating my viewing camera 90 degrees
with respect to a local coordinate system.
Local coordinate system: (in geocentric measure)
mine is at the edge of the earth; i.e. i'm using a spherical earth. here is
how I compute the local axes:
fuctionName ( osg::PositionAttitudeTransform pax )
{
osg::vec3d objectLocation = pax-getPosition(); // where x,y,z are -678468.2,
-5405095.0, 3682910.3
osg:;quat qOrient = pax-getAttitude();
osg::vec3d up(0,0,1); // z axis of the earth or World coordinates
osg::vec3d x_axis = up ^ objectLocaction;
osg::vec3d y_axis = objectLocaction ^ x_axis;
x_axis.normalize();
y_axis.normalize();
osg::Quat qRotAboutAxisByDegree;
qRotAboutAxisByDegree.makeRotate( osg::DegreesToRadians(-90.), objectLocaction);
osg::Quat qNewOrient = qOrient * qRotAboutAxisByDegree;
s_mtxdIrCamPosOrientOri = osg::matrix::rotate(qNewOrient) *
osg::matrix::translate(objectLocation);
}
1. I know for a fact that the pax is set correctly with position attitude
because my objects are being placed on my terrain, which is georeferenced
terrain, correctly; i.e. they are perpendicular w/ the terrain and sit nicely
on it.
2. the above code snippet actually works for rotation about the local Z axis
and I am looking straight down at my terrain; i.e. directly down the local Z
axis.
3. I want to rotate the camera up 90 degrees and be looking down the positive
X axis.
4. I have tried replacing
qRotAboutAxisByDegree.makeRotate( osg::DegreesToRadians(-90.), objectLocaction);
with
qRotAboutAxisByDegree.makeRotate( osg::DegreesToRadians(-90.), x_axis);
and I get the camera rotated about some axis I am NOT sure of and I am looking
at the terrain from a peculiar angle, though I know not what angle.
5. I am using the TerrainManipulator as my scene matrix manipulator, if that
helps.
Would someone please give me insight as to how to do this? I would be greatly
appreciative as the solution is totally eluding me. :O
...
Thank you!
Thank you very much.
Cheers,
Allen
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25471#25471
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] opengl 3 course: march 30 - april 2, 2010 - los angeles
Hi, any update on osg training? ... Thank you! Cheers, Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25472#25472 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rotating a Pyramid about its peak
Hi, How do I translate the origin to the peak? Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25474#25474 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] libjasper with jpeg decoder for jp2 plugin
Thanks, Laurens. I am trying on it. with best wishes Zhenlong Hi Zhenlong, I have tested the jp2 plugin on windows, attachted are my projectfiles for Visual studio 9 express, and a few fixes for the most serious warnings. I hope this helps, Laurens. Attached zip is an overlay for the jasper source from: http://www.ece.uvic.ca/~mdadams/jasper/software/jasper-1.900.1.zip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rotating a Pyramid about its peak
Hi John, Might not be the best solution but I think it will do the work. 1. translate the pyramid so your peak becomes at (0,0,0) 2. perform the rotation 3. translate back so your matrix would look like osg::Matrix m = osg::Matrix::translate(-peak) * osg::Matrix::rotate(quat) * osg::Matrix::translate(peak) -Nick On Wed, Mar 10, 2010 at 5:43 PM, John Galt manu9ak...@gmail.com wrote: Hi, How do I translate the origin to the peak? Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25474#25474 ___ 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] Playing smoothly a big video
Hi Serge, Serge Lages wrote: Hi all, We currently need to play a big video (approximately 5500*800) on 4 screens within an OSG application (we use a composite viewer), so we've tried : - Cut the video in 4 parts, but it seems really hard to synchronize the 4 streams. - Decode directly the big file, resulting with a very big texture split on 4 quads (with appropriate texture coords), but even with a powerful computer, it's very slow. Any idea on what's the best approach for this problem ? We're currently making our tests using the ffmpeg plugin, but maybe another plugin would be more appropriate ? Thanks in advance for your help. some ideas/questions. We do something similar - stitch four high-res camera videos into large texture. We have custom ffmpeg reader that just reads from 4 video files and we step them manually (and in sync) one frame at a time. We use raw video (no compression) to avoid cpu decompress, but now one needs fast disks. We don't have sound, do you need sound? For large sizes one needs to avoid copying around data in cpu mem as much as possible. There is still one copy in ffmpeg raw read that I need to get rid of. rgds jp Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture with independent framerate
Hi JP, thanks for you hint. I tried to code from the linked thread. Unfortunately it does not really work very well. To get you updated: I have 2 cameras, one is the original viewer cam and the other is a pbuffer one. My scenegraph has two nodes: root - scene - RRT Camera - scene2 I have an image connected to the RRT camera. In the main scene I have an overlay showing the image on a texture. I get two problems: 1) using viewer.setCamera(); alternatingly causes: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Maybe this is because setcamera creates a new Renderer every time? 2) When the scene for the pBuffer frames contains only the RRT camera then I see that there seems to be no rendering because the image is not updated and i tried a callback of the RRT camera with the printf that did not show anything. How difficult would it be to overload the osgviewer and implement a custom rendering of my RRT camera(s) off screen. Any Hints? Best regards and many thanks! Georg signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi JP, Thanks for your answer, and we don't need sound. By a fast disk, what do you recommend ? Your ffmpeg reader is based on the current OSG plugin or is it a custom one ? About our file, with some codecs and adjustments on the bitrate, we're able to play it with VLC without problems, so I think the reading part can be handled by the ffmpeg plugin with only one file, but then we need to dispatch this image on 4 textures. We're currently trying to do some tests. Cheers, On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Serge, Serge Lages wrote: Hi all, We currently need to play a big video (approximately 5500*800) on 4 screens within an OSG application (we use a composite viewer), so we've tried : - Cut the video in 4 parts, but it seems really hard to synchronize the 4 streams. - Decode directly the big file, resulting with a very big texture split on 4 quads (with appropriate texture coords), but even with a powerful computer, it's very slow. Any idea on what's the best approach for this problem ? We're currently making our tests using the ffmpeg plugin, but maybe another plugin would be more appropriate ? Thanks in advance for your help. some ideas/questions. We do something similar - stitch four high-res camera videos into large texture. We have custom ffmpeg reader that just reads from 4 video files and we step them manually (and in sync) one frame at a time. We use raw video (no compression) to avoid cpu decompress, but now one needs fast disks. We don't have sound, do you need sound? For large sizes one needs to avoid copying around data in cpu mem as much as possible. There is still one copy in ffmpeg raw read that I need to get rid of. rgds jp Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] adjusting brightness and contrast in osgviewer
Thanks, Nick. I just wonder if it is hard to create such a common function in osg for brightness and contrast adjustment of JPEG image, say add a filter. As I know, shader is not the same as real adjustment of brightness and contrast. with best wishes Zhenlong Subject: Re: [osg-users] adjusting brightness and contrast in osgviewer Message-ID: 6861bc941003042334yc80c2f2nc09163b27a5c6...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I dont think there are built in methods in osg for this. But I see it doable via shaders - this way you can do any image processing you want. -Nick On Thu, Mar 4, 2010 at 9:59 PM, zhenlong li zxl1...@gmail.com wrote: Dear all, Is there any function to adjust the brightness or contrast of image in osgviewer? If not, is it hard to add those functions in? Thanks! with best wishes Zhenlong ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi Serge, On Wed, Mar 10, 2010 at 4:11 PM, Serge Lages serge.la...@gmail.com wrote: About our file, with some codecs and adjustments on the bitrate, we're able to play it with VLC without problems, so I think the reading part can be handled by the ffmpeg plugin with only one file, but then we need to dispatch this image on 4 textures. We're currently trying to do some tests. Why do you need four textures? Modern graphics cards can handle pretty large texture sizes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] adjusting brightness and contrast in osgviewer
As I know, shader is not the same as real adjustment of brightness and contrast. I think it is -Nick On Wed, Mar 10, 2010 at 6:16 PM, zhenlong li zxl1...@gmail.com wrote: Thanks, Nick. I just wonder if it is hard to create such a common function in osg for brightness and contrast adjustment of JPEG image, say add a filter. As I know, shader is not the same as real adjustment of brightness and contrast. with best wishes Zhenlong Subject: Re: [osg-users] adjusting brightness and contrast in osgviewer Message-ID: 6861bc941003042334yc80c2f2nc09163b27a5c6...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I dont think there are built in methods in osg for this. But I see it doable via shaders - this way you can do any image processing you want. -Nick On Thu, Mar 4, 2010 at 9:59 PM, zhenlong li zxl1...@gmail.com wrote: Dear all, Is there any function to adjust the brightness or contrast of image in osgviewer? If not, is it hard to add those functions in? Thanks! with best wishes Zhenlong ___ 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] adjusting brightness and contrast in osgviewer
Hi Zhenlong, On Wed, Mar 10, 2010 at 4:16 PM, zhenlong li zxl1...@gmail.com wrote: Thanks, Nick. I just wonder if it is hard to create such a common function in osg for brightness and contrast adjustment of JPEG image, say add a filter. As I know, shader is not the same as real adjustment of brightness and contrast. I'm rather perplexed by your questions/request. The OSG isn't a monitor that you twist some dials and change the brightness. It's and scene graph API that is closely linked with OpenGL, it's general purpose, but with it you the developer have to code solution to problems that you are trying to solve. There are many ways of changing attributes related to OpenGL rendering with the OSG, but given the nature of your questions I really not sure advice in the direction will be helpful, as your questions seem directed at stuff that is too high level for what one would expect from a scene graph API. Are you familiar with OpenGL/3D graphics/scene graphs? Is it a problem with your data? Is it a problem with lighting? What are you trying to achieve with your application? You'll need to pass on more information about what you are trying to do, and how much knowledge others can assume you to have otherwise we really won't know how to help you. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi Robert, We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. On Wed, Mar 10, 2010 at 5:17 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Serge, On Wed, Mar 10, 2010 at 4:11 PM, Serge Lages serge.la...@gmail.comwrote: About our file, with some codecs and adjustments on the bitrate, we're able to play it with VLC without problems, so I think the reading part can be handled by the ffmpeg plugin with only one file, but then we need to dispatch this image on 4 textures. We're currently trying to do some tests. Why do you need four textures? Modern graphics cards can handle pretty large texture sizes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.com wrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Thanks for your advices Robert, anyone had some success on configuring and sharing graphic contexts on Windows 7 ? We'll also try the 4 images based on one big image and let you know how it goes. Cheers, On Wed, Mar 10, 2010 at 5:43 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.comwrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] need help with cmake / osg / os x / frameworks
Hi Stephan,
I am trying your XCode/CMake mods. It is now compiling, and very slw
but I have realize that in your osgViewer/CmakeLists.txt there is a weird
thing.
Line 107:
SET(LIB_EXTRA_LIBS ${COCOA_LIBRARY} ${LIB_EXTRA_LIBS})
Shouldn't it be SET(LIB_EXTRA_LIBS ${CARBON_LIBRARY} ${LIB_EXTRA_LIBS}) ??
Cheers.
2010/3/10 Stephan Maximilian Huber ratzf...@digitalmind.de
Hi all,
I am trying to add framework-support to the cmake-files, and I am
hitting a wall. I am not a cmake-expert so I'll ask the community for help.
Attached you'll find my modified cmake-files (based on current trunk),
which adds compiling osg as frameworks, which can be embedded into
application bundles (this is the main reason for the existance of the
deprecated xcode-project)
To compile frameworks with cmake you'll have to:
set OSG_COMPILE_FRAMEWORKS to TRUE
modify OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR if needed
set the CMAKE_INSTALL_PREFIX to something reasonable, I use a folder on
my desktop as destination.
Click Configure, click generate, open the xcode project, click build,
select the install-target, click build again. So you'll find in
CMAKE_INSTALL_PREFIX a bunch of folders, in lib you'll find the
frameworks, ready to be embedded into your app.
You'll get valid frameworks ONLY if you run the install-target. Without
that, the install_name_dirs are bound to the local storage of the
frameworks, and will not work on other computers, or other destinations.
And here's the big BUT:
I have problems to move the api-headers of osgViewer into their right
places (osgViewer.framework/headers/api/(Carbon|Cocoa)/*)
They end all in osgViewer.framework/headers/
There is a special property for this called MACOSX_PACKAGE_LOCATION,
which should move the corresponding files to the special place in the
framework-bundle, but it doesn't work for the api-headerfiles. Perhaps
someone can look at the source in src/osgViewer/CMakeLists.txt and check
my approach. cmake copies two cpp-files into that place instead of the
header-files.
So please, please test the packaged cmake-files and perhaps there is
someone out there who can help with the issues with the
osgviewer-header-files!
thanks in advance,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Jordi Torres Fabra
gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Serge, One other item that hasn't been explicitly mentioned yet is pixel packing. You want to make sure that the graphics card does as little with the source image as possible to get it into the OpenGL pipeline. Make sure that your on-disk pixel format is something that is on the fast path. Storing data as 24-bit RGB is not a good choice as it is not aligned. BGRA is your best bet as it is about the fastest pixel format on nvidia hardware. Chuck On Mar 10, 2010, at 8:43 AM, Robert Osfield wrote: Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.com wrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ 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] Playing smoothly a big video
Serge Lages wrote: Hi Robert, We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Four screens with one card? Does that mean you're using a Quadro NVS? If so, those cards aren't really designed to push a lot of pixels, and the 15fps rate wouldn't really surprise me. I'm guessing that when you switch to 2 cards (assuming they're decent 3D cards), you'll have better results, even with the multiple contexts and one large texture. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] need help with cmake / osg / os x / frameworks
Hi Stephan,
The XCode build fails for me in osgunittests when running
runFileNameUtilsTest(osg::ArgumentParser) because ld: symbol(s) not
found. Let me investigate further...
Cheers.
2010/3/10 Jordi Torres jtorresfa...@gmail.com
Hi Stephan,
I am trying your XCode/CMake mods. It is now compiling, and very
slw but I have realize that in your osgViewer/CmakeLists.txt there
is a weird thing.
Line 107:
SET(LIB_EXTRA_LIBS ${COCOA_LIBRARY} ${LIB_EXTRA_LIBS})
Shouldn't it be SET(LIB_EXTRA_LIBS ${CARBON_LIBRARY} ${LIB_EXTRA_LIBS}) ??
Cheers.
2010/3/10 Stephan Maximilian Huber ratzf...@digitalmind.de
Hi all,
I am trying to add framework-support to the cmake-files, and I am
hitting a wall. I am not a cmake-expert so I'll ask the community for
help.
Attached you'll find my modified cmake-files (based on current trunk),
which adds compiling osg as frameworks, which can be embedded into
application bundles (this is the main reason for the existance of the
deprecated xcode-project)
To compile frameworks with cmake you'll have to:
set OSG_COMPILE_FRAMEWORKS to TRUE
modify OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR if needed
set the CMAKE_INSTALL_PREFIX to something reasonable, I use a folder on
my desktop as destination.
Click Configure, click generate, open the xcode project, click build,
select the install-target, click build again. So you'll find in
CMAKE_INSTALL_PREFIX a bunch of folders, in lib you'll find the
frameworks, ready to be embedded into your app.
You'll get valid frameworks ONLY if you run the install-target. Without
that, the install_name_dirs are bound to the local storage of the
frameworks, and will not work on other computers, or other destinations.
And here's the big BUT:
I have problems to move the api-headers of osgViewer into their right
places (osgViewer.framework/headers/api/(Carbon|Cocoa)/*)
They end all in osgViewer.framework/headers/
There is a special property for this called MACOSX_PACKAGE_LOCATION,
which should move the corresponding files to the special place in the
framework-bundle, but it doesn't work for the api-headerfiles. Perhaps
someone can look at the source in src/osgViewer/CMakeLists.txt and check
my approach. cmake copies two cpp-files into that place instead of the
header-files.
So please, please test the packaged cmake-files and perhaps there is
someone out there who can help with the issues with the
osgviewer-header-files!
thanks in advance,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Jordi Torres Fabra
gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
--
Jordi Torres Fabra
gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] adjusting brightness and contrast in Osgviewer
Thanks, Robert, Sorry for the confusion. I am a beginner of 3D graphics. Right now, there is a nice JPS viewer based on OSGviewer. I want to add function to adjust the brightness and contrast of the image when viewing it, just similar to what one can do to a JPEG image with a JPEG viewer. Previous I thought OSGviewer has this kind of function for osg image already, so that one may call the function or take it as a reference. Hope this is clear. with best wishes Zhenlong ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] source for 3d glasses?
http://www.amazon.de/3DStereo-Glasses-3D-Brille-Blau/dp/B001VJYGE0/ref=sr_1_1?ie=UTF8s=ce-deqid=1268254978sr=8-1 very cheap this offer is - but shipping you must pay for. says Yoda. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] need help with cmake / osg / os x / frameworks
Hi Jordi,
Am 10.03.10 19:27, schrieb Jordi Torres:
Shouldn't it be SET(LIB_EXTRA_LIBS ${CARBON_LIBRARY} ${LIB_EXTRA_LIBS}) ??
No that's correct, as the carbon implementation uses also some
cocoa-code in DarwinUtils.mm.
cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Model Texture Compression Options
Hi, Thanks for the info, while I've used OSGConv to create IVE version of single models in the past I could not find a batch function. Is there a batch switch built in or can I use the directory switch like VPB uses for multiple input files ? I'm quite keen to give the DXT etc compression a go on a large model set of around 100,000 to see what the performance difference is. ... Thank you! Cheers, Colin www.aamgroup.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25504#25504 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems about layer rendering
Hi, I checked RenderStage::runCameraSetUp() source code, and found that bufferAttachments only have Texture1D, Texture2D, Texture3D, TextureCubeMap, TextureRetangle, but without TextureArray, and I don`t know weather OSG using glFramebufferTextureLayer or glFramebufferTexture when bind TextureArray, cubeMap and Texture3D, if using glFramebufferTexture, no layer rendering is available. I will try Texture3D for layer rendering. BTW, shadowCamera-attach(osg::Camera::COLOR_BUFFER0, ta, 0, 0); shadowCamera-attach(osg::Camera::COLOR_BUFFER1, ta, 0, 1); shadowCamera-attach(osg::Camera::COLOR_BUFFER2, ta, 0, 2); does not take effects, each color_buffer only accept the rastered fragments of primitive in first layer, the other 2 in geometry shader does not shown. Thank you! Cheers, Kai -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25506#25506 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems about layer rendering
Kai Xia wrote: Hi, I checked RenderStage::runCameraSetUp() source code, and found that bufferAttachments only have Texture1D, Texture2D, Texture3D, TextureCubeMap, TextureRetangle, but without TextureArray, and I don`t know weather OSG using glFramebufferTextureLayer or glFramebufferTexture when bind TextureArray, cubeMap and Texture3D, if using glFramebufferTexture, no layer rendering is available. I will try Texture3D for layer rendering. BTW, shadowCamera-attach(osg::Camera::COLOR_BUFFER0, ta, 0, 0); shadowCamera-attach(osg::Camera::COLOR_BUFFER1, ta, 0, 1); shadowCamera-attach(osg::Camera::COLOR_BUFFER2, ta, 0, 2); does not take effects, each color_buffer only accept the rastered fragments of primitive in first layer, the other 2 in geometry shader does not shown. The attach() method in FrameBufferObject.cpp seems to have support for Texture2D Arrays (and it calls glFrameBufferTextureLayer for them). I don't know if this means that it's fully supported, but someone at least tried to support them. For cube maps and 3D textures, it calls glFramebufferTexture2D and glFramebufferTexture3D, respectively. It does look like texture arrays are missing in RenderStage::runCameraSetUp, but I don't know enough about things there to know whether or not this is a problem. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unable to save just captured screen
Hi, This post was very helpful. I ran into the same problem. Thanks a million! :) ... Thank you! Cheers, Arun -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25508#25508 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Display from buffer
Thanks. Yes. I m using osg::Image to set my pixel buffer. I set GL_LUMINANCE as internal pixel format. But I m getting only black image. My code looks like this, .. unsigned char* data; int width, height; width=4200; //source_image width height=4710;//source_image height long size = width * height; data = new unsigned char[size]; //Reading Image of width * height into buffer for(i=0;i(width * height); i++) data[i]=source_image[i]); //Setting image osg::ref_ptrosg::Image image = new osg::Image; image-allocateImage(width, height, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE); image-setOrigin(osg::Image::BOTTOM_LEFT); image-setImage(width, height, 1, GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE,data, osg::Image::NO_DELETE); texture-setImage(image); My another question is, could it possible to display image without scaling down/up? Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25509#25509 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: how to rotate view camera 90 degrees in relationship to terrain
Hi,
I didn't try to follow your code, but here's and overview of how we do it:
Have a camera/manipulator makeLookAt command that takes eye, center and
up vectors. (These can be converted to the osg manipulators' distance,
rotation, center).
Have a transformation matrix from ECEF coords to local coords. Assume
the camera is positioned/rotated in ECEF.
In the local coords calculate eye, center, up. Convert to ECEF using the
transformation matrix and stick into makeLookAt.
jp
Allen Saucier wrote:
Hi,
I am having some extreme difficulty in rotating my viewing camera 90 degrees with respect
to a local coordinate system.
Local coordinate system: (in geocentric measure)
mine is at the edge of the earth; i.e. i'm using a spherical earth. here is
how I compute the local axes:
fuctionName ( osg::PositionAttitudeTransform pax )
{
osg::vec3d objectLocation = pax-getPosition(); // where x,y,z are -678468.2,
-5405095.0, 3682910.3
osg:;quat qOrient = pax-getAttitude();
osg::vec3d up(0,0,1); // z axis of the earth or World coordinates
osg::vec3d x_axis = up ^ objectLocaction;
osg::vec3d y_axis = objectLocaction ^ x_axis;
x_axis.normalize();
y_axis.normalize();
osg::Quat qRotAboutAxisByDegree;
qRotAboutAxisByDegree.makeRotate( osg::DegreesToRadians(-90.), objectLocaction);
osg::Quat qNewOrient = qOrient * qRotAboutAxisByDegree;
s_mtxdIrCamPosOrientOri = osg::matrix::rotate(qNewOrient) *
osg::matrix::translate(objectLocation);
}
1. I know for a fact that the pax is set correctly with position attitude
because my objects are being placed on my terrain, which is georeferenced terrain,
correctly; i.e. they are perpendicular w/ the terrain and sit nicely on it.
2. the above code snippet actually works for rotation about the local Z axis
and I am looking straight down at my terrain; i.e. directly down the local Z axis.
3. I want to rotate the camera up 90 degrees and be looking down the positive
X axis.
4. I have tried replacing
qRotAboutAxisByDegree.makeRotate( osg::DegreesToRadians(-90.), objectLocaction);
with
qRotAboutAxisByDegree.makeRotate( osg::DegreesToRadians(-90.), x_axis);
and I get the camera rotated about some axis I am NOT sure of and I am looking
at the terrain from a peculiar angle, though I know not what angle.
5. I am using the TerrainManipulator as my scene matrix manipulator, if that
helps.
Would someone please give me insight as to how to do this? I would be greatly
appreciative as the solution is totally eluding me. :O
...
Thank you!
Thank you very much.
Cheers,
Allen
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25471#25471
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rotating a Pyramid about its peak
Hi, well... I don't know what your pyramid looks like or where it's center position is. You have the coordinates of the corners so you'll need to calculate the translation to get the tip at 0,0,0. jp John Galt wrote: Hi, How do I translate the origin to the peak? Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25474#25474 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture with independent framerate
Hi, Georg Martius wrote: Hi JP, thanks for you hint. I tried to code from the linked thread. Unfortunately it does not really work very well. To get you updated: I have 2 cameras, one is the original viewer cam and the other is a pbuffer one. My scenegraph has two nodes: root - scene - RRT Camera - scene2 I have an image connected to the RRT camera. In the main scene I have an overlay showing the image on a texture. I get two problems: 1) using viewer.setCamera(); alternatingly causes: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Maybe this is because setcamera creates a new Renderer every time? Hmm, this is strange. 0x8CD5 is GL_FRAMEBUFFER_COMPLETE_EXT. Have you tried setting SingleThreaded mode for the viewer to see if anything changes? Only other thing I can think of is to swap camera buffers instead of swapping cameras, but I haven't tried this. What hardware/OS are you on? 2) When the scene for the pBuffer frames contains only the RRT camera then I see that there seems to be no rendering because the image is not updated and i tried a callback of the RRT camera with the printf that did not show anything. Maybe it thinks nothing has to be drawn... Try putting something with culling off into the scene. How difficult would it be to overload the osgviewer and implement a custom rendering of my RRT camera(s) off screen. Any Hints? Not sure, but you are not the first to want this kind of functionality. You can maybe mess with custom RenderStages. Maybe see here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/50502 Sorry I can't help more jp Best regards and many thanks! Georg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi, Serge Lages wrote: Hi JP, Thanks for your answer, and we don't need sound. By a fast disk, what do you recommend ? We have a raid0 setup that can sustain 150MB/s. Your ffmpeg reader is based on the current OSG plugin or is it a custom one ? It's a custom one, but not complicated. It basically pops the output of ffmpeg decompress into an osg::Image, set's PBO on that and lets OSG upload it. We are using only monochrome images though (GL_LUMINANCE). About our file, with some codecs and adjustments on the bitrate, we're able to play it with VLC without problems, so I think the reading part can be handled by the ffmpeg plugin with only one file, but then we need to dispatch this image on 4 textures. We're currently trying to do some tests. I'm still not sure where your problem area is. If it's not decoding it can only be upload to GPU or final rendering. You should be able to check this by varying the complexity of the rendering. jp Cheers, On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za wrote: Hi Serge, Serge Lages wrote: Hi all, We currently need to play a big video (approximately 5500*800) on 4 screens within an OSG application (we use a composite viewer), so we've tried : - Cut the video in 4 parts, but it seems really hard to synchronize the 4 streams. - Decode directly the big file, resulting with a very big texture split on 4 quads (with appropriate texture coords), but even with a powerful computer, it's very slow. Any idea on what's the best approach for this problem ? We're currently making our tests using the ffmpeg plugin, but maybe another plugin would be more appropriate ? Thanks in advance for your help. some ideas/questions. We do something similar - stitch four high-res camera videos into large texture. We have custom ffmpeg reader that just reads from 4 video files and we step them manually (and in sync) one frame at a time. We use raw video (no compression) to avoid cpu decompress, but now one needs fast disks. We don't have sound, do you need sound? For large sizes one needs to avoid copying around data in cpu mem as much as possible. There is still one copy in ffmpeg raw read that I need to get rid of. rgds jp Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Display from buffer
Hi, Akilan Thangamani wrote: Thanks. Yes. I m using osg::Image to set my pixel buffer. I set GL_LUMINANCE as internal pixel format. But I m getting only black image. My code looks like this, .. unsigned char* data; int width, height; width=4200; //source_image width height=4710;//source_image height long size = width * height; data = new unsigned char[size]; Hmm, does your card support 4K textures? Maybe start with something smaller with known/generated data just to see if it works. //Reading Image of width * height into buffer for(i=0;i(width * height); i++) data[i]=source_image[i]); //Setting image osg::ref_ptrosg::Image image = new osg::Image; image-allocateImage(width, height, 1, GL_LUMINANCE, GL_UNSIGNED_BYTE); you don't need allocateImage, you are allocating data yourself. image-setOrigin(osg::Image::BOTTOM_LEFT); not sure why you want this, just flip the texture coordinates later. image-setImage(width, height, 1, GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE,data, osg::Image::NO_DELETE); texture-setImage(image); My another question is, could it possible to display image without scaling down/up? What scaling are you talking about? Maybe do texture-setResizeNonPowerOfTwoHint(false); How are you applying the texture? jp Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25509#25509 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
