Re: [osg-users] [3rdparty] Rendering into cegui element
Hi Issam, My guess is that the state that the OSG is applying is affecting Cegui. You could try applying a osg::StateSet that contains the state that Cegui is assuming prior to calling Cegui. Robert. On Sat, Dec 18, 2010 at 1:48 PM, issam boughanmi amigof...@gmail.com wrote: well i solved my problem to render into cegui elmement but i am facing another one plesae see the attached image [Image: http://img811.imageshack.us/img811/7510/screenah.jpg ] please note the cegui listbox in the left here my code to create the textitems dynamically Code: AvionsListBox = m_pHUD-GetWidget(AvionsListBox); static_castCEGUI::Listbox*(AvionsListBox)-setMultiselectEnabled(false); ListboxTextItem * listBoxItem = new ListboxTextItem(Cessna 172-p, 1); listBoxItem-setSelectionBrushImage(WindowsLook, MultiListSelectionBrush); static_castCEGUI::Listbox*(AvionsListBox)-addItem(listBoxItem); listBoxItem = new ListboxTextItem(L39 - Albatros. ,2); listBoxItem-setSelectionBrushImage(WindowsLook, MultiListSelectionBrush); static_castCEGUI::Listbox*(AvionsListBox)-addItem(listBoxItem); this is something related to cegui definitivelly but since i got no support on their forum i ask here -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34958#34958 ___ 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] VertexBufferObject usage very slow...
Hi Sean, In general when moving from display listed data to VBO's it's best to avoid using tri-strips with separate osg::DrawElements and instead using a single osg::DrawElements containing just GL_TRIANGLES. This will be more duplicated indices but far less overhead in set up and dispatch. With modern graphics hardware and API the biggest overhead is typically the dispatch rather than vertex load on the GPU. Even mid range GPU's can comfortable handle a million+ vertices per frame at 60hz, but... you have to pass the data to them efficiently, and the bottlenecks we were once familiar with have changed. Robert. On Fri, Dec 17, 2010 at 6:57 PM, Sean Spicer sean.spi...@aqumin.com wrote: Robert, Some more data... Looks like we're drawing approx 100K tri-strips every frame. The glDrawElements call is the culprit...though I'm still baffled by why it is so much slower with VBOs than in immediate mode. Perhaps the drawing isn't sorted by VBO so that all of the triangles drawn from each VBO are draw in single bind call ? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer sean.spi...@aqumin.com wrote: Hi Robert, We are not updating the data frame-to-frame, which is why this is so baffling. I'm working through the issue with gDebugger now - if you don't have any suggestions off the top of your head, then I'll start digging and report back what I find, since I don't have time try and duplicate the issue outside our app. cheers, sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: reproduces the problem you are seeing? ___ 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] Render to texture 3D
Hi Julien,
I haven't personally tested this feature yet, but having merged the
submissions I know that the FACE_CONTROLLED_BY_GEOMETRY_SHADER control
is only available on recent hardware and drivers so check whether this
feature is available on your hardware.
Robert.
On Sat, Dec 18, 2010 at 7:19 PM, Julien Valentin
julienvalenti...@gmail.com wrote:
Hi,
I'm trying to make efficient fluid simulation with osg
I've just found this page :
http://www.mail-archive.com//msg05568.html
It look pretty great as my 1 camera per slice code is very CPU time consuming.
I develop a geometry shader that change gl_layer value per primitive.
It work so i change my texture my texture attachement to camera's FBO as
follow:
Code:
for(int i=0;i_depth;i++){
//one cam per slice
_cameras[i]-attach( osg::Camera::COLOR_BUFFER,tex,0,i,false);
}
to
for(int i=0;i1;i++){
//one overalll camera
_cameras[0]-attach(
osg::Camera::COLOR_BUFFER,tex,0,osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER);
}
But this change make a crash:
Code:
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8da8
Any idea?
Thank you!
Cheers,
Julien[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34962#34962
___
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 problem with multiple cards
Hi John, On Fri, Dec 17, 2010 at 6:43 PM, John Kelso ke...@nist.gov wrote: To summarize: 1) DGL, all OpenGL no OSG used, uses only Producer, no slowdown 2) DGL with OSG, uses SceneView and Producer (no Viewers or Cameras), slowdown observed 3) pure OSG, uses Viewers, Cameras (and eventually SceneView if I read the OSG code correctly), slowdown observed OK, not entirely encouraging finding, but 23 together does eliminate Producer vs osgViewer being the culprit. It would be interesting to try using osgViewer but without any scene graph attached, just using a custom osg::GraphicsOperation attched to the osgViewer::GraphicsWindow and have the osg::GraphicsOperation do the call to OpenGL. This would eliminate Producer vs osgViewer as a contributory factor. In terms of OpenGL vs OSG, I rather surprised that the later is not scaling as well as each context should be working independently, the OSG doesn't add any explictly extra thread serialization at the SceneView or osg::Geometry/Node/State level. The only explicit serialization is the option in osgViewer::Renderer. FYI, the Referenced global mutex that protects the addParent/removeParent() won't affect static scene graphs. When paging it's only in background threads that are likely to thrash addParent/removeParent, the main frame thread should only be one one or two add/removeChild() per frame. In my own testing I've never seen it as a bottleneck, and certainly shouldn't be a factor here. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fullscreen dual monitor spanning
Hi David, On Fri, Dec 17, 2010 at 11:53 PM, David Glenn I took a look at osgViewer::View::setUpViewAcrossAllScreens in View.cpp, did some tests on an example file and with little time I had concluded that it’s not how the width is being set in the windows traits! I have two 1600X1200 monitors and it is seeing it as one 3200X1200 monitor as it should! And that is what it's trying to set the view as that but it's getting bumped back to the 1600X1200 screen size for some reason. My gut felling is it's an OpenGL, or X11 isue! This sounds like the X11 redirect to the X11 window manager that is deciding for you that the window is too big and knows better. The Traits::overrideRedirect as I mentioned earlier in this thread is what should address this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cutting geometry out of a scene
Hi, I'm writing an app that essentially needs to 'cut' some geometry and its textures from a scene, to create a new model. Currently I'm using a PolytopeIntersector to find the faces I'm interested in. The next step is that I need to clip those faces to the boundaries of the Polytope I used to find the intersection. I also need to add some vertices to some of the faces to slightly change the shape. I've been looking at some libraries for geometry operations. I want to preserve the texture mapping if I divide the faces up, and I haven't found a library that I can use to divide the faces and preserve the texture mapping (creating new texture coordinates for the new verts). What I'm wondering is if there is something in OSG already I should be looking at as an example of this type of problem, or if anyone has any hints as to the best way to approach this. I sometimes find myself going down a path to solve a problem the hard way in OSG, then later I find out there's some existing feature I should have used to make life easier. Any tips are very much appreciated! Thanks, Kevin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34975#34975 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cutting geometry out of a scene
On 12/19/2010 12:01 PM, Kevin Bentley wrote: Hi, I'm writing an app that essentially needs to 'cut' some geometry and its textures from a scene, to create a new model. Currently I'm using a PolytopeIntersector to find the faces I'm interested in. The next step is that I need to clip those faces to the boundaries of the Polytope I used to find the intersection. I also need to add some vertices to some of the faces to slightly change the shape. I've been looking at some libraries for geometry operations. I want to preserve the texture mapping if I divide the faces up, and I haven't found a library that I can use to divide the faces and preserve the texture mapping (creating new texture coordinates for the new verts). What I'm wondering is if there is something in OSG already I should be looking at as an example of this type of problem, or if anyone has any hints as to the best way to approach this. I sometimes find myself going down a path to solve a problem the hard way in OSG, then later I find out there's some existing feature I should have used to make life easier. Any tips are very much appreciated! I don't know of an existing OSG-compatible tool for this, but it shouldn't be difficult to implement. Clipping a triangle against a plane is fairly trivial and it sounds like you've already solved that. Use linear interpolation to derive the new texture coordinate; that's what OpenGL does when it clips primitives. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL error 'invalid enumerant' after RenderBin::draw(, )
Hi, I've had some problems getting my OSG applications to render properly. I'm using Microsoft Visual C++ 2010 Express. I've written a very simple application which should simply display a sphere. The code compiles, but when the viewer runs, the sphere doesn't appear and I get the message: Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) I have no idea what this means or how to fix it. I was able to compile and run successfully on a Linux system, but I've had no luck with Windows and Visual C++. Can anybody help me out? ... Thank you! Cheers, Evan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34950#34950 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
