Re: [osg-users] save a movie
Hi Gianni, like Sergey said, you could try an application external to your own. On Linux we've also used istanbul and ffmpeg [1] before. If you want to read pixels back you can use one of the approaches in osgscreencapture. We've experimented with this in a small image processing framework we have. See the screen_capture_producer and screen_capture examples here: http://code.google.com/p/flitr/ It basically attaches (a producer) to an osg::View as a final draw callback and reads data into a memory buffer. A consumer then streams this data to disk in another thread. One is obviously limited by either GPU-CPU speed, mem size or (more likely) disk speed. cheers jp [1] e.g. ffmpeg -f x11grab -r 20 -s 768x768 -i :0.0+4,52 -an -vcodec mjpeg ... On 12/05/11 16:42, Sergey Polischuk wrote: Hi, Gianni In linux you can use glc for grabbing video from opengl render in realtime. osgscreencapture-like screen capture takes a lot of time each frame and would be slow as hell in good resolutions (you can speedup it to some point by writing to drive created in ram). 11.05.2011, 12:17, Gianni Ambrosioga...@vi-grade.com: Hi All, I know this topic have been already discussed in the past but I didn't find clear solution. Basically I need to save a movie of what is shown in an osgViewer embedded in a Qt widget. I gave a rough look at the osgscreencapture example. Is the recommended way to implement what I need? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39265#39265 ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
Hi Robert Thorsten, I simply merged r12395 in my 2.9.14 branch and got this : http://frbouvi.free.fr/flightsim/fgfs-txf-fonts.jpg oversized font! Regards, -Fred - Robert Osfield a écrit : Hi Thorsten, I have tracked down the problem to the txf plugin not setting the width and height of the glyph, adding this addressed the sizing/spacing problems I saw when running the osgtext3D --2d --no-3d -f Helvetica.txf test. My fix is now checked into svn/trunk. Could you please test svn/trunk and let me know whether this addresses the problems you've been seeing. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
Hi Frederic, I've just modified the osgtext example to use the Helvetica.txf and see the problem with oversized text.. The text has the right spacing, but is just too large... I didn't spot the size problem yesterday as the osgtext3D usage had the viewer moving the eye point back to view the whole text so what ever size it was in object coordianates it only took up the same size on screen. Not sure where the culprit lies, it might be lack of scaling on the osgText side, or perhaps just needing to rescale the sizes in txf. I will dig into the code and see what is going on. Robert. On Fri, May 13, 2011 at 8:19 AM, Frederic Bouvier fredlis...@free.fr wrote: Hi Robert Thorsten, I simply merged r12395 in my 2.9.14 branch and got this : http://frbouvi.free.fr/flightsim/fgfs-txf-fonts.jpg oversized font! Regards, -Fred - Robert Osfield a écrit : Hi Thorsten, I have tracked down the problem to the txf plugin not setting the width and height of the glyph, adding this addressed the sizing/spacing problems I saw when running the osgtext3D --2d --no-3d -f Helvetica.txf test. My fix is now checked into svn/trunk. Could you please test svn/trunk and let me know whether this addresses the problems you've been seeing. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
On Friday 13 May 2011 09:19:38 Frederic Bouvier wrote: Hi Robert Thorsten, I simply merged r12395 in my 2.9.14 branch and got this : http://frbouvi.free.fr/flightsim/fgfs-txf-fonts.jpg oversized font! Yes, I see the same with yesterday's head revisions of OSG and flightgear/simgear. Regards, Magnus Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
Hi Frederic and Magnus, On Fri, May 13, 2011 at 9:14 AM, Robert Osfield robert.osfi...@gmail.com wrote: Not sure where the culprit lies, it might be lack of scaling on the osgText side, or perhaps just needing to rescale the sizes in txf. I will dig into the code and see what is going on. I have tracked down the problem to fact that osgText now assumes that all fonts handle their own scaling to a unit font size of 1.0, rather than have each font come in at any size and then require osgText itself to rescale these. The freetype plugin honoured this, but the txf font didn't scale it's glyph settings to be against a unit size. I have now added this and checked it in. Could you please test this out? In test with the txf plugin with a tweaked version of the osgtext example I found that while the scaling issues now looked to be resolved quite a few of the character representations on screen were corrupted or just blank. Initially I thought that it was down the txf plugin becasue the freetype and default fonts all worked correctly, but after much digging the culrprit for these rendering problems looked to be the mechanism for placing the glyph images into the GlyphTexture (which works as texture atlas). I haven't yet established exactly what is going wrong, but as a workaround increasing the margin size between the glyphs in the GlyphTexture resolves the rendering problems. Increasing margin size really is just a hack that happens to work for this particular font, I don't see it as a resolving the bug so I won't check this hack. Curiously this bug will have been lurking unseen for a while, and mainly just luck that it hasn't appeared with the freetype fonts. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Transparency on Shapes
Hello, I am learning to use *Transparency Effect* on OpenSceneGraph. I don't know if I am doing it right. I have made a video screen capture. I do think that I missed something http://www.youtube.com/watch?v=Kzm_1X55OIM I have multiple shapes. I attached a *osg::Material* attribute to some of them.The third sphere (nearst to the user) is set to be transparent up to 40%. // Enable blending, select transparent bin. stateSet-setMode( GL_BLEND, osg::StateAttribute::ON ); stateSet-setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); // Material osg::Material * _material = new osg::Material; _material-setAlpha( osg::Material::FRONT_AND_BACK, 0.4f ); _material-setColorMode( osg::Material::AMBIENT ); stateSet-setAttributeAndModes( _material , osg::StateAttribute::ON ); // Blending osg::ref_ptrosg::BlendFunc blendFunc = new osg::BlendFunc; blendFunc-setFunction( osg::BlendFunc::SRC_ALPHA , osg::BlendFunc::ONE_MINUS_SRC_ALPHA ); stateSet-setAttributeAndModes( blendFunc ); 1. Have I done it right ?? 2. let suppose I would like to modify the transparency of a Node picked ??? Should I get its material attribute and modify its *Alpha* ?? 3. In case, the video show a small lack of transparency between the two cylinders and the sphere ?? is it normal ?? or I missed the *osg::Depth *attribute ?? Thank you for advance for your help Cheers ps: video http://www.youtube.com/watch?v=Kzm_1X55OIM *--* *M. ALJI Mohamed* ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
On Friday 13 May 2011 12:28:37 Robert Osfield wrote: Hi Frederic and Magnus, On Fri, May 13, 2011 at 9:14 AM, Robert Osfield robert.osfi...@gmail.com wrote: Not sure where the culprit lies, it might be lack of scaling on the osgText side, or perhaps just needing to rescale the sizes in txf. I will dig into the code and see what is going on. I have tracked down the problem to fact that osgText now assumes that all fonts handle their own scaling to a unit font size of 1.0, rather than have each font come in at any size and then require osgText itself to rescale these. The freetype plugin honoured this, but the txf font didn't scale it's glyph settings to be against a unit size. I have now added this and checked it in. Could you please test this out? Thanks, Robert. Your fix seems to work fine in FlightGear now. Text is now rendered at the right size and with suitable spacing between letters again. I notice a slight kerning issue, but that might very well have been there before. Magnus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text character spacing
Hi Magnus, On Fri, May 13, 2011 at 5:16 PM, Magnus Kessler magnus.kess...@gmx.net wrote: Thanks, Robert. Your fix seems to work fine in FlightGear now. Text is now rendered at the right size and with suitable spacing between letters again. Good to hear it working once more. I still haven't tracked down the bugs I'm seeing on rendering using txf with the osgtext example, so there is chance that you might see problems later with more intensive use. I'm still hunting this bug down so fingers crossed I'll nail it soon. I notice a slight kerning issue, but that might very well have been there before. txf itself doesn't seem to support kerning, with the plugin just returning a 0,0 offset for kerning, both older and newer versions use this same default kerning value. However, the code to advance between characters is a little changed, the old code add an arbitary extra 0.1 of height to the advance. I didn't maintain this as it rather looked like a hack. I can add this add back in if you feel that it would be better to maintain the extact spacing before, even if it doesn't actually match what the font itself specifies. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersection testing in a separate thread
J-S, Shayne, Thanks for the help. The threaded/shared scenegraph is the approach I had in mind, but there are still a few kinks in my understanding that I'm trying to work out. The current serial render loop looks something like: databasePager-signalBeginFrame(...); databasePager-updateSceneGraph(...); scene-accept(updateVisitor); // process sim logic here sceneView-cull(); sceneView-draw(); databasePager-signalEndFrame(); databasePager-compileGLObjects(...); So as you can see, the scene will be changing due to the database pager adding/removing nodes, and part of the simulation will be moving subgraphs around in world space (e.g. changing matrix transforms). Would it be possible to leave most everything -- update, cull, etc. on the main thread, but push the drawing off to a separate thread? Basically I want the update and sim logic to run as fast as possible and not wait on the draw(). If a mutex is used to prevent the main thread from being in cull() while the draw thread is in draw(), would that work? Would it be possible to run cull() on the draw thread and use a mutex to prevent cull() and the updates from happening simultaneously? Finally, where does the database pager fit in -- should it signal begin/end frames on each update, or each draw? Thanks, Craig On Thursday, May 12, 2011 at 3:50 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: J-S, Yes, a great point I failed to bring up about the mutex. Thanks for mentioning that. We did have to do that to protect the shared resource when we used threading. For our stuff, one process (out-the-window) does the usual traversal (via viewer.frame) while the other sits idle until a request comes in for either HAT/HOT or LOS. Once a request comes in, it just computes the intersection with the terrain via the osgSim class and sends the scalar result back. Both processes load the same PagedLOD terrain node but they're using completely different graphs. We only check for intersection with terrain and nothing else... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Thursday, May 12, 2011 2:37 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Intersection testing in a separate thread Hi Shayne, Craig, Bottom line is that it can be done. It basically amounts to having asynchronous traversal of the same scenegraph, one for rendering traversal and the other for intersections. These traversals can either be done in different threads or different processes. But the case of a different thread vs a different process is not the same. In his case, there will be (optimally) one copy of the scene graph, and both the rendering and the intersection thread will access it. He will need a mutex which would be held by the rendering thread while it's in the update phase, and by the intersection thread while it does an intersection. In your case, you have two copies of the scene graph, so there are no threading issues. (how did you update the scene graph between processes?) But that doesn't mean it can't be done, just that it's not quite as simple as that. Hope this helps, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.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
Re: [osg-users] osgText::Text character spacing
Hi All, On Fri, May 13, 2011 at 5:45 PM, Robert Osfield robert.osfi...@gmail.com wrote: I still haven't tracked down the bugs I'm seeing on rendering using txf with the osgtext example, so there is chance that you might see problems later with more intensive use. I'm still hunting this bug down so fingers crossed I'll nail it soon. After a rather exhusting and perplexing debug session I finally conerned the bug to the way that the src/osgText/Font.cpp was caching seperate sets of osgText::Glyph for different font resolutions. This is correct behviour for formats like FreeType or QFont, but for fonts like the osgText::DefaultFont and the TXF fonts it's not appropriate as these only support a fixed resolution size, so if you request a different font resolution you don't actually get a different glyph, so it's inappropriate to cache it multiple times. It's this sharing of single Glyph between multiple apparent font resolutions that caused the problem with rendering of osgtext when using with Helvertica.txf. I have now changed osgText::Font::FontImplementation so it can automatically tell osgText::Font that it's inappropriate to use the font resolution requested as guide, and to just use a single glyph cache for this fixed size. I had to update the freetype, DefaultFont, osgQt::QFontImplementation and txf plugin all to provide the correct setting, and this is all now checked in. Curiously this particular bug will have been in the OSG for a very long time, almost as long as osgText, but was just never detected or characterised. I also spotted and fixed a bug in handling of the Object::resizeGLObjectLists request that may have meant that opening new contexts whilst using fonts would have resulted in the texturing of the text quads going astray. All these changes are now checked into svn/trunk. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
