Re: [osg-users] Fullscreen dual monitor spanning
David Glenn writes: Chriss10 wrote: I added eventhandler, but it doesn't work for me! It does not matter how many times I pess 'f', my application will only be shown on one screen. Can somebody help? Other ideas? I think it should be possible to span it over 2 fullscreens. Well I'll tell you what I had to resort to, but it's a hack not a fix. First I render the view to a window (not the whole screen). There is many ways to do that - the examples show you how. Then, when I start things off I resize the window frame a bit beyond the scale of the two screens. This can be done in code but if all else fails, after you start the program resize it with your mouse- I told you it was a hack! Note: Make sure that resize of the window GUI is linked to your OSG resize for this to work! This is the best that I've been able to do in the Linux realm - might work in MS Windows. I use this to render a 3D projection with two Polarized projections and it works, but as I said it's a hack! I'm looking into a more practical solution as time permits – This 3D Projection stuff is more of a hobby scale right now. This is kind of one of those types of subjects that maybe an easy answer, but it's ether just a bit beyond the box to find it in this forum, or beyond the interest of others to answer, or that’s what I’m beginning to think! For me, I’ve done some very weird stuff with this OSG code, much to the puzzlement of some of the OSG authors here and when you do this you sometimes have to stick to your guns and find the answers in other ways and forums! I have to say that it used to work well at least with OSG 2.4.0. Then that misbehaviour appeared, but I don't know if it is a problem with the drivers or with OSG. I think it's more likely a configuration/driver issue since you are the first pinging the list for that, if I recall correctly. The osgViewer::View::setUpViewAcrossAllScreens should be a good starting point to track the issue. In Windows it expands across the screens from the beginning, but the OSG windowing code is different. Regards, -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] background visible on point sprite spheres
Hi Don, Ok, than you can try disabling depth writes while rendering your point sprites. You can use osg::Depth attribute to disable depth writes. For example: _state-setAttribute(new osg::Depth(osg::Depth::LESS, 0.0, 1.0, false)); The last parameter in constructor of osg::Depth controls depth writes during rendering. Best regards, Yurii Monakov 2010/12/16 Yurii Monakov monako...@gmail.com: Hi Don! I think that you can try enabling GL_BLEND mode in your StateSet (if it is not already enabled). Best regards, Yurii Monakov 2010/12/16 Don Leich d...@ilight.com: Hi all, I've got a problem that I haven't been able to find a solution for and could use some help. I'm using the standard texture file OpenSceneGraph-Data/Images/sphere.gif as the source image for point sprites. The file is an image of a shaded sphere against a fully transparent background. I can set a state to properly render small 2-D sphere images with GL_POINTS primitive type. I needed to add sprites to my scene graph after some other content that requires setting a different state first. The point sprites after this other content will show the shaded sphere image correctly, but will now also render the sphere image background even though it should be fully transparent. Adding osg::StateAttribute::OVERRIDE to the blend function state was a thought, but no help. fn-setFunction(osg::BlendFunc::SRC_ALPHA, osg::BlendFunc::ONE_MINUS_SRC_ALPHA); _state-setAttributeAndModes(fn, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON); A dump and compare of .osg files didn't yield any insight. Does anyone have a suggestion for a possible fix here or maybe a way to debug the state with OSG internals? What besides BlendFunc should be in influence here? Does it sound like I'm just not applying the state where I think I am? Thanks, -Don Leich ___ 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, I haven't seen any perfomance slow downs with VBO usage. I've been testing the VBO side pretty heavily over the last week, using paged databases that use VBO's. A VBO vertex array of size 65535 is not particularly large at all and shouldn't present any issues. Are you dynamically updating the data? Would it be possible to create an example datasets or example that reproduces the problem you are seeing? Cheers, Robert. On Thu, Dec 16, 2010 at 11:40 PM, Sean Spicer sean.spi...@aqumin.com wrote: Hi Everyone, Working off the OSG trunk this afternoon, I tried some experiments with VertexBufferObjects and our geometry (all on the fast path). The only deltas in our code are as follows...all timing as measured by OSG stats: geometry-setUseDisplayList(true) geometry-setUseVertexBufferObjects(false) === Draw time = 2ms, FrameTime = 12ms geometry-setUseDisplayList(false) geometry-setUseVertexBufferObjects(false) === Draw time = 13ms, FrameTime= 19ms geometry-setUseDisplayList(false) geometry-setUseVertexBufferObjects(true) === Draw time = 67ms !!! FrameTime = 109ms What is going on here ? We are always on the fast path - however, our vertex arrays are large (65535 verts). VBOs *should* be way faster than immediate mode...any ideas ? sean ___ 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, Steve, et. al, On Tue, Dec 14, 2010 at 7:32 PM, John Kelso ke...@nist.gov wrote: DGL has its own threading and draw code. It uses OpenThreads for threading. The OpenGL calls generated by draw() are sent to the defined windows using OSG's SceneView class and Producer. So, it's not completely OSG-free, but as its threading works, perhaps this indicates that the OSG problem is not in SceneView. I'm I reading this correctly. You are using Producer and SceneView, and only a custom OpenGL call to the rendering? I wouldn't expect any performance issues due to straight OpenGL dispatch or SceneView, the scene graphs job is make sure there aren't issues, and will typically far out perform a naive OpenGL program. Most likely culprit would be at the high level - creating graphics windows and synchronization of the threads and swap buffers. This would lead me to ask question could the difference be Producer vs osgViewer? Both are pretty similar in window setup and threading when running CullDrawThreadPerContext is very similar to that of Producer's multi-thread approach. Events are handled a little differently, but this won't be a factor for performance. The only real difference I can recall is that the osgViewer uses a barrier at the end of dispatch and before the call swap buffers, while Producer just dispatches swap buffers independently and then joins a barrier afterwards. Is there any chance that this is the issue? I'd be easy to move the barrier. Unfortunately I've got my head down looking at paging issues right now so can't head off to start testing multi-card setup. 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. I use Matrox Dual Head 2 Go for 2 fullscreens 2010/12/17 Alberto Luaces alua...@udc.es: David Glenn writes: Chriss10 wrote: I added eventhandler, but it doesn't work for me! It does not matter how many times I pess 'f', my application will only be shown on one screen. Can somebody help? Other ideas? I think it should be possible to span it over 2 fullscreens. Well I'll tell you what I had to resort to, but it's a hack not a fix. First I render the view to a window (not the whole screen). There is many ways to do that - the examples show you how. Then, when I start things off I resize the window frame a bit beyond the scale of the two screens. This can be done in code but if all else fails, after you start the program resize it with your mouse- I told you it was a hack! Note: Make sure that resize of the window GUI is linked to your OSG resize for this to work! This is the best that I've been able to do in the Linux realm - might work in MS Windows. I use this to render a 3D projection with two Polarized projections and it works, but as I said it's a hack! I'm looking into a more practical solution as time permits – This 3D Projection stuff is more of a hobby scale right now. This is kind of one of those types of subjects that maybe an easy answer, but it's ether just a bit beyond the box to find it in this forum, or beyond the interest of others to answer, or that’s what I’m beginning to think! For me, I’ve done some very weird stuff with this OSG code, much to the puzzlement of some of the OSG authors here and when you do this you sometimes have to stick to your guns and find the answers in other ways and forums! I have to say that it used to work well at least with OSG 2.4.0. Then that misbehaviour appeared, but I don't know if it is a problem with the drivers or with OSG. I think it's more likely a configuration/driver issue since you are the first pinging the list for that, if I recall correctly. The osgViewer::View::setUpViewAcrossAllScreens should be a good starting point to track the issue. In Windows it expands across the screens from the beginning, but the OSG windowing code is different. Regards, -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Maxim Gammer ___ 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
On Thu, Dec 16, 2010 at 3:50 PM, Christina Werner werner...@fh- Can somebody help? Other ideas? I think it should be possible to span it over 2 fullscreens. I don't know what OS you are working with. Often OS's have the drivers control how the desktop and windows open up on. I'm only really familiar with X11, in which case the window manager can redirect windows that an application asks to be opened up across the whole desktop to just appear on one of the screens. In this case you want to tell the OSG to tell X11 to override this redirect, in osg::GraphicsContext::Traits you'll find an overriderRedirect flag which need to set to true. You'll also need to set up X11/OpenGL drivers so that it uses a single desktop rather than have separate Displays, for NVidia this is called TwinView. If you can't achieve a single graphics window across both displays the OSG still allows you to open up two separate windows and have them synchronized so that it looks and behaves like a single window. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Native Windowing recursion (WM_NCHITTEST, et al)
Greetings, all. I've been cleaning up my application, and, somehow, this has triggered a StackOverflow situation. I'm working on Windows XP, and have been working with OSG 2.6. In attempting to deal with the problem, I've updated to 2.8.3, and find that the problem persists. The symptom is that WM_NCHITTEST (0x0084) is causing infinite recursion. I've read the forum topics that match WM_NCHITTEST, but none of those seem to apply. Specifically, the call stack tells me that user32.dll (I'm not currently loading symbols for user32) calls: osgViewer::WindowProc, which calls osgViewer::GraphicsWindowWin32::handleNativeWindowingEvent. _windowProcedure is set, so that calls user32.dll CallWindowProc, which produces a call stack of three more user32 calls, which then calls osgViewer::WindowProc, and the recursion continues to Stack Overflow. Hmmm, on recreating the error, to capture the call stack for you, the uMsg this time isn't WM_NCHITTEST, but rather 0x000e (WM_GETTEXTLENGTH). (The StackOverflow is the same.) While I wait for a response, I'll look into loading the symbols for user32.dll. In case it sheds any light on the problem, I'll describe my cleanup. When I first employed osgViewer::Viewer, I completely misunderstood how to (correctly) apply Cameras and ViewManipulators. I wove a complex mechanism on top of osgViewer::Viewer managing the camera for each ViewManipulator and blah, blah, blah. As I've come to understand the viewer better, I have realized that, for the most part, it handles all that for me. So, I've been untangling that mess, and simplifying my derivative of Viewer. And that has gone quite well (except for the above problem). One of the things that I'm doing more of (but simpler) is more frequent use of setCamera and setCameraManipulator, to intentionally switch views (under user control). Thank you, Phil Tessier ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Native Windowing recursion (WM_NCHITTEST, et al)
Addendum: Having loaded the symbols for user32.dll, the call sequence is: osgViewer::WindowProc, which calls osgViewer::GraphicsWindowWin32::handleNativeWindowingEvent. _windowProcedure is set, so that calls user32.dll CallWindowProcA user32.dll IsWindowUnicode user32.dll GetDC user32.dll GetDC, which then calls osgViewer::WindowProc, and the recursion continues to Stack Overflow. -Original Message- From: Tessier, Philip A (TASC) Sent: Friday, December 17, 2010 9:56 AM To: 'osg-users@lists.openscenegraph.org' Subject: [osg-users] Native Windowing recursion (WM_NCHITTEST, et al) Greetings, all. I've been cleaning up my application, and, somehow, this has triggered a StackOverflow situation. I'm working on Windows XP, and have been working with OSG 2.6. In attempting to deal with the problem, I've updated to 2.8.3, and find that the problem persists. The symptom is that WM_NCHITTEST (0x0084) is causing infinite recursion. I've read the forum topics that match WM_NCHITTEST, but none of those seem to apply. Specifically, the call stack tells me that user32.dll (I'm not currently loading symbols for user32) calls: osgViewer::WindowProc, which calls osgViewer::GraphicsWindowWin32::handleNativeWindowingEvent. _windowProcedure is set, so that calls user32.dll CallWindowProc, which produces a call stack of three more user32 calls, which then calls osgViewer::WindowProc, and the recursion continues to Stack Overflow. Hmmm, on recreating the error, to capture the call stack for you, the uMsg this time isn't WM_NCHITTEST, but rather 0x000e (WM_GETTEXTLENGTH). (The StackOverflow is the same.) While I wait for a response, I'll look into loading the symbols for user32.dll. In case it sheds any light on the problem, I'll describe my cleanup. When I first employed osgViewer::Viewer, I completely misunderstood how to (correctly) apply Cameras and ViewManipulators. I wove a complex mechanism on top of osgViewer::Viewer managing the camera for each ViewManipulator and blah, blah, blah. As I've come to understand the viewer better, I have realized that, for the most part, it handles all that for me. So, I've been untangling that mess, and simplifying my derivative of Viewer. And that has gone quite well (except for the above problem). One of the things that I'm doing more of (but simpler) is more frequent use of setCamera and setCameraManipulator, to intentionally switch views (under user control). Thank you, Phil Tessier ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight Export - MultiTexturing - wrong Texture Coordinates
On 12/17/2010 9:13 AM, Katharina Plugge wrote: Hi, MultiTexturing has still its problems. Now I tried the first time to use up to 3 textures. Converting to flt again lead to corrupted texture coords. I attached an osg-file which can be used to reproduce the problem. Converting this file to flt shows the effect. Unfortunatly this time I have no idea what goes wrong. In FltExportVisitor::writeUVList the texture coords for both channels are determined correctly and written to _records. Somehow the texture coordinates have to be corrupted later. In the resulting file texture coords from channel one are mixed up with those from channel 2 and vice versa. Would be great, if someone could help here. OK, I will try to take a look. I might have some time to dig in over the next couple weeks. Thanks for posting the test file. -- -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
Re: [osg-users] Fullscreen dual monitor spanning
Greetings All! I checked out the OpenGL forum at Khronos and they suggested to me the save hack that I dreamed up! Grin! Furthermore, I found out that this is the same solution for X11 and MS Windows - including Windows7! I know that I complained to Autodesk the other day about Spanning screens with my Maya2011 and they told me that you cannot max-out on two windows. You have to just drag it out with your mouse. QT says you can't do it without a hack - still wating for that hack, Nokia! Maybe, as Robert is suggesting, that it was a function that you could have done and now you can’t! I'm Sorry if it seems to look like I'm bucking ageist the system here! But “Hay”, if I remember right, that what my Bosses pay me to do! =D FYI: I'm still stuck using in RedHat 5.2 (thanks to Government) X11 and a (most likely dated) gnome Windows Manager! Anyways,... * ^ ^^^ ^ || --- You all have some Happy Holidays! D Glenn D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34941#34941 ___ 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 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
Re: [osg-users] OSG problem with multiple cards
Hi Robert, Based on your question I went back and did some grepping through the DGL codebase and I see that DGL does NOT use SceneView or any other OSG code. It simply uses Performer. I was mistaken when I said earlier than DGL uses SceneView. There is an OSG layer that can be used with DGL to allow OSG programs to work with DGL, and it is this layer that uses SceneView. It does not use the OSG Viewer or Camera classes. This might be helpful: While a non-OSG DGL program does not show the slowdown when using multiple displays, an OSG program using DGL DOES show a slowdown similar to what we see with the pure OSG program. 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 I apologize that my original posting was incorrect, and I hope it didn't cause anyone to go down the wrong rabbit hole. Thanks, John On Fri, 17 Dec 2010, Robert Osfield wrote: Hi John, Steve, et. al, On Tue, Dec 14, 2010 at 7:32 PM, John Kelso ke...@nist.gov wrote: DGL has its own threading and draw code. It uses OpenThreads for threading. The OpenGL calls generated by draw() are sent to the defined windows using OSG's SceneView class and Producer. So, it's not completely OSG-free, but as its threading works, perhaps this indicates that the OSG problem is not in SceneView. I'm I reading this correctly. You are using Producer and SceneView, and only a custom OpenGL call to the rendering? I wouldn't expect any performance issues due to straight OpenGL dispatch or SceneView, the scene graphs job is make sure there aren't issues, and will typically far out perform a naive OpenGL program. Most likely culprit would be at the high level - creating graphics windows and synchronization of the threads and swap buffers. This would lead me to ask question could the difference be Producer vs osgViewer? Both are pretty similar in window setup and threading when running CullDrawThreadPerContext is very similar to that of Producer's multi-thread approach. Events are handled a little differently, but this won't be a factor for performance. The only real difference I can recall is that the osgViewer uses a barrier at the end of dispatch and before the call swap buffers, while Producer just dispatches swap buffers independently and then joins a barrier afterwards. Is there any chance that this is the issue? I'd be easy to move the barrier. Unfortunately I've got my head down looking at paging issues right now so can't head off to start testing multi-card setup. Robert.___ 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...
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
Re: [osg-users] OSG problem with multiple cards
Oops!!! In the below, It simply uses Performer. should have read It simply uses Producer. Performer is not involved with this problem in any way. 8^) John On Fri, 17 Dec 2010, John Kelso wrote: Hi Robert, Based on your question I went back and did some grepping through the DGL codebase and I see that DGL does NOT use SceneView or any other OSG code. It simply uses Performer. I was mistaken when I said earlier than DGL uses SceneView. There is an OSG layer that can be used with DGL to allow OSG programs to work with DGL, and it is this layer that uses SceneView. It does not use the OSG Viewer or Camera classes. This might be helpful: While a non-OSG DGL program does not show the slowdown when using multiple displays, an OSG program using DGL DOES show a slowdown similar to what we see with the pure OSG program. 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 I apologize that my original posting was incorrect, and I hope it didn't cause anyone to go down the wrong rabbit hole. Thanks, John On Fri, 17 Dec 2010, Robert Osfield wrote: Hi John, Steve, et. al, On Tue, Dec 14, 2010 at 7:32 PM, John Kelso ke...@nist.gov wrote: DGL has its own threading and draw code. It uses OpenThreads for threading. The OpenGL calls generated by draw() are sent to the defined windows using OSG's SceneView class and Producer. So, it's not completely OSG-free, but as its threading works, perhaps this indicates that the OSG problem is not in SceneView. I'm I reading this correctly. You are using Producer and SceneView, and only a custom OpenGL call to the rendering? I wouldn't expect any performance issues due to straight OpenGL dispatch or SceneView, the scene graphs job is make sure there aren't issues, and will typically far out perform a naive OpenGL program. Most likely culprit would be at the high level - creating graphics windows and synchronization of the threads and swap buffers. This would lead me to ask question could the difference be Producer vs osgViewer? Both are pretty similar in window setup and threading when running CullDrawThreadPerContext is very similar to that of Producer's multi-thread approach. Events are handled a little differently, but this won't be a factor for performance. The only real difference I can recall is that the osgViewer uses a barrier at the end of dispatch and before the call swap buffers, while Producer just dispatches swap buffers independently and then joins a barrier afterwards. Is there any chance that this is the issue? I'd be easy to move the barrier. Unfortunately I've got my head down looking at paging issues right now so can't head off to start testing multi-card setup. Robert.___ 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 modify textures of an .IVE
We are currently using version 2.8.1 of OSG, so what I am about to say may not jive with the version you are using. 1) Look to the console. The console should give you plenty of information on errors that may be going on inside code. If you see nothing, try changing the environment variable OSG_NOTIFY_LEVEL to the highest setting (DEBUG_FP). 2) When the OSG converts the models, the texture path is stored in the stateset with the texture. The issue here, though, is that some programs that produce the model store the texture as an absolute path. This can be quite problematic as the same directory structure is required to be known. Relative paths are a bit better, but I'm not sure if textures that are created and used from different directories will actually generate those directories for you during the conversion process. 3) With those two things stated, you may or may not get a file produced. Don't be fooled into thinking that the file can be used by GIMP just yet. Was the image compressed when creating the IVE? In the case of all our models, the file is compressed during the conversion process. When the image comes back out, it still uses the image path name stored in the stateset to write the texture to disk. In our case, this was RGB, but the image was a compressed format that needed to be DDS. This is another issue you may face. For me, knowing that all the images were compressed, I just locally modified the code to always replace the RGB file extension to DDS. There may be an easier way of doing this, but I didn't spend lots of time trying to figure it out. Just need the textures. Hope this helps and good luck. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34946#34946 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] MS Kinect - official drivers available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2010 11:25 AM, Torben Dannhauer wrote: Hiho, I thought this might be interesting for some of you: The manufacturer of Microsofts Kinect Sensor released a official driver package for linux and windows! you can download and read the spects on http://www.openni.org Actually, to be accurate - OpenNI has nothing to do with Kinect manufacturer (which is Microsoft). It is an initiative to promote natural interfaces and PrimeSense (the manufacturer of one of the chips in Kinect, not Kinect itself!) is only one partner. I think Willow Garage (the guys behind OpenCV) are more relevant there. The library is not really a Kinect driver, but a toolkit/framework to support different trackers for interaction/motion capture. Interesting nevertheless. If you want just pure driver, then Freenect is probably simpler choice. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iD8DBQFNC85Xn11XseNj94gRApGwAKCNCDFmI74EYRZgcNLhiAiAi8TxvwCfcjKN 6yoSwdnL5AevOEuUkukWLzM= =hiqi -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] MS Kinect - official drivers available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/2010 11:39 PM, dimi christop wrote: Are you sure these drivers work for the Kinect. On the site it states that it only works with a Primesense camera. And although its the same company that produced both the Primesense camera and gave the design for XBox Kinect, Can you just plugin the Kinect and use the drivers as is? Or does it only work as stated on the site with a Primesense camera. Which by the way looks very much like the kinect.. http://www.primesense.com/?p=514 I think that is their more pro product. Kinect uses the chip from PrimeSense, but there are other things in it as well - microphone, motor for moving the whole head, etc. At the very least the USB ids are going to be different. But there is a free driver for Kinect already, no need to hack this one. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iD8DBQFNC87zn11XseNj94gRAjtHAKCvQeA5yUshugznnpZM5ISB8w/QCwCgzTtj RA2+WvKvrLCRHxhyZBSL094= =nm87 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] MS Kinect - official drivers available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/2010 08:09 AM, Torben Dannhauer wrote: Hello Dimi, the driver ist NOT provided by Microsoft, but by Primesense, the producer In my opinion Microsofts attitude towards the Kinect drivers is just a good face to the matters. Kinect was hacked, and they had to decide whether they pursue the modifications or to allow them and open Kinect for further usage beyond XBox. I personally was very surprised that the decided to do the latter - Microsoft isn't an example of good open source cooperation for me. Well, they didn't have much choice there - there are no laws that forbid you with using your controller on another OS and since no copyright was broken, they couldn't use something like the American DMCA or similar to quash the efforts like they routinely do with the various modchip sellers/developers. I guess they realized they have no legal leg to stand on and backed down to save their face. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iD8DBQFNC8/An11XseNj94gRAkvlAJ4iCLyk6r1CWWxkfcufjKeNnTplJQCeKoF1 oSq3fdzoSgGjKWrvautaaDo= =7rBo -END PGP SIGNATURE- ___ 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
Holiday Greetings All! Alberto Luaces wrote: I have to say that it used to work well at least with OSG 2.4.0. Then that misbehaviour appeared, but I don't know if it is a problem with the drivers or with OSG. I think it's more likely a configuration/driver issue since you are the first pinging the list for that, if I recall correctly. The osgViewer::View::setUpViewAcrossAllScreens should be a good starting point to track the issue. In Windows it expands across the screens from the beginning, but the OSG windowing code is different. Regards, -- Alberto ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum 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! That was all I could do over my lunch break. I'm back to Mouse Manipulator hacking agean for now. If I can devote more time later, I will. * ^ ^0^ ^0^0^ || --- You all have some Happy Holidays! D Glenn D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34953#34953 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How can I change the colour(RGBA) of material?
Hi, I have a model created by 3dmax.The model contains many objects which already have color or textures.I want to change the color of the model. I have tried the method to change the material,but it dosen't work well.My code is: Code: osg::ref_ptr osg::StateSet stateset=new osg::StateSet(); stateset=model1-getOrCreateStateSet(); stateset-setMode(GL_BLEND,osg::StateAttribute::OFF|osg::StateAttribute::OVERRIDE); osg::ref_ptrosg::Materialmaterial=new osg::Material(); material-setDiffuse(osg::Material::FRONT_AND_BACK,osg::Vec4(1.0,0.0,0.0,1)); material-setAmbient(osg::Material::FRONT_AND_BACK,osg::Vec4(1.0,0.0,0.0,1)); material-setSpecular(osg::Material::FRONT_AND_BACK,osg::Vec4(1.0,0.0,0.0,1)); material-setEmission(osg::Material::FRONT_AND_BACK,osg::Vec4(1.0,0.0,0.0,1)); material-setShininess(osg::Material::FRONT_AND_BACK,0); material-setTransparency(osg::Material::FRONT_AND_BACK,0.5); material-setAlpha(osg::Material::FRONT_AND_BACK,0.5); stateset-setAttribute(material.get(),osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE); Oringinal model: [img] http://photo.163.com/d3d3d353/big/#aid=215946288id=6638799033 [/img] result: [img] http://photo.163.com/d3d3d353/big/#aid=215817442id=6638797425 [/img] As you can see from the picture,the color of the model is not uniformly red(osg::Vec4(1.0,0.0,0.0,1)),and also the alpha channel of some part of the model don't change to 0.5(when I get a screenshot to read the alpha channel).How can I deal with that? Thank you! Cheers, Duan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34955#34955 ___ 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
up, (It's so bad it doesnt work) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34956#34956 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
