Re: [osg-users] Shader composition, OpenGL modes and custom modes
Very excited about the new features Robert, sounds like you're really cracking
on.
I had two thoughts I hope you'll consider integrating:
One is that GLSL is quite poor for initialization. The main problem with this
is if you were to enable a shader with, say, 8 uniforms, there wasn't, until
very recently, a way to initialize them, and the stateset enable calls
generally are single parameter. So in with the definitions of a new possible
shader mode, and the attributes/uniforms it needs, we will probably need a way
to initialize any uniforms that the shader needs, but the user may not
specifically set. Default values, in essence, but also just non-random values.
Second is that, although your point about trying linking on the fly and then
seeing what happens is a good one, I'm worried about the fact that different
GPUs, drivers, OS's etc have very different costs for this, (all of which would
be too much in some circumstances).
I was thinking that we could maybe build in the ability to use a conditional in
each shader as a matter of course. That way the program object can be left as
is, and sorted correctly, and the conditional uniform set instead of
re-linking. The comparable mechanism to me is the 'dynamic' setting of nodes,
or the 'useDisplayLists' setting.
So for example, instead of just:
vec4 applyBlur (vec4 inPixel
{
return inPixel;
}
or
vec4 applyBlur (vec4 inPixel)
{
vec4 outPixel;
// do costly blur
return outPixel;
}
the non-placeholder version might have:
vec4 applyBlur (vec4 inPixel)
{
if (!blurEnabled)
return inPixel;
vec4 outPixel;
// do costly blur
return outPixel;
}
I hope you see the advantages - far more shader sharing and less compilation in
a complex situation.
Bruce
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and vsync (UNCLASSIFIED)
On Jun 23, 2010, at 3:35 PM, Bunfield, Dennis AMRDEC/AEgis wrote: For Nvidia cards there is a built in 2 frames of latency. So even after your sync you won't see the image you updated come out the DVI until 2 render frames later. Where does this information come from Dennis? Where is this delay happening? I doubt it's triple buffering, since the extra memory would have to be accounted for, and it makes tearing mostly impossible (as on the Mac). So you believe the Gl command queue is buffered/delayed somewhere? Doesn't that have huge implications for things like glGet, making them impossible to use without at least halving the frame rate? Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and vsync (UNCLASSIFIED)
Thanks for the info Dennis, I'll take a look at your paper too. Just surprised the latency can be that much, but it really explains why glGet's are quite so awful! Bruce On Jun 28, 2010, at 11:38 AM, Bunfield, Dennis AMRDEC/AEgis wrote: Classification: UNCLASSIFIED Caveats: FOUO Yes we found this through internal testing. Nvidia later confirmed it. This isn't related to double or triple buffering either. The pipeline as explained to me is similar to a break line in a car. Everything works well unless you inject an air bubble into the brake line. This would be similar to doing certain glGet's commands. The driver will tell the GPU to stop it's processing so that it can handle your glGet request. So for real-time programming you really need to be aware of this -- and don't do it --. Depending upon the type of readback you are performing you will introduce a momentary lag in the system because the GPU has to stop everything it is doing to respond back to you. glReadPixels behaves a little differently as long as the pixel format aligns with the frame buffer format where the driver can just dma that framebuffer back to the cpu. If your pixel formats are not aligned you will get bad performance again, because the GPU will have to stop what it is doing and reformat the data to send back. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bruce Wheaton Sent: Monday, June 28, 2010 12:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED) On Jun 23, 2010, at 3:35 PM, Bunfield, Dennis AMRDEC/AEgis wrote: For Nvidia cards there is a built in 2 frames of latency. So even after your sync you won't see the image you updated come out the DVI until 2 render frames later. Where does this information come from Dennis? Where is this delay happening? I doubt it's triple buffering, since the extra memory would have to be accounted for, and it makes tearing mostly impossible (as on the Mac). So you believe the Gl command queue is buffered/delayed somewhere? Doesn't that have huge implications for things like glGet, making them impossible to use without at least halving the frame rate? Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g Classification: UNCLASSIFIED Caveats: FOUO ___ 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] Shader composition, OpenGL modes and custom modes
On Jun 25, 2010, at 6:42 AM, Mathias Fröhlich wrote: With that proposal - espcially the StateAttribute::compose call working directly on the osg::State - I conclude that we need to relink during draw: * we will probably loose state sorting for the shader combinations * shaders need to be at least relinked on every state change which will have some runtime (drawtime) overhead. Actually, I was thinking of something more sophisticated: Use shader linking and/or conditional compilation/string concatenation for shaders that are defined ahead of time. Use conditional if/then statements for attributes that are declared as dynamic. That way you can sort on the shader, just set the uniforms (including the ones used for conditional switches) per use, and you also minimize re-compilation and/or re-linking. This should probably be selectable back-end behavior, in the same way that display lists are now. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] ffmpeg plugin on osx
Has anybody compiled ffmpeg sucessfully to work with osg-2.8.3-rc2? When building the osgmovie example I keep getting the attached linker errors no matter how I seem to compile ffmpeg. I tried both i386 and x86_64, building everything from scratch. I have a feeling though the ffmpeg configure script is ignoring the arch flag or I am doing it wrong. Stefan, what system are you compiling on? 10.6 or 10.5? Compiling 32 bit ffmpeg on 10.6 is a cross-compilation at best. I've had no luck getting a usuable 10.5 binary with an ffmpeg compiled on 10.6. Here's some flags to look at: --extra-cflags=-arch i386 --extra-ldflags='-arch i386' --arch=x86_32 --target-os=darwin --enable-cross-compile Bruce -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29391#29391 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render graphics for 3DReady-TV?
May not be so bad. HDMI and BluRay are standardizing on a 'top-bottom' format, with 2 1280x720 eye images and a 30 pixel border. There may also be a flag that has to get set in the HDMI stream, that will be awkward, but making the top-bottom 3D should be trivial. Possibly some of the TVs will have a switch to tell the TV the content is 3D, or possibly, the strange resolution will tell it to switch to 3D mode. Bruce -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29335#29335 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader composition, OpenGL modes and custom modes
So, we would do the same enable calls on state sets with custom made enums, and then also provide a shader function that will be used only if that feature is enabled? It sounds like a great idea... although isn't it maybe sufficiently useful that it deserves it's own enable and set functions, especially if all the enums are custom? Then name collisions won't be a problem. The more I think about it though, the more it does seem like enable/disable and set value is a good fit. The there could also be different backend methods to create the final shader - by compilation if there's enough time, or by conditional if the graphics system does it quickly enough... One worry might be the implication that every single 'building block' could be dropped in and things will still work. I have a number of shader pieces that only work in the context of a bunch of other shader pieces being active, along with the correct textures etc etc. It's definitely intriguing. Bruce -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29334#29334 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using a texture as an Alpha Mask for the whole screen
I need to use a texture, rendered with geometry, as a mask (with transparency levels) for other operations. It's for a transition - let's say a fullscreen wipe effect to be understandable. So the flow will go (in an openGL sense, at least): - Draw some layers into framebuffer, with alpha blending per layer, - Clear depth, set a blending factor - Draw more layers over, using each layers alpha, the blend factor, and the mask as an overall 'stencil'. So the layers could be fading on while a wipe is happening, for instance (by animating the mask). I think I've worked out how I would do it in OpenGL terms - render into a screen sized FBO, then use that as a texture in all the other operations with a shader that uses that texture as a master mask. Are there any OSG mechanisms to make this easier? Any current examples? I found an old link saying osgPlanets uses an alpha mask, but now it seems to use lighting for the same purpose. A side topic - in researching, I discovered that rendering your whole scene into an FBO is problematic because there's no real alpha blending. There's some OSG examples that do this - osgPrerender, for example. Any tricks to work around this? Ping-ponging 2 FBOs springs to mind, but that sounds really painful. Regards, Bruce Wheaton PS - Note this isn't basic multitexturing - the alpha mask has to be rendered into the scene with geometry and blending also - in fact I will probably use the alpha of one or more layers that will also be used in the visible drawing pass. Probably best to think of the mask as a complete other pass of a branch/scene, with it only making a mask. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo basic question
On May 12, 2010, at 8:19 AM, rah...@vizexperts.com wrote: Sorry for the wrong way of posting thread guys. It's not the wrong way of posting, it's the wrong way to send an email. You'd be best off breaking that habit before you send the wrong thing to the wrong person by accident. Not cool. Why do we need 120 hz for stereo rendering for visual simulation applications ? 120 Hz is used for frame sequential formats, and gives you full 60 Hz information to each eye. Without full 50-60 Hz, motion isn't as smooth without using expensive techniques like motion blurring. It's especially true for frame sequential stereo 3D, since you'd also get unpleasant flickering at lower rates. More to the point, this has become somewhat of a standard in projectors - it's close to the current limit of dual-link DVI (at 1920x1080) and fast enough to avoid artifacts. Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Two Pass Rendering?
What's the preferred way to do this? I need to separate a shader into an H and V pass. I suppose I could double the scene in the graph, but since the first pass needs to be to a texture that wouldn't do it, would it. So I suppose I need another camera with an FBO using the same scene - render to that with my H shader, then use that plus all the new FBO as the source for the final pass? That seems odd to me, since a lot of the objects might be partially obscured in the first pass. Do I need to use an interim texture/camera for each object? Is there an example doing this? I understand it's a favorite way to do glows. regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question on OSX frameworks
Martins, I was under the impression that the projects were 'partial' in this way so you had an option of installing OSG frameworks. What I do, to make standard, distributable examples, is: Add a build stage to the target you're building, a 'Copy Files' stage. Set the destination to 'Frameworks'. Go up to products and pick it, in the top right contents pane, you should see all the Frameworks. Drag the OpenThreads, OSG, OSGViewer, OSGDB and any other frameworks you need into your copy stage - make sure you have OpenThreads plus all the frameworks the targets you linked to. Now make a Copy Files stage set to 'Plugins'. Go and find all the osgdb_xxx products. Drag any of these you might need into that stage. Be aware that some of them, if used in an OSG file, may need additional frameworks, even if the app didn't. Now build the example app. You'll end up with all the libraries you need being copied into it. Bruce On Apr 23, 2010, at 11:12 AM, Martins Innus wrote: Hello, I've been using the frameworks generated by the latest CMake updates in my own projects under osx, and it works great. However it doesn't seem like its working for the osg provided applications. I build the frameworks and application bundles using svn from yesterday. Then when i run osgviewer i get: dyld: Library not loaded: @executable_path/../Frameworks/ OpenThreads.framework/Versions/2.5.0/OpenThreads Referenced from: /util/osg/svn64/bin/osgconv.app/Contents/MacOS/ osgconv Same thing with osgconv, etc The path appears correct, but the frameworks are not being copied into the application bundle during the install stage i guess. In my own project, I just add a copy Files build stage to copy the frameworks to the application bundle. I'm not sure how to do that under CMake though for OSG itself. Has any body else run into this or is there something misconfigured on my machine? Thanks Martins ___ 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] Multi screen VSync Linux NVidia
Serge, as Robert says, TwinView is what you need. Here's the deal. On Nvidia non-Quadro cards on Linux, the only way to guarantee no tearing on one screen is: UBB flipping enabled, full screen OpenGL app, no obstructions, Vsync flag with that screen number - there's an environment variable. For dual screens, TwinView, with both screens with the *exact* same res and rate - same modeline, basically, one OpenGL window/context filling both screens. The way you're doing, with two contexts, will tear. On Quadro cards, almost all conditions are lifted. Bruce On Apr 20, 2010, at 6:44 AM, Serge Lages wrote: Hi all, I'm currently having a problem with NVidia hardware on Linux, it's not directly OSG related, but I hope someone here can help me. Here is my setup : Ubuntu 9.10 195.36.15 NVidia drivers 2 GTX 285 graphic cards (one DVI, one VGA and one HDMI port) 4 screens (2 screens on each cards), all independents (no twinview) Compiz disabled On this setup, I have an OSG application running full-screen on all 4 screens (a CompositeViewer with 4 views). My app is running at 60fps when VSync is on, it's the screens refresh rate. When I enable Sync to VBlank in the Nvidia-settings, here is the current result : - On the first screen of each cards (plugged on the DVI port), the VSync is perfect, no tearing. - On the second screen of each cards (plugged on the VGA port), tearing is noticeable on the upper part of the screens (I have a line about 100 pixel far from the top of the screens). = Result : 2 screens without tearing, 2 screens with tearing in a specific location. It seems VSync is not really performed on the second screen of each cards. I have also tested on GTX285 cards with 2 DVI ports with the same result. Another note : the 4 screens are the same, all plugged in VGA with the same resolution (using an adaptor when plugged in the card DVI ports). I've tested with other screens with the same result. Anyone knows where this problem comes from ? And any idea how to solve it ? Is it a bug in recent drivers, maybe I should test olders ? Thanks in advance for your help. Best regards, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Thanks for reporting back Serge - glad that's working for you. Sorry I didn't have time to test on my Linux rig. Was the technique the same as your Main.cpp example, as posted, or did you have to do any extra tricks? Also, what graphics cards and drivers are you using? That makes a big difference in Linux. Regards, Bruce Wheaton On Mar 29, 2010, at 5:17 AM, Serge Lages wrote: Hi all, Some news on this topic, we've tested on Linux : same hardware (2 GTX285 and 4 screens), same video, same code, an ubuntu 9.04 configured with 4 screens, with VSync enabled we've got a solid 60fps... Without VSync it goes between 150 and 300fps. So we've got our solution, we'll make our setup on Linux. Multi- screen support in OpenGL is really crappy on Windows... :/ Cheers, On Thu, Mar 25, 2010 at 2:44 PM, Serge Lages serge.la...@gmail.com wrote: Hi JP, Thanks for your reply, we've tested to share the contexts but it wasn't much better. Cheers, On Thu, Mar 25, 2010 at 9:24 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Serge, Serge Lages wrote: Hi all, Still having problems playing my big video. Here is our current state : - On a single screen setup (with only one GT 220 GeForce), with a composite viewer and 4 windows (450x800 each window), it plays smoothly at 60 fps with a fluid video, no problem here. - On the destination setup : Intel QuadCore + 2 GeForce GTX 285 + 4 screens in 1360x768 (2 screens per cards), a composite viewer with one view per screen, it plays between 10 and 20 fps... We've made our tests on WinXP and Win7 with the same result. The technique we're currently using is the one from Robert, having a big osg::Image updated by ffmpeg, and having 4 images for the textures pointing at the correct location on the large one. The video's size is 768x6532. Have you tried sharing the context for the two views per card? Also, you are now uploading twice the data needed to each GPU, because each one is only viewing half the data. I'm sorry I can't help further currently, I would love to test on Linux, but don't have time... jp You can find attached the current code, any idea on what can be better ? Or any other idea on how to handle this problem ? And any chance for someone to test on Linux ? You can also find the test video here : http://labs.tharsis-software.com/outv.mp4 Thanks ! On Thu, Mar 11, 2010 at 9:53 AM, Serge Lages serge.la...@gmail.com mailto:serge.la...@gmail.com wrote: Hi all, Thanks for your advices. About the current setup, we're using only one screen with a 9800GT card (and 4 windows) for our tests, but the final setup will be composed of 2 9800GT cards and 4 screens. I'll let you know how our tests goes. Cheers, On Thu, Mar 11, 2010 at 8:28 AM, J.P. Delport jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za wrote: Hi, Serge Lages wrote: Hi JP, Thanks for your answer, and we don't need sound. By a fast disk, what do you recommend ? We have a raid0 setup that can sustain 150MB/s. Your ffmpeg reader is based on the current OSG plugin or is it a custom one ? It's a custom one, but not complicated. It basically pops the output of ffmpeg decompress into an osg::Image, set's PBO on that and lets OSG upload it. We are using only monochrome images though (GL_LUMINANCE). About our file, with some codecs and adjustments on the bitrate, we're able to play it with VLC without problems, so I think the reading part can be handled by the ffmpeg plugin with only one file, but then we need to dispatch this image on 4 textures. We're currently trying to do some tests. I'm still not sure where your problem area is. If it's not decoding it can only be upload to GPU or final rendering. You should be able to check this by varying the complexity of the rendering. jp Cheers, On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za wrote: Hi Serge, Serge Lages wrote: Hi all, We currently need to play a big video (approximately 5500*800) on 4 screens within an OSG application (we use a composite viewer), so we've tried : - Cut the video in 4 parts, but it seems really hard to synchronize the 4 streams. - Decode directly the big file, resulting with a very big texture split on 4 quads (with appropriate texture coords), but even with a powerful computer, it's very slow. Any idea on what's
Re: [osg-users] Quad Buffered Stereo FBO
FBO's don't support double buffering either. FBO's are frame buffer that are ever directly connected to display outputs. I didn't mean literally, rather that two color buffers would get attached and used as left and right back buffers. That's quite feasible, as far as I can tell. If you want to do two stereo outputs using FBO use two osg::Camera RTT cameras and then use the different results in your left/right eye subgraphs. For an illustration of how to manage left/right eye subgraphs see the osgstereimage example. Right, so essentially I'm back to roll my own stereo? That's fine. I suppose the left camera fbo and right camera and fbo will get node masked when it's time to recombine them in a quad buffered frame buffer. That way the final stero pass is osg standard, not that it makes much difference if all the content is already left/right split. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Quad Buffered Stereo FBO
Is a quad buffered FBO supported by default? If so, does drawing from it to a quad buffered framebuffer correctly keep left and right separate? I'm thinking of something like osgdistortion, just in stereo. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3rc2 Mac Xcode project - Windowing system
I'm working on it, but I ran out of time compiling it this morning. Will continue later. The correct flags seem to be there, in a place they will get picked up. The PNG plug-in seems like an easy fix - it's their recommended fix. Did you try it with the older library, just in case that version number isn't getting though at the right time? Bruce On Mar 31, 2010, at 8:46 PM, Paul Martz wrote: Bruce Wheaton wrote: I certainly defer to Stephan on this... but I presume the fix he found is similar, or addresses the core problem. If time becomes a factor Stephan, or you need testing of a changed version, let me know. Stephan sent me a new XCode project file and I have checked it in to the 2.8 branch but I have not yet made another release candidate. I want to consider updating the PNG plugin before I tag another rc. (If the changes to PNG are non-intrusive, and I'm suspecting they are, it might be a good idea to update it.) In the meantime, if you could test the XCode project files on the head revision of the 2.8 branch, I'd appreciate it. -- -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
Re: [osg-users] 2.8.3rc2 Mac Xcode project - Windowing system
The Xcode project seems better - executables can now create the correct sort of windows. Thanks Stephan! I also got to learn something more about OSG, so that was nice. BTW, Paul - thanks for the OSGQSG - very nice, good introduction. Bruce On Apr 1, 2010, at 10:05 AM, Bruce Wheaton wrote: I'm working on it, but I ran out of time compiling it this morning. Will continue later. The correct flags seem to be there, in a place they will get picked up. The PNG plug-in seems like an easy fix - it's their recommended fix. Did you try it with the older library, just in case that version number isn't getting though at the right time? Bruce On Mar 31, 2010, at 8:46 PM, Paul Martz wrote: Bruce Wheaton wrote: I certainly defer to Stephan on this... but I presume the fix he found is similar, or addresses the core problem. If time becomes a factor Stephan, or you need testing of a changed version, let me know. Stephan sent me a new XCode project file and I have checked it in to the 2.8 branch but I have not yet made another release candidate. I want to consider updating the PNG plugin before I tag another rc. (If the changes to PNG are non-intrusive, and I'm suspecting they are, it might be a good idea to update it.) In the meantime, if you could test the XCode project files on the head revision of the 2.8 branch, I'd appreciate it. -- -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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 2.8.3rc2 Mac Xcode project - Windowing system
On the Mac Xcode project, the Cocoa viewer works, but on the osgviewer and osgmovie targets, they don't run. I've tried the Carbon 32-bit and Cocoa 32-bit versions. I linked to Carbon, Cocoa, OpenGl and Quicktime Frameworks. osgViewer, OpenThreads, osg, osgDB, osgText, osgUtil, osgGA Frameworks are copied into the bundle's Frameworks folder All plugins are copied into the bundle's Plugins folder But when the apps try to make a window, they fail with: View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. As I recall, this used to be enough. Did the introduction of the Cocoa viewer change something? Is there an environment variable that needs to be set? Since I intend to make a Mac bundle, I'd rather not have any user installation steps. Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3rc2 Mac Xcode project - Windowing system
OK, it seems that when I set: -DUSE_DARWIN_COCOA_IMPLEMENTATION for the osgViewer framework, then recompile, the problem goes away. I'm not 100% if this is the right place, but it seems appropriate - the targets seem to be broken down by carbon and cocoa here in the viewer more than anywhere. I also tried -DUSE_DARWIN_CARBON_IMPLEMENTATION in the carbon target configurations with apparent success. Hopefully that's it - a fairly minor change. I don't see a reason why it wouldn't always be set, since without the flag the correct window implementation doesn't get compiled. If Stephan doesn't get back before you need it, I can modify a clean Xcode project and send it back? Where would that be too? Bruce On Mar 31, 2010, at 1:42 PM, Paul Martz wrote: FYI, I'm sort of waiting to hear what's up with this issue, will it require a change or not. The change I just put in for static linking on the 2.8 branch really is so insignificant that it hardly merits a new release candidate. But if there's a change for XCode too, then I'd like to cook another release candidate and let people taste the cooking before the final release. On the other hand, I don't want to hold this up forever. So any progress you folks can make on the XCode issue will be greatly appreciated. At the time I write this, the XCode issue is the only item holding up the release. -- -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
[osg-users] libPNG API changes
LibPNG changed their API in January. I have a current Arch Linux
install which uses the newer version, but we can presume it will crop
up more. The only two current issues are addressed by:
/OpenSceneGraph/src/osgPlugins/png/ReaderWriterPNG.cpp
176d175
#if PNG_LIBPNG_VER 10004
178,180d176
#else
if (fin.gcount() == 8 png_sig_cmp(header, 0, 8) == 0)
#endif
231,232d226
{
#if PNG_LIBPNG_VER 10004
234,237d227
#else
png_set_expand_gray_1_2_4_to_8(png);
#endif
}
As per the libPNG recommendations, to replace png_check_sig and
png_set_gray_1_2_4_to_8()
http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt
If this isn't the best/place to report this, someone please let me know.
Regards,
Bruce Wheaton___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3rc2 Mac Xcode project - Windowing system
I certainly defer to Stephan on this... but I presume the fix he found is similar, or addresses the core problem. If time becomes a factor Stephan, or you need testing of a changed version, let me know. Bruce On Mar 31, 2010, at 2:58 PM, Paul Martz wrote: Bruce Wheaton wrote: OK, it seems that when I set: -DUSE_DARWIN_COCOA_IMPLEMENTATION for the osgViewer framework, then recompile, the problem goes away. I'm not 100% if this is the right place, but it seems appropriate - the targets seem to be broken down by carbon and cocoa here in the viewer more than anywhere. I also tried -DUSE_DARWIN_CARBON_IMPLEMENTATION in the carbon target configurations with apparent success. Hopefully that's it - a fairly minor change. I don't see a reason why it wouldn't always be set, since without the flag the correct window implementation doesn't get compiled. If Stephan doesn't get back before you need it, I can modify a clean Xcode project and send it back? Where would that be too? Bruce This is excellent news! Thanks! Stephan's follow-up email indicates we still lack consensus. If you folks decide on a change, you can zip up the project files and just email them directly to me to avoid sending megabytes through the mail server. -- -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
[osg-users] Callback to run existing OpenGL Code
I'm moving my backend to OSG, but I'm too chicken to do it all at once. Where would be the best place to run existing code? The code is a set of texture transfers (individual planes of videos) and then some drawing with a shader to convert it to floating point RGB. The transfer code should: run every single frame, before other operations (resulting textures get used), should ideally be split - transfer starts (PBOs) and transfer completion, could optionally use a pre-process camera and osg::uniforms, Can be overlapped with existing rendering (the tail of the previous drawing) - first phase won't affect textures in use. Should be done once per GPU (assuming contexts are shared on each card). Is there a callback or two that would fit? Is it kosher to do the work in a draw callback, or is there an earlier point that is in the OpenGL context? Maybe an example? Since I know the 'best advice' will probably be to bite the bullet, as a sanity check, I mention that my code is an ffmpeg video channel that decodes the video into native planes, then transfers multiple planes and uses a shader and multiple texturing to convert to floating point and do various color correction etc. I think fitting that into the existing ImageSequence, which seems to assume single frames of RGB, would be too time consuming at the moment. Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3-rc1 tagged
On Mar 24, 2010, at 1:19 AM, Stephan Huber wrote: OpenThreads is still part of the xcode-project (there should be a target for it) and may not be removed. Paul removed the redundant OpenThreads folder from the xcode folder because it doesn't make sense, to have a separate xcode-project file for OpenThreads as OpenThreads is now part of OpenSceneGraph. Ok, neat. So then the --framework OpenThreads needs to be removed from various Xcode targets, AFAICT. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Serges, I do something similar - at least with the multiple GPUs, and multiple videos. I have a machine here with very similar spec running Linux, I could maybe try your code tomorrow. On a side note, we had problems with frame rate fluctuations on our previous (heavily threaded) pipeline design when sending to multiple GPUs, and that's why I'm looking at OSG. I'm about to try to change over. Fairly early on the list will be removing/making optional the CPU colorspace conversion that is probably slowing you up a bit too. Assuming your videos are MP4, like that sample, and probably 4:2:0, that could also have the effect of halving your texture transfers. Regards, Bruce Wheaton PS - our fluctuations were 2-8 frames, occasionally, not what you're describing. On Mar 23, 2010, at 10:51 AM, Serge Lages wrote: Hi all, Still having problems playing my big video. Here is our current state : - On a single screen setup (with only one GT 220 GeForce), with a composite viewer and 4 windows (450x800 each window), it plays smoothly at 60 fps with a fluid video, no problem here. - On the destination setup : Intel QuadCore + 2 GeForce GTX 285 + 4 screens in 1360x768 (2 screens per cards), a composite viewer with one view per screen, it plays between 10 and 20 fps... We've made our tests on WinXP and Win7 with the same result. The technique we're currently using is the one from Robert, having a big osg::Image updated by ffmpeg, and having 4 images for the textures pointing at the correct location on the large one. The video's size is 768x6532. You can find attached the current code, any idea on what can be better ? Or any other idea on how to handle this problem ? And any chance for someone to test on Linux ? You can also find the test video here : http://labs.tharsis-software.com/outv.mp4 Thanks ! On Thu, Mar 11, 2010 at 9:53 AM, Serge Lages serge.la...@gmail.com wrote: Hi all, Thanks for your advices. About the current setup, we're using only one screen with a 9800GT card (and 4 windows) for our tests, but the final setup will be composed of 2 9800GT cards and 4 screens. I'll let you know how our tests goes. Cheers, On Thu, Mar 11, 2010 at 8:28 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi, Serge Lages wrote: Hi JP, Thanks for your answer, and we don't need sound. By a fast disk, what do you recommend ? We have a raid0 setup that can sustain 150MB/s. Your ffmpeg reader is based on the current OSG plugin or is it a custom one ? It's a custom one, but not complicated. It basically pops the output of ffmpeg decompress into an osg::Image, set's PBO on that and lets OSG upload it. We are using only monochrome images though (GL_LUMINANCE). About our file, with some codecs and adjustments on the bitrate, we're able to play it with VLC without problems, so I think the reading part can be handled by the ffmpeg plugin with only one file, but then we need to dispatch this image on 4 textures. We're currently trying to do some tests. I'm still not sure where your problem area is. If it's not decoding it can only be upload to GPU or final rendering. You should be able to check this by varying the complexity of the rendering. jp Cheers, On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za wrote: Hi Serge, Serge Lages wrote: Hi all, We currently need to play a big video (approximately 5500*800) on 4 screens within an OSG application (we use a composite viewer), so we've tried : - Cut the video in 4 parts, but it seems really hard to synchronize the 4 streams. - Decode directly the big file, resulting with a very big texture split on 4 quads (with appropriate texture coords), but even with a powerful computer, it's very slow. Any idea on what's the best approach for this problem ? We're currently making our tests using the ffmpeg plugin, but maybe another plugin would be more appropriate ? Thanks in advance for your help. some ideas/questions. We do something similar - stitch four high- res camera videos into large texture. We have custom ffmpeg reader that just reads from 4 video files and we step them manually (and in sync) one frame at a time. We use raw video (no compression) to avoid cpu decompress, but now one needs fast disks. We don't have sound, do you need sound? For large sizes one needs to avoid copying around data in cpu mem as much as possible. There is still one copy in ffmpeg raw read that I need to get rid of. rgds jp Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] 2.8.3-rc1 tagges
Sorry, Paul, did the Mac OS X frameworks and Xcode stuff get updated properly? I saw you were looking for help (afraid I'm too new to the project to offer). Bruce On Mar 23, 2010, at 12:10 PM, Paul Martz wrote: Hi all -- Things are looking pretty stable so far, so I've gone ahead and tagged release candidate 1. You can check it out from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.3-rc1/ Please test as soon as your schedule allows and report any problems. See the wiki page for major features, and guide your testing accordingly: http://www.openscenegraph.org/projects/osg/wiki/Support/283release The only potential issue I'm aware of at this time is the ongoing discussion concerning FreeBSD 8 pthreads. If this requires a change, or if other issues are found requiring a change, I'll tag another release candidate. Thanks for everyone who has helped so far. I'm overwhelmed by the responsiveness of people here, directing me to specific fixes and trunk changes in order to fix bugs and add new features to the 2.8 branch. Outstanding work, everyone! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3-rc1 tagged
Things are going pretty well, until I tried osgMovie - seems like a -- framework OpenThreads flag is still in the Target. Oh, wait, it's in a few places - osgViewer too. Am I right that it can be safely removed now? The target seems to be gone from the Xcode file. osgViewerCocoa was working, I guess the other targets need some work? Bruce On Mar 23, 2010, at 1:27 PM, Paul Martz wrote: Bruce Wheaton wrote: Sorry, Paul, did the Mac OS X frameworks and Xcode stuff get updated properly? I saw you were looking for help (afraid I'm too new to the project to offer). XCode project files were added and are in rc1 (thanks, Stephan). I have a Mac, but primarily use it as a *nix box (gcc and a shell prompt), so I really have no experience with XCode. I was able to load the project into XCode v3.1.4, but didn't do any further testing with it. So right now Stephan is really the only XCode tester. If you have XCode experience and your schedule allows, please try out the XCode project files, and let us know how things work for you. Did the ply and fbx plugins make it into the XCode project file, for example? That would be one thing to check... -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shader Composition - pixel formats
The phrase gets thrown around a lot, and there seems to be an assumption that everyone knows exactly what it means in this context. I'm new, I don't, and searching doesn't seem to solve the problem. My presumption is that it's an effort to solve the problem of recent 'shader only' OpenGL versions, where adding features to a shader is the way to affect rendering, as opposed to changing states? And it will use the ability to link multiple shaders into each shader stage? So will there be a standardized naming of functions, so that a master shader can 'collate' all the stages? What's the plan? Main reason I ask - I currently have a 'master fragment shader' and I customize it by concatenating a one line main() function at the end that calls the right functions. Obviously, installing that will subvert a good portion of state that OSG is trying to manage and sort for me. I'd also like to break this down myself, and use a more flexible approach, that should also require less compiling (although more linking). My stages are something like: Decode pixel format: converts planar and packed pixel formats into RGBA Float 16-bit (HALF) as YUVA data. Apply brightness/contrast/saturation Convert to rec.709 colorspace RGBA Remove transfer function (gamma) More work Later I need stages to de-interlace or not, then trilinear scale, re- apply transfer functions etc. Be nice to apply lighting here if needed. Is this the sort of thing shader composition will help with? Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgMovie and the ImageStream Object
I had a bit of trouble tracking down where the ImageStream object is handled, and I think I've worked it out, but it's quite odd, even for a demo. As far as I can tell, an Image is created from the provided file name and held in a pointer. That image is cast to an imagestream for some housework. A texture is created and the image is set as it's source - this is all a pointer, as far as I can tell, not the refPtr I expected to see. Then, the main thread seems to forget about the image/s, and moves on. It then goes into a visitor, which finds any images and makes a ref pointer list to them. Is that about right? So there's a ref pointer and a raw pointer floating around at once? And for a while, only a pointer? Isn't that a pretty nasty situation? Am I missing some C++ kung-fu to make refPtrs in the texture or earlier? Is there an example with a 'better' management of image/stream objects? Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Great, thank you. I will be trying 'git pull --rebase origin master' in the future. I feel better that there's some experts floating around OSG that can help people with this sort of thing. Maybe if/when OSG goes to Git, a wiki entry with a few approaches would be useful. Bruce On Feb 27, 2010, at 3:31 AM, Tim Moore wrote: On Sat, Feb 27, 2010 at 3:21 AM, Bruce Wheaton br...@spearmorgan.com wrote: Not to blame the victim, but it sounds like some user error was involved here. You should do your local work on branches, because it is very easy to do so and makes it very easy to update to the main sources if you need to. The git rebase workflow is perfect for the occasional contributor. Good to hear, however this is the first I've heard of the git rebase workflow - sort of makes my point - not very friendly to non- core users. I would have loved to find a guide to working with a workflow with this, in fact, if you have one (please) I'll post it elsewhere right away. Subversion took a few hours to start working with, although of course, there's just stuff that's not even worth trying to do. Here a couple of links, in no particular order: http://blog.woobling.org/2009/08/git-rebase-for-impatient.html http://book.git-scm.com/4_rebasing.html http://jarrodspillers.com/articles/git-merge-vs-git-rebase-avoiding-rebase-hell (an alternate viewpoint :) It has been a valid criticism that git can be hard to get into for a novice, but I think the situation has changed as the community of users grows outside of Linux kernel hackers.The git book listed above, newbie documentiation at github.com, etc. are all part of this positive trend. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
I've played with various tools on OS X, and the best I've found is SmartGIT, which is free for non-commercial use (and Java, so multi platform). I like it for this sort of thing since it also has some helper functions for users of projects like this. Speaking of which, here's my 2c. Git is designed to address the exact problems discussed in this thread - it allows contributors to safely develop parallel branches and 'grown-ups' to merge selected branches with the main branch, and it has great support for tags and full releases, *but* it's way harder for the dabbler to work on some features but try to keep up to date with an ongoing flow of many changes. For instance, if I were working on ImageStreams, and had occasional small fixes, but also wanted to keep up to date with the 'head' branch, I'd expect to have a lot of merge problems when I update - I do have with another project that has moved to Git. Not enough to stop things moving ahead, but just a caveat. The normal users who wants to just do a complete check-out of a formally tagged release should be fine, they just may have to start from a blank slate each time, unlike say SVN, which works well with a 'master/remote' and 'slave/local' repo. Sorry I can't offer to contribute yet, I don't really have my head around OSG yet! Hopefully down the road. Great project, thanks for the hard work. Regards, Bruce Wheaton PS The hardest part of moving to Git was giving up Versions, the most 'Mac-like' SCM client I've seen yet. On Feb 26, 2010, at 8:23 AM, Robert Osfield wrote: Hi Mathieu et. al, On Fri, Feb 26, 2010 at 12:34 PM, Mathieu Marache mathieu.mara...@gmail.com wrote: Mercurial had a head start but now things are even in terms of tools, both command line and graphical. Windows : - command line with msysgit : http://msysgit.googlecode.com/files/Git-1.6.5.1-preview20091022.exe - explorer integration with TortoiseGit : http://code.google.com/p/tortoisegit/downloads/list Mac : - git : http://code.google.com/p/git-osx-installer/downloads/list - gitk : comes in with git and is a graphical local repository browser - GitX (my fav app) : http://gitx.frim.nl/ Could Windows and Mac users have a play with these tools. It'd be good to get feedback on how you get on with the various tools for Git, Mercurial and Subversion and how they all compare with each other. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
On Feb 26, 2010, at 12:38 PM, Mathieu Marache wrote: Speaking of which, here's my 2c. Git is designed to address the exact problems discussed in this thread - it allows contributors to safely develop parallel branches and 'grown-ups' to merge selected branches with the main branch, and it has great support for tags and full releases, *but* it's way harder for the dabbler to work on some features but try to keep up to date with an ongoing flow of many changes. For instance, if I were working on ImageStreams, and had occasional small fixes, but also wanted to keep up to date with the 'head' branch, I'd expect to have a lot of merge problems when I update - I do have with another project that has moved to Git. I'm confused. DCVS tools should ease this process (or at least they all claim it loud). It would be grand if you could be more precise in your description of the process. Because it looks like this could be a show stopper... I'm not sure it would be a show stopper. For the regular full-on updaters - who I believe we're trying to reduce the strain on right now - there's great tools for merging branches and making new ones etc. For the beginner or straightforward user, getting a full checkout of a tagged release is easy enough. It's just the in between users - those who tend to make a few tweaks, and/or would like to stay current that will have to work a bit harder. In essence, the problem seems to be that Git always regards your local work - which is a real repo, as sacrosanct, and you can't tell it to ignore your noodlings and overwrite it with the lovely fresh code from the master branch. If you try, by accident, then auto-merges tend to fail (in my experience) and you end up with a hung repo that's between one state and another. You then, in theory would go by hand and merge things and execute some magic to tell Git that. In the particular project I dealt with it, this included a huge amalgamated C++ file that would be suicidal to try to merge by hand. I also find that the failed merges fills files with mine type stuff, and double copies of things (mine/theirs in one file) that make diffs very hard. The solution seems to be to make branches very often, so you can revert them or switch away from them. I think they're enforcing what they believe to be the correct behaviour. It was Linus that made it, after all. They actually removed an old merge strategy of 'prefer theirs', god bless 'em. I sometimes solve it with a forced update/switch trick, but it always feels like a bodge. I still think making the change will help - it's obvious the load on one developer is unfair, and I'd prefer it be Git, but I wanted to warn people it's not as seamless a change as it might seem from the ease of importing svn. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
On Feb 26, 2010, at 5:14 PM, Tim Moore wrote: There's no such thing as hung repo unless you're encountering a bug in git, probably very rare these days. You can always get back to a sane state using git reset --hard. I've being doing that, but it doesn't move you toward the solution, it just abandons what you tried. I meant hung as in unable to move forward. Not to blame the victim, but it sounds like some user error was involved here. You should do your local work on branches, because it is very easy to do so and makes it very easy to update to the main sources if you need to. The git rebase workflow is perfect for the occasional contributor. Good to hear, however this is the first I've heard of the git rebase workflow - sort of makes my point - not very friendly to non-core users. I would have loved to find a guide to working with a workflow with this, in fact, if you have one (please) I'll post it elsewhere right away. Subversion took a few hours to start working with, although of course, there's just stuff that's not even worth trying to do. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Changing scenes on the fly
What's the recommended way to change scenes? I'll have a static setup of multiple cameras, then need to change what scene is being viewed. I feel that one big issue is the scale of the scene I want to load, so I guess I need a master PAT, which I may have to add, since I need to keep the setup up on a few different cameras. Is it best to switch the whole scene, or add the scene's top node as a child of my existing graph? I should add that I'll have multiple scenes, if for nothing else than to cross-fade between the two scenes. Am I answering my own question then? I need a master node, maybe a switch, a PAT for each scene, then load the scene and place it as a child of the PAT node? Let me guess - there's an example that shows this exact thing? Thanks, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing scenes on the fly
Thanks, I have seen Switch nodes. Some wrinkles though - I need a dynamic system, and there may be multiples active at a time, for instance in between a cross-fade. But my main question still applies - should I load the .osg file and attach the whole graph downstream of the switch on the fly? Bruce On Feb 22, 2010, at 4:02 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/ MXDEC wrote: Bruce, I would recommend using the switch node osg::Switch to change between scenegraphs. You can add the scenegraphs that the switch node can render at any one time during setup and then select which one you want rendered using the method setSingleChildOn. Hope this helps... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bruce Wheaton Sent: Monday, February 22, 2010 11:33 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Changing scenes on the fly What's the recommended way to change scenes? I'll have a static setup of multiple cameras, then need to change what scene is being viewed. I feel that one big issue is the scale of the scene I want to load, so I guess I need a master PAT, which I may have to add, since I need to keep the setup up on a few different cameras. Is it best to switch the whole scene, or add the scene's top node as a child of my existing graph? I should add that I'll have multiple scenes, if for nothing else than to cross-fade between the two scenes. Am I answering my own question then? I need a master node, maybe a switch, a PAT for each scene, then load the scene and place it as a child of the PAT node? Let me guess - there's an example that shows this exact thing? Thanks, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] !Present3D GUI
On Feb 14, 2010, at 4:31, Robert Osfield robert.osfi...@gmail.com wrote: Hi Bruce, On Fri, Feb 12, 2010 at 5:49 PM, Bruce Wheaton br...@spearmorgan.com wrote: The Present3D wiki asks for contributors. If it would be acceptable for a GUI to be written in juce then I'm not familiar with Juce. Why Juce rather than other GUI toolkits? No reason. Qt may be better. Last time I evaluated it, I found it counter-intuitive, cheesy looking (results) and crazy expensive - juce seemed the exact opposite. I'm working in juce and would be willing to make a version to share. W.r.t license Present3D is GPL, while osgPresentation and the p3d plugin that provide the bulk f the functionality are OSGPL. I'll have to look at which parts are GPL, whether the rest is usuable without it. I terms of functionality Present3D itself my plans has been to refactor osgPresentation to provide a better object model and then scripting on top of this, and have GUI elements that sit on top of this for create/editing presentation objects. The GUI elements would be a mix of fully 3D elements using osgWidget/osgManipulator and 2D elements such as file browsers. Present3D is used extensively as immersive (stereo) presentation tool, so being able to stay in fully immersive (i.e. not 2D elements at all) is important when fine tuning a presentation. 3d GUI is great, but my intended audience is way different - 3d on a large flat single screen for a medium to large passive audience. The creators of presentations would be working mainly in existing 2d tools, only dropping into 3D to make the final composition, and for sufficiently long periods that 3d would have to be optional in the interface. I would use an offshoot of the code commerically. If we can get the osgPresentation layer right and avoid too much deviation ontop of this hopefully we'd be able to have a family of presentation tools that would be pretty compatible with each other. If some of these are commercial then great, especially if they can drive forward the osgPresentation layer and provide better tools for generating content. It sounds like we have two tools but one format would work. I'll look through the example doc and source code when I get a chance. Bruce ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph and MultiThreading
On Feb 14, 2010, at 14:15, Danny Lesnik danny...@walla.co.il wrote: The value of node is null. I'm a newbie in Threading Programming, but I need to find a way to work it out. Your problem lies in C, Danny, not in threading. You passed a pointer into your thread class by value. Your thread class initialized a pointer member with that value. There is absolutely no link between those two except, at the start, they have the same value (0). could anybody help? Thank you! Cheers, Danny -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24146#24146 ___ 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] OpenSceneGraph and MultiThreading
Sorry, sent too early. Anyway, OSG has a potential solution to this - ref ptrs. If you pass and hold ref ptrs, then you will have two objects pointing to the same thing. Specifically, you would pass a pointer to your ref ptr. Having said that, I'm new to OSG - there's probably a better way. Please also consider thread safety - what would happen if your main thread tries to access the node while it's being created? What are you trying to do? Bruce On Feb 14, 2010, at 14:28, Bruce Wheaton br...@spearmorgan.com wrote: On Feb 14, 2010, at 14:15, Danny Lesnik danny...@walla.co.il wrote: The value of node is null. I'm a newbie in Threading Programming, but I need to find a way to work it out. Your problem lies in C, Danny, not in threading. You passed a pointer into your thread class by value. Your thread class initialized a pointer member with that value. There is absolutely no link between those two except, at the start, they have the same value (0). could anybody help? Thank you! Cheers, Danny -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24146#24146 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] !Present3D GUI
The Present3D wiki asks for contributors. If it would be acceptable for a GUI to be written in juce then I would like to help. Juce works as GPL or under a commercial license. That does mean an OSG licensed GUI would probably not be possible, although I can ask the developer. Maybe not an issue, as it's an app, not library? I would use an offshoot of the code commerically. Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo with pre-split images streams
OK, great, I figured this had been dealt with. That's a nice, full example, thanks. I'll get my head around it. I was a bit worried about this approach and the complexity of 'doubling' my graph, but it seems that all I have to do is double the one Geode - which is a leaf, so has no children I have to deal with, and then do some minor offsets, or supply a different texture in the update. And, as I read it, cullmasks are arbitrary masks that I can set up, then assign to different nodes and cameras for this exact purpose. So I can set up: Mono0x0001 Left0x0002 Right 0x0004 Assign those to cameras, And then make the left node mask 0x0003 and the right 0x0004. And I should be able to get the node's cullmask and decide what to do in an update callback - ideally the same callback for each geode. I don't suppose you've a handy example for image streams as well, do you? And yes, I saw you did Present3D. It sounds fantastic, but there's no editor is there? That, and the 3D, makes it hard to see examples. If there was, I would try to support that format in my app, and then recommend the editor for clients. Thank you for putting that in the core. Oh, I see in the wiki, Present3D has stereo movie support. Very cool - I'll dig through there too - Have to update from OSG 2.8 anyway. Bruce On Feb 12, 2010, at 12:57 AM, Robert Osfield wrote: I've done lots of 3D video work with the OpenSceneGraph/Present3D over the years. There is even an example osgstereoimage that shows how to do it using two subgraph each with their own NodeMask which is matched to the left eye/right eye cull masks. Robert. On Fri, Feb 12, 2010 at 1:08 AM, Bruce Wheaton br...@spearmorgan.com wrote: I'm about to drop OSG into an app and I'm looking at how to do various things. The built-in stereo support is great, but I'm not sure how to do something that's easy in my current code - handle pre-split images. I have to take a variety of images, mainly in streams, and handle them correctly in the left and right eye. The formats I deal with are: 1. Dual-stream, for instance two images, or two tracks in a Quicktime movie or AVI file (3D Blu-ray too, someday), 2. Left-Right, 3. Top-Bottom, 4. Possibly, interleaved. Right now I've dealt mostly with 2 3, by padding two sets of tex coords along with 3D images. I intend to deal with 1 and 4 by splitting textures, maybe using 2 FBO attachments. The issues/options seem to be: Draw the images billboarded and at screen depth, so there's no extra parallax introduced. It would be great to be able to mask or draw a frame 'in-front' of the image, even though it's at zero, so the edges appear to be at the same depth as the content (or can be manipulated). Then I can either use a cull callback, since I believe cull runs once per eye, and reset tex-coords and/or which texture (or attachment of an FBO) to use, or place a duplicate item of each 3D texture in the graph, set it correctly on update, then set the stereo cullsettings correctly. Any suggestions? Did I miss a better technique? Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stereo with pre-split images streams
I'm about to drop OSG into an app and I'm looking at how to do various things. The built-in stereo support is great, but I'm not sure how to do something that's easy in my current code - handle pre-split images. I have to take a variety of images, mainly in streams, and handle them correctly in the left and right eye. The formats I deal with are: 1. Dual-stream, for instance two images, or two tracks in a Quicktime movie or AVI file (3D Blu-ray too, someday), 2. Left-Right, 3. Top-Bottom, 4. Possibly, interleaved. Right now I've dealt mostly with 2 3, by padding two sets of tex coords along with 3D images. I intend to deal with 1 and 4 by splitting textures, maybe using 2 FBO attachments. The issues/options seem to be: Draw the images billboarded and at screen depth, so there's no extra parallax introduced. It would be great to be able to mask or draw a frame 'in-front' of the image, even though it's at zero, so the edges appear to be at the same depth as the content (or can be manipulated). Then I can either use a cull callback, since I believe cull runs once per eye, and reset tex-coords and/or which texture (or attachment of an FBO) to use, or place a duplicate item of each 3D texture in the graph, set it correctly on update, then set the stereo cullsettings correctly. Any suggestions? Did I miss a better technique? Regards, Bruce Wheaton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
