[osg-users] How to setup osg with c++
Hi, I am new in using open scene graph, and i have problems is setting up osg with microsoft visual 2008 c++ express edition. can anyone help me up? Thank you! Cheers, shyuan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35722#35722 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to setup osg with c++
What is the problem ? You should have a look on osg website to find installation help. Vincent. Le 18/01/2011 10:08, Tze Shyuan a écrit : Hi, I am new in using open scene graph, and i have problems is setting up osg with microsoft visual 2008 c++ express edition. can anyone help me up? Thank you! Cheers, shyuan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35722#35722 ___ 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] multiple tex gen modes in a single scene
Hi, I have a small amount of extra info to add, which confuses me even more. Revisting all my code I discovered that my overlays actualy use two eye linear tex gens (one for close items, one for distant ones, a bit like the parralel split shadow maps) with different matrices and different units. These work fine in isolation, but don't work when I add in the third shadow tex gen. The code that adds the tex gens to the positional state container is almost identical. I am now very confused as to why I can use two tex gens for my overlays but it wont work with shadows added. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: Friday, 21 January 2011 3:47 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Robert, I am currently adding shadows to my scene (which is going well) but in doing so I have hit this issue. I already use an eye linear tex gen in my scene to render overlays (very similar code to the osgSim::OverlayNode). I don't think it would be possible for me to split the renderering accross two different RenderStages as the two tex gens are used from within the same shader to render my terrain (one for applying shadows and the other for applying overlays). I have had a look at the PositionalStateContainer class and I do not understand why the issue exists. The tex gens use different texture units and as such there matrices are stored and applied seperately. However the result I am seeing is one of the two always 'wins' and its matrix is applied to both tex gens. This is an issue I will need to resolve so I am hoping you could provide some more guidance as to what would be the best solution. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, 13 January 2011 6:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Paul, Eye linear glTexGen is positional state, i.e. it's value depends on the current modelview matrix, so has to be treated by the OSG like other positional state like glLight and glClipPlane. All positional state has to be positioned by a positional state node, and for glTexGen this is TexGenNode. During the cull traversal the OSG collects the positional state and binds the TexGen/Light/ClipPlane to modelview matrix at that point in traversal, this binding is done via the PositionalStateContainer, and there is one of these per RenderStage. During the draw traversal the positional state is then applied prior to the traversal of the RenderStage, and fixes each positional state in the appropriate place. While this technique doesn't properly fix the state as required, it does limit you to one position, per stage, you can't have two eye line tex gens/lights/clip planes applied on two separate subgraphs. Object linear TexGen isn't positional state so can be applied in the normal way and you have multiple of these per stage without problem. To have multiple Eye linear TexGen/TexGenNode's you'll need to break the scene up into multiple RenderStage and use the clear mask set to 0 on the subsequent stages so that each stage overlays correctly on the previous one. Other approaches are to write a custom TexGen that you push/pop a custom modelview matrix. I'm afraid both approaches are rather hacky. Robert. On Thu, Jan 13, 2011 at 2:28 AM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- Has anyone ever successfully used multiple TexGen modes (say, EYE_LINEAR and OBJECT_LINEAR) on different objects in the same scene? What is the recommended way to do this in OSG? The TexGenNode has a pointer to a TexGen, and the TexGen has the mode. I assume I should create two TexGens, one OBJECT_LINEAR and one EYE_LINEAR, and two TexGenNodes to reference them, and add the two TexGenNodes to the scene graph. Then, I assume I should attach the same two TexGens as StateAttributes to different Node's StateSets as needed. I am running into some issues with this. If it sounds like I'm doing everything right, I'll post a small example that fails, or dig into the OSG code. More than likely, I'm doing something wrong here, so I just wanted to ask what the intended usage is. Thanks, -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ 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 DISCLAIMER:---
Re: [osg-users] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi JP Thanks for the quick response. I'm not used to these forum things so the format of my response will probably be odd, anyway... what are you setting for near/far in the DO_NOT_COMPUTE_NEAR_FAR case? What is your nonLinearRange value? Is it dependent on camera field of view? In both cases I'm getting my the near/far from rttCamera-getProjectionMatrixAsFrustum. The values returned in the the DO_NOT_COMPUTE case are 1.0 and 1.0 and the linearised ranges seem to agree with this. The camera field of view is not changing. I haven't looked at the actual values only their differences. I had hoped that some of my assumptions were wrong, but following your response it seems that I'm going to have to do this the hard way and get some proper data. Also, I discovered yesterday that I'm going to have to port the whole lot to Windows because of image processing dependencies. This might take some time. Hopefully I can eventually close this thread down with some answers rather than questions. Thanks again. John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35837#35837 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I extract OSG data?
Hi Christian, What you mean by extract data... there is lots of types of data stored in 3d model files, vertices, colours, primitives, state, nodes. The data is also stored in a hierarchy so a CSV file really wouldn't be very appropriate. Perhaps the most useful answers you'll get would be if you explained what you wanted to extract data for. There are many ways of extracting data from a scene graph, but how you go about it depends entirely what you want to do with the data. Robert. On Wed, Jan 19, 2011 at 11:01 PM, Christian Sanelli csane...@potomacfusion.com wrote: Hi, I'm an OSG newbie and after a few hours looking around online, I don't see how I can extract the data from my OSG files. How do I extract the data into, say, CSV files? Thank you very much! Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35782#35782 ___ 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] Screen Resolution Being Overriden in Twinview
Hi Karl, The issue you are seeing is mostly like the window manager redirecting the request for a full sized window to produce a window that fits one screen. To tell X11 to override the window manage redirect you'll need to set the Traits::overrideRedirect flag to true. Robert. On Thu, Jan 20, 2011 at 10:08 PM, Cary, Karl A. karl.a.c...@saic.com wrote: I am having an issue with screen resolution in Twinview. If I am in clone mode or non twinview, everything is fine. But when I am in twinview otherwise, the screen resolution changes even though I am not telling it to. It is essentially adding an invisible window decoration as that is the size it is changing by. My setup: I have 2 monitors, one is 1280x1024, the other is 1920x1200. I would like my application to show up on the 1280x1024 monitor and it does, just not at 1280x1024. When I create my graphics context, I do the following: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 0; traits-y = 0; traits-width = 1280; traits-height = 1024; traits-windowDecoration = false; traits-windowName = “myApp”; traits-doubleBuffer = true; traits-sharedContext = 0; osg::DisplaySettings* ds = osg::DisplaySettings::instance(); traits-sampleBuffers = ds-getMultiSamples; traits-samples = ds-getNumMultiSamples(); osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); At this point if I pause my program, the resolution is already wrong. It is starting at 0,0, but it is missing the far right and bottom, about the size of the window decoration border. If I then go through and get the window out of the osgViewer and do a window-setWindowRectangle(0,0,1280,1024), the screen goes full screen again. However any time I do anything at all to the viewer or wsi or window, or sets back to the other size. For example if I do a window-useCursor(true) call it resets. What am I doing wrong? I know it is not a driver issue as this was formerly a Performer app and it works just fine in there with the same system so it has to either be an issue in OSG (I doubt) or an error in how I am setting up the window. 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
Re: [osg-users] OSG and QT example
Hi Benjamin, We have improved Qt integration checked into svn/trunk as part of the new osgQt library. Submissions would be best built upon this new work rather than introducing yet another variation of Qt integration. Cheers, Robert. On Thu, Jan 20, 2011 at 9:42 PM, Benjamin Wasty bennywa...@gmx.de wrote: Hi, I worked on a Qt-widget integration for my university based on the Delta3D files posted earlier by David Guthrie. I made a few changes - mainly to make multi-threaded rendering really work. We'd be willing to make a submission if there's interest. My current version is attached - feedback would be welcome as this is the first time I worked with OSG. Below are some details and open issues: The class QtViewer inherits from osgViewer::Viewer and OSGAdapterWidget. It does some setup and calls frame() in its updateGL() method. Context sharing between Qt and OSG didn't work when OSG was running multi-threaded - in the end (after quite a few hours of debugging) I just 'switched' the two contexts in OSGAdapterWidget - the QGLWidget keeps its original one and the additional one created in threadedInitializeGL() is used by the OSG draw thread (OSGGraphicsWindowQt directs the makeCurrent/doneCurrent()-calls to that context). Improved mapping from Traits/osg::DisplaySettings to QGLFormat Removed QtGuiWindowSystemWrapper and GLWidgetFactory because we don't need them (but only commented out) No rendering when Widget is hidden (otherwise some access violation occurs) One remaining problem is that there is quite a lag when the main window is moved or resized, because Qt apparently doesn't have enough time to render fluently due to the blocking caused by vsync. Increasing the interval for the update timer helps, but reduces the framerate and in my opinion the now used 10ms are already too much. Should the frame()-call maybe moved to a separate thread like there: forum . openscenegraph . org / viewtopic.php?p=17387#17387 ? (2 posts before I can post URLs? I don't have time for that...) A quick test with that code didn't work, but I didn't pursue it further so far. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35820#35820 ___ 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] Upgrade from 1.0.0 to 2.8.2
Hi Mike, I vaguely recall another user having problem with a migration from a very old version of the OSG to a recent, it's a while though so can't remember the exact details. You description makes me think of this case though so I presume there is a connection even if I can't recall the details of the problem or solution. I think it was something pretty straight forward once the issue was located, the solution may have been to do with near/far planes. A search in the archives might bring up some clues. Robert. On Fri, Jan 21, 2011 at 4:16 AM, Mike Hatcher mike.hatche...@yahoo.com wrote: True, I was comparing the osgviewer and osg dumps taken in the different versions. The debug output shows all images, textures, models, and everything loading just fine. They are all found just fine and using readImageFile they are all read with all plugins appear to function correctly but using osgviewer they (textures only) don't appear to be rendered under 2.8.2 but at least sufaces are. However, the larger concern for me at the moment is that in the app, not osgviewer nothing at all appears...no wireframe, no surfaces, nothing but with osgviewer and the osg dump taken while actually running the app, surfaces are rendered. In 1.0.0 everything is there. On 2.8.2 it's all gone...except when using osgviewer and viewing the .osg dump. I think I can probably tackle the issue with textures once I can at least get something displayed on the screen but until then I'm at a total loss! Thank you! Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35827#35827 ___ 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] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi, John Instead of relying on matrix that you get from osg camera, you can use gl_ProjectionMatrix in shaders which is guaranteed to be current projection matrix, this uniform contains all values you need to get linear depth from 0..1 postperspective depth which i belive can be calculated as: float linear_depth = post_perspective_depth * (-gl_ProjectionMatrix[3].z/(post_perspective_depth * (-2.0) + 1.0 - gl_ProjectionMatrix[2].z)) where post_perspective_depth is depth in 0..1 range (i think you can use there gl_FragCoord.z) Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35842#35842 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi Sergey Instead of relying on matrix that you get from osg camera, you can use gl_ProjectionMatrix in shaders which is guaranteed to be current projection matrix, this uniform contains all values you need to get linear depth from 0..1 postperspective depth which i belive can be calculated as: float linear_depth = post_perspective_depth * (-gl_ProjectionMatrix[3].z/(post_perspective_depth * (-2.0) + 1.0 - gl_ProjectionMatrix[2].z)) where post_perspective_depth is depth in 0..1 range (i think you can use there gl_FragCoord.z) This puts a completely different spin on things. I've been fiddling around with OSG depth buffers, textures, cameras etc. to extract the depth data. But presumably I can do all this in the shaders straight from the normal scene view. Is this what you're saying? John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35844#35844 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg widget window rotate
Cheers, that works great. However, the widgets which are added to the window are still being clipped. Is there a similar method for widgets? As i can't seem to find it? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35845#35845 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg widget window rotate
Ah, this only seems to be happening for embedded widgets ... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35846#35846 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi, Forget my prev post. What i mean is if you need linear depth texture why not render it linear right away? Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35847#35847 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Hi, John And regarding your algorithm on linearizing depth, i assume you expect to get (z/far) value, and it will work as expected if you supply it with depth that in range (-1..1). If you use it with values from depth texture you should rescale them to (-1..1) range from initial (0..1) prior to calculating linearized depth. In my posts by linear depth i meant just plain z coord in camera view space. Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35848#35848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg widget window rotate
When rotating a widget is there any way to specify an axis to rotate by? The widget currently rotates around the origin of the widget (bottom left). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35849#35849 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with processing keystokes
Hi,
I have a problem with processing keystokes in osg-viewer window.
I would like to tell about this problem and propound resolution.
First i need to explain what is problem i have:
Assume that you want process ASDW keydown like as in Counter-Strike and F to
flash light.
that you need to do?
you need to create something like
Code:
case osgGA::GUIEventAdapter::KEYDOWN:
switch(ea.getKey())
{
case 'w':
// go forward
break;
...
}
It will work until you need to add crouch.
let's see what will be in this case:
after key is pressed there is message recieved
Code:
case WM_KEYDOWN:
case WM_SYSKEYDOWN :
their handlers do the following:
adaptKey(wParam, lParam, keySymbol, modifierMask);
1. getting a virtual key code
2. converting virtual key code to symbol code
then there is a call of
Code:
getEventQueue()-keyPress(keySymbol, eventTime);
with GUIEventAdapter created inside it, what contain keySymbol
i.e. now to turn flashlight we have to do steps below:
Code:
case osgGA::GUIEventAdapter::KEYDOWN:
switch(ea.getKey())
{
case 'F':
case 'f':
case 'f'-0x40 : // for processing with CTRL
// do something
}
as we don't know whick key is pressed by user, we have to include all
possibilities:
I suggest using virtual keys codes both with current key handles, as the
following:
Code:
adaptKey(wParam, lParam, keySymbol, modifierMask, virtualKey);
...
getEventQueue()-keyPress(keySymbol, virtualKey eventTime);
What do you think about it?
Thank you!
Cheers,
Alexander
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35850#35850
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Z Buffer linearisation and DO_NOT_COMPUTE_NEAR_FAR
Sergey Thanks for your responses. I should be in a position on Monday to try out your suggestions (I'm just battling with porting my nice Eclipse project to Visual Studio 2008 which I'm a bit rusty on). I'll get back to this thread then. Cheers John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35851#35851 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Quat
Hi, From a quaternion, how to get the angle of rotation on each axis? I saw that it exists the function getRotate(...) but it gives the angle according to all axes. Thank you! Cheers, lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35852#35852 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple tex gen modes in a single scene
Brad, It really sounds like texgen stage conflict. You can use up to 8 texgens concurently (stages 0..7). PositionalStates (including TexGens) are apllied at start of render stage and not changed during rendering. So if there are more then one texgen on particular stage, only one will be used (I am not sure which will win the race). If you are sure, texgens are applied on unique stages, check if your shaders use the correct texgen indices. Wojtek -Oryginalna wiadomość- From: Christiansen, Brad Sent: Friday, January 21, 2011 9:29 AM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi, I have a small amount of extra info to add, which confuses me even more. Revisting all my code I discovered that my overlays actualy use two eye linear tex gens (one for close items, one for distant ones, a bit like the parralel split shadow maps) with different matrices and different units. These work fine in isolation, but don't work when I add in the third shadow tex gen. The code that adds the tex gens to the positional state container is almost identical. I am now very confused as to why I can use two tex gens for my overlays but it wont work with shadows added. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: Friday, 21 January 2011 3:47 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Robert, I am currently adding shadows to my scene (which is going well) but in doing so I have hit this issue. I already use an eye linear tex gen in my scene to render overlays (very similar code to the osgSim::OverlayNode). I don't think it would be possible for me to split the renderering accross two different RenderStages as the two tex gens are used from within the same shader to render my terrain (one for applying shadows and the other for applying overlays). I have had a look at the PositionalStateContainer class and I do not understand why the issue exists. The tex gens use different texture units and as such there matrices are stored and applied seperately. However the result I am seeing is one of the two always 'wins' and its matrix is applied to both tex gens. This is an issue I will need to resolve so I am hoping you could provide some more guidance as to what would be the best solution. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, 13 January 2011 6:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Paul, Eye linear glTexGen is positional state, i.e. it's value depends on the current modelview matrix, so has to be treated by the OSG like other positional state like glLight and glClipPlane. All positional state has to be positioned by a positional state node, and for glTexGen this is TexGenNode. During the cull traversal the OSG collects the positional state and binds the TexGen/Light/ClipPlane to modelview matrix at that point in traversal, this binding is done via the PositionalStateContainer, and there is one of these per RenderStage. During the draw traversal the positional state is then applied prior to the traversal of the RenderStage, and fixes each positional state in the appropriate place. While this technique doesn't properly fix the state as required, it does limit you to one position, per stage, you can't have two eye line tex gens/lights/clip planes applied on two separate subgraphs. Object linear TexGen isn't positional state so can be applied in the normal way and you have multiple of these per stage without problem. To have multiple Eye linear TexGen/TexGenNode's you'll need to break the scene up into multiple RenderStage and use the clear mask set to 0 on the subsequent stages so that each stage overlays correctly on the previous one. Other approaches are to write a custom TexGen that you push/pop a custom modelview matrix. I'm afraid both approaches are rather hacky. Robert. On Thu, Jan 13, 2011 at 2:28 AM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- Has anyone ever successfully used multiple TexGen modes (say, EYE_LINEAR and OBJECT_LINEAR) on different objects in the same scene? What is the recommended way to do this in OSG? The TexGenNode has a pointer to a TexGen, and the TexGen has the mode. I assume I should create two TexGens, one OBJECT_LINEAR and one EYE_LINEAR, and two TexGenNodes to reference them, and add the two TexGenNodes to the scene graph. Then, I assume I should attach the same two TexGens as StateAttributes to different Node's StateSets as needed. I am running into some issues with this. If it sounds like I'm doing everything right, I'll post a small example that fails, or dig into the OSG code. More than
Re: [osg-users] Screen Resolution Being Overriden in Twinview
Thank you, thank you, thank you. That worked perfectly. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, January 21, 2011 3:58 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Screen Resolution Being Overriden in Twinview Hi Karl, The issue you are seeing is mostly like the window manager redirecting the request for a full sized window to produce a window that fits one screen. To tell X11 to override the window manage redirect you'll need to set the Traits::overrideRedirect flag to true. Robert. On Thu, Jan 20, 2011 at 10:08 PM, Cary, Karl A. karl.a.c...@saic.com wrote: I am having an issue with screen resolution in Twinview. If I am in clone mode or non twinview, everything is fine. But when I am in twinview otherwise, the screen resolution changes even though I am not telling it to. It is essentially adding an invisible window decoration as that is the size it is changing by. My setup: I have 2 monitors, one is 1280x1024, the other is 1920x1200. I would like my application to show up on the 1280x1024 monitor and it does, just not at 1280x1024. When I create my graphics context, I do the following: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 0; traits-y = 0; traits-width = 1280; traits-height = 1024; traits-windowDecoration = false; traits-windowName = myApp; traits-doubleBuffer = true; traits-sharedContext = 0; osg::DisplaySettings* ds = osg::DisplaySettings::instance(); traits-sampleBuffers = ds-getMultiSamples; traits-samples = ds-getNumMultiSamples(); osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); At this point if I pause my program, the resolution is already wrong. It is starting at 0,0, but it is missing the far right and bottom, about the size of the window decoration border. If I then go through and get the window out of the osgViewer and do a window-setWindowRectangle(0,0,1280,1024), the screen goes full screen again. However any time I do anything at all to the viewer or wsi or window, or sets back to the other size. For example if I do a window-useCursor(true) call it resets. What am I doing wrong? I know it is not a driver issue as this was formerly a Performer app and it works just fine in there with the same system so it has to either be an issue in OSG (I doubt) or an error in how I am setting up the window. Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QOSGWidget and ViewQOSG resize behavior
Thanks for information. When I get the chance, I'll see what I can do with the updated example. Sincerely, flyingcadet -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35858#35858 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget Nutton getData
Hi, I've a for cycle that create various buttons and add to them the callback. I want to pass to button also a string data. I saw some examples and passes it with static string data = test; then in callback addCallback( new osgWidget::Callback(WidgetManager::buttonPress,this,osgWidget::EVENT_MOUSE_PUSH,data) ); The problem is that I want that data is different for every cycle, but it's static, then doesn't change. If I don't flag it static, it retreives an empty string. In my function buttonPress I retrieve my data value with: string *test= static_caststd::string*(ev.getData()); Can you help me? thank you! daniele -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35859#35859 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visibility of point array
Hi, Oliver
Quick and somewhat dirty how-to example attached. File contains custom
osg::Drawable::DrawCallback with some utility stuff and comments on what is
going on and how to use it.
shaders to test against view frustum is:
vertex:
[code]
#version 150 core
in vec3 InstancePosition;
uniform mat4 MVP;
out vec4 OrigPosition;
flat out int objectVisible;
void main(void) {
OrigPosition = vec4(InstancePosition,1.0);
vec4 SSpos = MVP * OrigPosition;
bvec4 outside;
outside.w = SSpos.w0.0;
SSpos = abs(SSpos);
outside.xyz = greaterThan(SSpos.xyz,vec3(SSpos.w,SSpos.w,SSpos.w));
objectVisible = int(!any(outside));
}
[/code]
geometry:
[code]
#version 150 core
layout(points) in;
layout(points, max_vertices = 1) out;
in vec4 OrigPosition[1];
flat in int objectVisible[1];
out vec4 CulledPosition;
void main() {
/* only emit primitive if the object is visible */
if ( objectVisible[0] == 1 )
{
CulledPosition = OrigPosition[0];
EmitVertex();
EndPrimitive();
}
}
[/code]
You will need to add test against depth map to vertex shader and setup depth
texture in code.
Cheers,
Sergey
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35864#35864
#include GL/gl.h
#include osg/Camera
#include osg/GL
#include osg/GLExtensions
#include osg/Drawable
#include osg/io_utils
#include iostream
#define GL_TEXTURE_BUFFER_ARB 0x8C2A
#define GL_GEOMETRY_SHADER0x8DD9
void checkLinkError(GLuint prog, osg::GL2Extensions gl2_ext)
{
GLint status;
gl2_ext.glGetProgramiv(prog, GL_LINK_STATUS, status);
if (status != GL_TRUE) {
std::cerr Failed to link shaders: std::endl;
GLchar log[1];
gl2_ext.glGetProgramInfoLog(prog, 1, NULL, log);
std::cerr log std::endl;
}
}
GLuint loadShaderFromFile(const char* filename, GLenum shaderType, osg::GL2Extensions gl2_ext) {
std::ifstream file(filename);
if (!file) {
std::cerr Unable to open file: filename std::endl;
return 0;
}
char line[256];
std::string source;
while (file) {
file.getline(line, 256);
source += line;
source += '\n';
}
if (!file.eof()) {
std::cerr Error reading the file: filename std::endl;
return 0;
}
GLuint shader = gl2_ext.glCreateShader(shaderType);
gl2_ext.glShaderSource(shader, 1, (const GLchar**)source, NULL);
gl2_ext.glCompileShader(shader);
GLint status;
gl2_ext.glGetShaderiv(shader, GL_COMPILE_STATUS, status);
if (status != GL_TRUE) {
std::cerr Failed to compile shader: filename std::endl;
GLchar log[1];
gl2_ext.glGetShaderInfoLog(shader, 1, NULL, log);
std::cerr log std::endl;
exit(1);
}
return shader;
}
class MyExtensions: public osg::Referenced
{
public:
MyExtensions(unsigned int contextID)
{
if (!osg::setGLExtensionFuncPtr(_glGenBuffers, glGenBuffers ))
if (!osg::setGLExtensionFuncPtr(_glGenBuffers, glGenBuffersARB )) {std::cerrglGenBuffers(ARB) not supportedstd::endl;exit(0);}
if (!osg::setGLExtensionFuncPtr(_glBindBuffer, glBindBuffer )) {std::cerrglBindBuffer not supportedstd::endl;exit(0);}
osg::setGLExtensionFuncPtr(_glBufferData, glBufferData );
osg::setGLExtensionFuncPtr(_glMapBufferRange, glMapBufferRange );
osg::setGLExtensionFuncPtr(_glUnmapBuffer, glUnmapBuffer );
osg::setGLExtensionFuncPtr(_glGenVertexArrays, glGenVertexArrays );
osg::setGLExtensionFuncPtr(_glBindVertexArray, glBindVertexArray );
osg::setGLExtensionFuncPtr(_glEnableVertexAttribArray, glEnableVertexAttribArray );
osg::setGLExtensionFuncPtr(_glVertexAttribPointer, glVertexAttribPointer );
if (!osg::setGLExtensionFuncPtr(_glTexBuffer, glTexBuffer ))
osg::setGLExtensionFuncPtr(_glTexBuffer, glTexBufferARB );
if (!osg::setGLExtensionFuncPtr(_glGenTextures, glGenTextures ))
osg::setGLExtensionFuncPtr(_glGenTextures, glGenTexturesEXT );
if (!osg::setGLExtensionFuncPtr(_glBindTexture, glBindTexture ))
osg::setGLExtensionFuncPtr(_glBindTexture, glBindTextureEXT );
if (!osg::setGLExtensionFuncPtr(_glGenQueries, glGenQueries ))
osg::setGLExtensionFuncPtr(_glGenQueries, glGenQueriesEXT );
if (!osg::setGLExtensionFuncPtr(_glBindBufferBase, glBindBufferBase ))
osg::setGLExtensionFuncPtr(_glBindBufferBase, glBindBufferBaseEXT );
if (!osg::setGLExtensionFuncPtr(_glBeginTransformFeedback, glBeginTransformFeedback ))
if (!osg::setGLExtensionFuncPtr(_glBeginTransformFeedback, glBeginTransformFeedbackEXT )) {std::cerrglBeginTransformFeedback(EXT) not supportedstd::endl;exit(0);}
if (!osg::setGLExtensionFuncPtr(_glEndTransformFeedback, glEndTransformFeedback ))
if(!osg::setGLExtensionFuncPtr(_glEndTransformFeedback, glEndTransformFeedbackEXT )) {std::cerrglEndTransformFeedback(EXT) not supportedstd::endl;exit(0);}
if
Re: [osg-users] Texture Buffer Objects status?
Hi, My simple fragment shader with textureSize() seem to work fine when dealing with a usampler1D uniform (the problem I had at one point was that I was giving a texture that was too big for the driver, hence the size ended up being actually 1, and my test was always failing). tex-setInternalFormat(GL_RGBA8); image-allocateImage((128*128), 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, 1); In my fragment shader: uniform usampler1D tex; My (textureSize(tex, 0) == 16384) test actually does work. When I change my code so that your TextureBuffer is used, somehow, things don't work. - I change the uniform type from UNSIGNED_INT_SAMPLER_1D to UNSIGNED_INT_SAMPLER_BUFFER. - usampler1D becomes usamplerBuffer, textureSize() becomes textureSizeBuffer(). - and of course I create a TextureBuffer and not a Texture1D object. In my GL tracer, I don't see any OpenGL error. I am trying hard to see what is wrong, but so far, I have no idea. And yet, things don't work. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35866#35866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Fred, If you can provide a minimal code example I can test it on my machine and see what's the problem. Otherwise, for me it's impossible to know what's going on and I can only guess. By the way, did you try using GL_LUMINANCE instead of GL_RGBA? Cheers, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Quat
Hi Lucie, What you're looking for is how to convert the quaternion representation of a rotation into the Euler angle representation. Take a look at http://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles for more info and the equations. Alternatively, you can get the rotation about an arbitrary axis this way: 1) Create a unit vector perpendicular to your axis (e.g. (0,1,0) for rotations about the z-axis) 2) Rotate this vector by the quat: rotated = quat * forward_vec * quat.conj() 3) Project the result onto the plane perpendicular to your axis (see http://www.euclideanspace.com/maths/geometry/elements/plane/lineOnPlane/index.htm for info on projecting vectors onto planes) 4) Normalize the result to unit length. 5) Take the dot product between your initial forward vector and this normalized rotated forward vector. 6) Take the inverse cosine to get the angle. Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35869#35869 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVidiaTextureTools integration moved from VPB to OSG
Hi, This may be a dumb question in relation to this thread, but does one still need to employ the Mesa tools to bypass the graphics card when using VPB to build databases with the NVTT? -Shayne -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35871#35871 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Upgrade from 1.0.0 to 2.8.2
On 1/20/2011 9:16 PM, Mike Hatcher wrote: True, I was comparing the osgviewer and osg dumps taken in the different versions. The debug output shows all images, textures, models, and everything loading just fine. They are all found just fine and using readImageFile they are all read with all plugins appear to function correctly but using osgviewer they (textures only) don't appear to be rendered under 2.8.2 but at least sufaces are. However, the larger concern for me at the moment is that in the app, not osgviewer nothing at all appears...no wireframe, no surfaces, nothing but with osgviewer and the osg dump taken while actually running the app, surfaces are rendered. In 1.0.0 everything is there. On 2.8.2 it's all gone...except when using osgviewer and viewing the .osg dump. I think I can probably tackle the issue with textures once I can at least get something displayed on the screen but until then I'm at a total loss! Any number of things could cause your app to render nothing. The only thing I can really suggest is that you use standard debugging techniques to find out what's going wrong. With OSG you have the source code. Sorry I can't be more helpful, but a lot has changed since v1.0. Few people on this list have even been around that long. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVidiaTextureTools integration moved from VPB to OSG
Hi Shayne, On Fri, Jan 21, 2011 at 4:58 PM, Shayne Tueller shayne.tuel...@hill.af.mil wrote: This may be a dumb question in relation to this thread, but does one still need to employ the Mesa tools to bypass the graphics card when using VPB to build databases with the NVTT? VPB still links to OpenGL, virtual of OSG link to it, but you won't need a graphics context at runtime. This means the actual version of OpenGL should be moot, whether you have a software or hardware GL driver won't affect VPB as NVTT will take on the responsibility of doing the GL compression. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Making a Visible Vector with Translating point
Bumping my own thread because I need an answer :( -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35875#35875 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Making a Visible Vector with Translating point
Hi Richard, You seem to have a lot of the pieces already sort of in place. I'm not sure exactly what you're asking... but here goes. To have something render, you want to create an object of class osgViewer::Viewer. Then you need to add data (your scene graph) to the viewer using setSceneData(osg::Node*). In your case, this will be the PositionAttitudeTransform node (vectorOrient), which has the update callback attached and the geode (lineVector1) as a child as you've already done. Then you need to call viewer.run(), or create a loop with viewer.frame() within it. In the callback, it sounds like you want to set the attitude(rotation) of the PAT node. So, instead of calling setPosition(Vec3), you want to use setAttitude(Quat). The Quat class has a makeRotate method which creates a quaternion to rotate from one vector to another. So you want to have two vectors, one which points in the initial direction of the line you want to draw (defined when you created the geometry) and the other which points in the desired direction depending on your dynamic data. Once you have those vectors, do moveVector-setAttitude(osg::Quat::makeRotate(initial_vec, final_vec)). Hope that helps you get started, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35879#35879 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Flocking
i am suppose to implement flocking but im not sure how can anyone help??
Puck. h:
#ifndef PUCK_H
#define PUCK_H
#include osg/Group
#include osg/Geode
#include osg/Geometry
#include osg/ShapeDrawable
#include osg/MatrixTransform
#include iostream
#include osgViewer/Viewer
#include Obstacle.h
using namespace osg;
using namespace osgViewer;
using namespace std;
class Puck
{
public:
Puck(Group *root, Obstacle** obstacles, int ob_count, double x, double
y);
};
#endif
obstacle.h:
#ifndef OBSTACLE_H
#define OBSTACLE_H
#include osg/Group
#include osg/Geode
#include osg/Geometry
#include osg/ShapeDrawable
#include osg/MatrixTransform
#include osgViewer/Viewer
using namespace osg;
using namespace osgViewer;
class Obstacle
{
public:
double x,y;
double radius;
Obstacle(Group *root, double x, double y, double radius);
};
#endif
obstacle.cpp:
#include Obstacle.h
Obstacle::Obstacle(Group *root, double x_pos, double y_pos, double r)
{
x = x_pos;
y = y_pos;
radius = r;
Cylinder *shape=new Cylinder(Vec3(x,y,0),radius,0.1);
ShapeDrawable *draw=new ShapeDrawable(shape);
draw-setColor(Vec4(1,0,1,0));
Geode *geode=new Geode();
geode-addDrawable(draw);
MatrixTransform *T=new MatrixTransform();
T-addChild(geode);
root-addChild(T);
}
puck.cpp:
#include Puck.h
#ifndef M_PI
#define M_PI 3.1415
#endif
class TranslateCB : public osg::NodeCallback
{
private:
double _dx,_dy;
double _dirx,_diry;
double _inc;
double _theta;
double _radius;
double _x,_y;
Obstacle** obstacles;
int ob_count;
public:
TranslateCB() : _dx( 0. ), _dy( 0. ), _dirx(1), _diry(0), _inc(0.2),
_theta(0) {}
TranslateCB(Obstacle** ob, int count, double r, double x, double y) :
_dx( 0. ), _dy( 0. ),
_dirx(2.0*rand()/RAND_MAX-1), _diry(2.0*rand()/RAND_MAX-1),
_inc(0.001), _theta(0)
{ obstacles = ob; ob_count = count; _radius = r; _x = x; _y =
y; }
virtual void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::MatrixTransform* mt =
dynamic_castosg::MatrixTransform*( node );
osg::Matrix mR, mT;
mT.makeTranslate( _dx , _dy, 0. );
mt-setMatrix( mT );
double ob_dirx;
double ob_diry;
double ob_dist;
_theta = 0;
double min = 4;
for(int i = 0; i ob_count; i++)
{
ob_dirx = (_x+_dx) - obstacles[i]-x;
ob_diry = (_y+_dy) - obstacles[i]-y;
ob_dist = sqrt(ob_dirx*ob_dirx+ob_diry*ob_diry);
//normalise directions
double ob_norm = sqrt(ob_dirx*ob_dirx+ob_diry*ob_diry);
ob_dirx = (ob_dirx)/ob_norm;
ob_diry = (ob_diry)/ob_norm;
double norm = sqrt(_dirx*_dirx+_diry*_diry);
_dirx = (_dirx)/norm;
_diry = (_diry)/norm;
//calculate angle between direction travelling, and
direction to obstacle
double angle = acos(_dirx*ob_dirx + _diry*ob_diry);
//calculate closest distance between puck and obstacle
if continues on same path
double min_dist = ob_dist*sin(angle);
if(min_dist _radius + obstacles[i]-radius
ob_dist min+obstacles[i]-radius)
{
min = ob_dist;
if(ob_dist _radius + obstacles[i]-radius){
_theta = 0; }
else if(angle M_PI/2){ _theta = -0.3; }
else{ _theta = 0.3; }
}
}
//change direction accordingly
_dirx = _dirx*cos(_theta) + _diry*sin(_theta);
_diry = _diry*cos(_theta) - _dirx*sin(_theta);
_dx += _inc*_dirx;
if((_x+_dx 10 _dirx 0) || (_x+_dx -10 _dirx 0))
{
_dirx = -_dirx;
_diry += (0.2*rand()/RAND_MAX-0.1); //add
randomness to bounce
}
_dy += _inc*_diry;
if((_y+_dy 10 _diry 0) || (_y+_dy -10 _diry 0))
{
_diry = -_diry;
_dirx += (0.2*rand()/RAND_MAX-0.1); //add
randomness to bounce
}
traverse( node, nv );
}
};
Puck::Puck(Group
Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release
Hi Robert, it compiled without error on Win7 with VS2008+SP1, OSG and VPB with NVTT in both, 32 and 64 bit. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35880#35880 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bad_alloc exception generated
Hi, i just installed OpenSceneGraph and i tried running this piece of code: im getting a bad_alloc exception. Could anyone point where the error is? Thank you! Cheers, Mukund -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35878#35878 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bad_alloc exception generated
Hi Mukund, I believe your post is missing the code you wanted to include. kind regards, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35881#35881 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Screen Resolution Being Overriden in Twinview
Ok this has created a new problem. If I give focus to something other than my application, I cannot gain focus again. And I notice that there is no associated window via Alt+Tab or toolbar. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Friday, January 21, 2011 7:07 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Screen Resolution Being Overriden in Twinview Thank you, thank you, thank you. That worked perfectly. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, January 21, 2011 3:58 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Screen Resolution Being Overriden in Twinview Hi Karl, The issue you are seeing is mostly like the window manager redirecting the request for a full sized window to produce a window that fits one screen. To tell X11 to override the window manage redirect you'll need to set the Traits::overrideRedirect flag to true. Robert. On Thu, Jan 20, 2011 at 10:08 PM, Cary, Karl A. karl.a.c...@saic.com wrote: I am having an issue with screen resolution in Twinview. If I am in clone mode or non twinview, everything is fine. But when I am in twinview otherwise, the screen resolution changes even though I am not telling it to. It is essentially adding an invisible window decoration as that is the size it is changing by. My setup: I have 2 monitors, one is 1280x1024, the other is 1920x1200. I would like my application to show up on the 1280x1024 monitor and it does, just not at 1280x1024. When I create my graphics context, I do the following: osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-x = 0; traits-y = 0; traits-width = 1280; traits-height = 1024; traits-windowDecoration = false; traits-windowName = myApp; traits-doubleBuffer = true; traits-sharedContext = 0; osg::DisplaySettings* ds = osg::DisplaySettings::instance(); traits-sampleBuffers = ds-getMultiSamples; traits-samples = ds-getNumMultiSamples(); osg::ref_ptrosg::GraphicsContext gc = osg::GraphicsContext::createGraphicsContext(traits.get()); At this point if I pause my program, the resolution is already wrong. It is starting at 0,0, but it is missing the far right and bottom, about the size of the window decoration border. If I then go through and get the window out of the osgViewer and do a window-setWindowRectangle(0,0,1280,1024), the screen goes full screen again. However any time I do anything at all to the viewer or wsi or window, or sets back to the other size. For example if I do a window-useCursor(true) call it resets. What am I doing wrong? I know it is not a driver issue as this was formerly a Performer app and it works just fine in there with the same system so it has to either be an issue in OSG (I doubt) or an error in how I am setting up the window. Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Flocking
On 01/21/2011 11:31 AM, john song wrote: i am suppose to implement flocking but im not sure how can anyone help?? I don't have time to debug your code for you, but this site is an excellent reference for steering behaviors like flocking: http://www.red3d.com/cwr/steer/ They also have a library that you can use if you don't want to code it yourself. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVidiaTextureTools integration moved from VPB to OSG
Robert, Thanks for the input. I will try to compile and run the latest trunk with NVTT on Fedora core 13 and report any problems... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, January 21, 2011 10:41 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] NVidiaTextureTools integration moved from VPB to OSG Hi Shayne, On Fri, Jan 21, 2011 at 4:58 PM, Shayne Tueller shayne.tuel...@hill.af.mil wrote: This may be a dumb question in relation to this thread, but does one still need to employ the Mesa tools to bypass the graphics card when using VPB to build databases with the NVTT? VPB still links to OpenGL, virtual of OSG link to it, but you won't need a graphics context at runtime. This means the actual version of OpenGL should be moot, whether you have a software or hardware GL driver won't affect VPB as NVTT will take on the responsibility of doing the GL compression. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bad_alloc exception generated
Hi Roland, Thanks for the reply. Yes, i had some problem with posting the code. i tried editing but editing was disabled since my real name and username was the same. im not able to add code tags. im getting this: You must have 2 posts before you can post URL's/Links. il paste the code in my next post Thanks, Mukund -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35884#35884 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bad_alloc exception generated
Here is the code:
Code:
#include osgViewer/Viewer
#include osgDB/ReadFile
int main( int, char ** )
{
osgViewer::Viewer viewer;
viewer.setSceneData( osgDB::readNodeFile( cow.osg ) );
return viewer.run();
}
Thanks,
Mukund
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35886#35886
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Optimizing scene structure and geometry
Hi all,
I thought I had a pretty firm grasp on what to optimize given a certain
set of scene stats, but I've optimized what I can and I'm still getting
little improvement in results. So I'll explain my situation here and
hope you guys have some good suggestions. Sorry if this is a long
message, but I prefer to give all the relevant data now rather than get
asked later.
The whole scene is about a 200m x 200m square (apart from the ocean and
skydome but these are not significant, I have removed them and confirmed
that the situation is the same). The worst case viewpoint is a flying
view where the whole scene could be visible at once. So I need to
balance culling cost with draw cost, since in some views we will see
only part of the scene (so we should be able to cull away at least part
of what's not visible) and in the flying view everything is visible so
we shouldn't waste too much time doing cull tests which we know will not
cull anything.
The other thing is that there are a lot of dynamic objects, so there are
a lot of transforms. But I can't change this, it's part of our simulation.
So, after doing some optimization (removing redundant groups, building
texture atlases where possible, merging geodes and geometry, generating
triangle strips, most of which I did with the osgUtil::Optimizer), I get
the following stats, which I'll talk about a bit later:
Scene stats:
StateSets 1345
Groups 392
Transforms 672
Geodes 992
Geometry 992
Vertices139859
Primitives 87444
Camera stats:
State graphs 1282
Drawables 2151
PrimitiveSets 73953
Triangles 3538
Tri. Strips 211091
Tri. Fans16
Quads 11526
Quad Strips 534
Total primitives 226705
And, both in our simulator and in osgViewer, for the same scene and same
viewpoint, I get:
FPS: ~35
Cull: 5.4ms
Draw: 19ms
GPU: 19ms
This is on a pretty good machine: Core i7 920, GeForce GTX 260.
First of all, the stats above tell me that the Primitives part of the
scene stats refers to primitive sets, not just primitives... Since the
camera stats tell me there are over 226000 primitives in the current view.
As you can see, the number of primitiveSets is very high. If I
understand correctly, each PrimitiveSet will result in an OpenGL draw
call, and since my draw time is what's high now, I would want to reduce
that (since I'm currently at about 3 primitives per primitiveSet on
average). If I remove triangle strip generation from the optimizer
options, the stats become:
Scene stats:
StateSets 1345
Groups 392
Transforms 672
Geodes 992
Geometry 992
Vertices190392
Primitives 51197
Camera stats:
State graphs 1254
Drawables 2117
PrimitiveSets 4899
Triangles 17122
Tri. Strips 191
Tri. Fans 7212
Quads106464
Quad Strips 534
Total primitives 131523
This indicates to me that the tristrip visitor in the optimizer does a
pretty bad job. I looked at an .osg dump, and it seems to generate a
separate strip for each quad (so one strip for 4 vertices) which is
ridiculous... But that's a subject for another day.
When I disabled the tristripper, you can see a massive decrease in the
number of primitiveSets (and even in the number of primitives), however
there was no significant change in the frame rate and timings. I don't
understand this. I would have expected, with more primitives per
primitiveSet (I'm now at about 26 prims per primSet on average, as
opposed to around 3 before) and much less draw calls, that the draw time
would have been much lower. That's not what happens in practice.
My previous attempts at optimizing (using the osgUtil::Optimizer) were
also centered around lowering the number of primitives (by creating
texture atlases and sharing state so the merging of geodes and geometry
objects gave good results). And even though that also lowered the
numbers (I started at around 2215 Geodes and 2521 Geometry objects in
the same scene, compare that to 992 each now), it also had underwhelming
results in practice.
Clearly there are more than one primitiveSet per Geometry in the above
stats. What I see in the dumped .osg file, is there is often things like:
PrimitiveSets 4
{
DrawArrays TRIANGLES 0 12
DrawArrays QUADS 12 152
DrawArrays TRIANGLES 164 12
DrawArrays QUADS 176 152
}
I would expect, by reordering the vertex/color/normal/texCoord data, I
would be able to get only 2 primitiveSets there, one TRIANGLES and one
QUADS. Am I wrong? Why does the osgUtil::Optimizer not do this already
when merging Geometry objects? I expect because it's easier not to do
it, but still, it gives sub-optimal results...
Of course I can't do that for strips or fans, unless I insert new
vertices to restart the strip. Again this is something that could be
done, but might
[osg-users] Camara: PreDrawCallback and PostDrawCallBack
Hello folks, We have a custom sensor model that we have used for some time with OSG. It provides an FBO for rendering the scene to, processes the captured scene, and then will render the FBO when completed. I would like to change the way we use it in OSG to make it work closer to the osg::Camera class. My first thought was to derive a Camera class and override the applicable functions. At first glance, this appears a bit more involved than I really hoped. While looking at the Class I see (and now remember) Pre and Post draw calls. My big questions are: 1. Is the graphics context bound when these calls are made? (if not, why not) 2. If so, am I allowed to bind my FBO in the pre-draw, and draw in my post draw? Thanks! --- Brad Colbert Renaissance Sciences Corporation ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camara: PreDrawCallback and PostDrawCallBack
I think I answered my own question by just doing it. BTW, it appears that the graphics context is bound and I'm able to capture what the camera see's, process it, and render the processed image. -B -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Colbert Sent: Friday, January 21, 2011 3:51 PM To: 'osg-us...@openscenegraph.org' Subject: [osg-users] Camara: PreDrawCallback and PostDrawCallBack Hello folks, We have a custom sensor model that we have used for some time with OSG. It provides an FBO for rendering the scene to, processes the captured scene, and then will render the FBO when completed. I would like to change the way we use it in OSG to make it work closer to the osg::Camera class. My first thought was to derive a Camera class and override the applicable functions. At first glance, this appears a bit more involved than I really hoped. While looking at the Class I see (and now remember) Pre and Post draw calls. My big questions are: 1. Is the graphics context bound when these calls are made? (if not, why not) 2. If so, am I allowed to bind my FBO in the pre-draw, and draw in my post draw? Thanks! --- Brad Colbert Renaissance Sciences Corporation ___ 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] Upgrade from 1.0.0 to 2.8.2
OK, well thanks for reading and responding to my post. I'm appreciative of the thought. I noticed that all the examples have state code that sets state and textures seem to have to be turned on so to speak. Are they off by default? That may be part of the problem. Thanks for the advice on the clip planes! That is exactly the kind of thing I was hoping for. I will get to work on that and see what I can find out. Thanks again folks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35890#35890 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
