http://blog.gmane.org/gmane.comp.graphics.openscenegraph.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74886 <pre>Hi, I'm currently working on the example osgAndroidExampleGLES1. I want to delete the change navigation button. Turn and drag the object only by fingers. +slip is made by a finger. it's easy +rotation by two fingers: one fixed and the other turns. I couldn't control the rotaion. Can someone help me, Please? Thank you! Cheers, Rghima ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47833#47833 </pre> Rghima Ahlem 2012-05-24T14:29:13 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74885 <pre>Hi Andres, If you have a fix for the problem could you post it to osg-submissions? Thanks, Robert. On 24 May 2012 09:06, Anders Backman &lt;andersb-M9ekpT6mRt2zQB+pC5nmwQ&lt; at &gt;public.gmane.org&gt; wrote: </pre> Robert Osfield 2012-05-24T08:57:16 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74884 <pre>Hi all. Found a bug in ShapeDrawable.cpp This is verified in 3.0.1 and 2.9.11: Bug in OpenSceneGraph/src/osg/ShapeDrawable.cpp, void DrawShapeVisitor::apply(const Capsule&amp; capsule) : If numRows becomes odd, the capsule top and bottom parts created with two calls to drawHalfSphere will not align with the cylinder body created with drawCylinderBody. Easiest seen if with large radius and few rows. Example capsule parameters: height 8.4 radius 5 Set detail ratio hints to 0.35 so numRows becomes 7. Misalign. Change hints to 0.4, numRows becomes 8 and capsule part aligns. Fix: If numRows is odd, add one before calling drawHalfSphere. I don't think the user should be aware of this and have to pick a suitable detailRatio. Cheers, Anders </pre> Anders Backman 2012-05-24T08:06:25 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74883 <pre>Hi Michael, On 24/05/12 12:45 , michael kapelko wrote: You can mix C, C++ and ObjC on iOS. So the meat of your app could be in C++ talking to OSG and the UIKit stuff can be in ObjC. Cheers, /ulrich </pre> Ulrich Hertlein 2012-05-24T04:26:07 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74882 <pre>Hi, Thomas. I was thinking about iOS recently and decided to ask you, if you coded those apps in C++ or Obj-C? I heard you need to write Obj-C on iOS? 2012/4/24 Thomas Hogarth &lt;thomas.hogarth-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;: </pre> michael kapelko 2012-05-24T02:45:16 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74881 <pre>Greetings! For what it worth, They where trying to port WWII- Online over at Corner Rat Software. I wasn't involved directly in that effort at the time (our Mac Programmer was at the time I was there), I was too busy on the current game effort making sure the infantry move right and to deal with other smoke-n- mirror stuff. I left CRS before they finished anything to work with the DOD again. I don't recall if they fished it! I'm in the process of doing a Dancing Anime Girl on Stage - Hatsune Miku. I've been so tied up on other off work projects, so the effort keeps getting pushed off! michael kapelko wrote: ------------------------ David Glenn --------------- D Glenn 3D Computer Graphics &amp;amp; Media Systems. www.dglenn.com ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47826#47826 </pre> David Glenn 2012-05-23T17:54:26 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74880 <pre>Hi George, The DataVariance property of osg::Object is used in couple of ways. For internal nodes of the scene it is used as a hint to operations such as the osgUtil::Optimizer that parts of the scene graph are static or dynamic and to use this information as guide to what can be optimized and in what ways - generally it means leaving DYNAMIC nodes alone. The DataVariance property on Nodes isn't used during the update, cull and draw traversals so it's effectively ignored. For the leaves of the scene graph - the osg::StateSet and osg::Drawable (and it's subclasses), the DataVariance is only used when using the DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext threading models and is used during the draw traversal to prevent the next frame from commensing till all DYNAMIC StateSet and Drawables are dispatch. For SingleThreaded and CullDrawThreadPerContext threading models the DataVariance is not used as the next frame doesn't commence till the whole draw dispatch is completed. The DataVariance of the StateAttribute subclasses is not used in update, cull or draw traversals, and like nodes is only used be specialist traversals like some of the ones contained in the Optimizer. So if you want to dynamic update a Uniform then the way to make sure that draw doesn't overlap the update of it is to set the DataVariance of the StateSet that enclose it to DYNAMIC. There isn't an automatic scheme to check the DataVariance of StateAttributes as it would be prohibitively expensive to do during the draw traversal. Robert. On 23 May 2012 16:36, George Bekos &lt;bekosftw-EMRzualFZlQ&lt; at &gt;public.gmane.org&gt; wrote: </pre> Robert Osfield 2012-05-23T16:22:11 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74879 <pre>Hello OSGers! :) Let's say that I have an osg::StateSet with some osg::Materials or osg::Uniforms attached to it. The osg::Material or osg::Uniform changes values during the run time, and because of that I set their DataVariance to DYNAMIC. Do I also have to set the DataVariance of the osg::StateSet to DYNAMIC? What if I have an osg::Geode on which I add/remove Drawables during the run-time? What if I have an osg::Drawable which I update its geometry in every frame? Do I have to set the DataVariance of the osg::Geode to DYNAMIC? Could someone tell me if (and when) the DataVariance property of an osg::Object is inherited to its parent or children automatically? Thanks for your time! Cheers, George ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47824#47824 </pre> George Bekos 2012-05-23T15:36:38 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74878 <pre>Hi Trystan, On 22 May 2012 17:35, Trystan Larey-Williams &lt;trystan-l79J1C/qZ3BAfugRpC6u6w&lt; at &gt;public.gmane.org&gt; wrote: At a high level the OSG state is managed in way that is relatively self contained without state bleeding out from one operation to the next. In your particular usage pattern it might not be the 100% most convenient thing for the OSG to do, but what you are doing is very niche, the OSG can't handle everyone niche requirements in the more effortless way, such a utopia is an impossibility. Robert. </pre> Robert Osfield 2012-05-23T11:27:51 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74877 <pre>Hi Frederic, On 23 May 2012 09:41, Frederic Bouvier &lt;fredlist01-GANU6spQydw&lt; at &gt;public.gmane.org&gt; wrote: I don't recall any changes that should effect the support for multiple contexts between 2.9.x and the present day, it all should work as before. I also don't recall any reports of problems with multi-context support so I would be surprised if they has been an OSG specific regression. More likely is that drivers/OS have changed in way that is causing a regression. There has been a shader related fix since 3.0.x which can be found in 3.1.x and svn/trunk that can effect some programs on NVidia, this isn't related to context though. This won't be related to multi-context support but might be worth trying rather than trying to use older versions of the OSG. Robert. </pre> Robert Osfield 2012-05-23T08:49:24 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74876 <pre>Hi Wojciech, Thank you for taking the time to reply to my question. I made some progress. First I use only one monitor per GPU because I need color calibration for my photography work and the Windows architecture has only one LUT per card. But I temporarily hooked up the second monitor to the first card and activated SLI. The same issue occurs in osgViewer : only the primary display is refreshed. But FlightGear has a handy configuration system where we can setup windows/graphic contexts and cameras separately. As you suggested, when I create only one window that span on both monitors (on screen 0) and bind the two cameras to two viewports of this window, both viewports are updated. I have a vague recollection that my setup with 1 monitor per GPU and 2 graphic contexts used to work with a 2.9 OSG. Unfortunately FlightGear has evolve in a way that it requires 3.0 but I will try to get osgViewer work with an older version. I also remember seeing submissions on the way swapping is done in OSG. Maybe there is something related Regards, -Fred ----- Mail original ----- De: Wojciech Lewandowski Hi, Frederic, I was testing similar situation on GeForces more than 2 years ago (I left the building in the meantime) and honestly don't remember if we have found 'an always working' recipee for this problem. All I remember we were somehow able to use multiple cards with multiple monitors but honestly I am not sure if this was just luck with drivers or we did some extra tricks (we tried several workarounds back then). This problem is probably related to Windows DWM screen update scheme vs NVidia optimizations and Windows 7 design that primary card renders all OpenGL contexts so second card is practically not used. I could be wrong but I believe we had most success with NVidia surround where we set up single Window spanning all monitors and this window was split into 3 or 4 viewports matching particular monitors. So I really don't have a solution but would recommend to test various options and select the best one. - Test single card dual monitor output vs dual card sli dual monitor vs dual card / dual monitor. I remember that after this test we realized it does not make sense to buy second card which is practically not used. SLI mode seemed to not bring more performence in our scenarios (this may vary for you of course). So we realized that unless we do not want to use more than 2 monitors we will not buy another card. And even with more monitors it would make sense to buy powerful card as primary and weak one as secondary adapter because it will be practically used as passthrough for graphics rendered on first one. For Surround mode it may be neccessary to use the same cards though, (don't remember exactly). Above problem only affects GeForces. Quadros provide extension which can be used to assign GPU to window. h ttp://developer.download.nvidia.com/opengl/specs/WGL_nv_gpu_affinity.txt Unfortuantely NVidia chose to not provide it for GeForces. I also believe that Radeons have introduced similar extension a year or two ago. - Do above tests with NVidia surround. - Try playing with NVidia control panel settings (threading optimization / swap method) And certainly must have options are: - Aero off / fullscreen mode to avoid DWM quirks HTH, Wojtek Lewandowski 2012/5/20 Frederic Bouvier &lt; fredlist01&lt; at &gt;free.fr &gt; Paul, I see the same issue with 3.1.2 Regards, -Fred ----- Mail original ----- De: "Frederic Bouvier" &lt; fredlist01&lt; at &gt;free.fr &gt; À: "OpenSceneGraph Users" &lt; osg-users&lt; at &gt;lists.openscenegraph.org &gt; Envoyé: Dimanche 20 Mai 2012 10:10:42 Objet: Re: [osg-users] Multiple GPU/monitor issue on Windows 7/NVidia Hi Paul, I should have stated that I am using OSG 3.0.1. Is there a fix in a development release ? Regards, -Fred ----- Mail original ----- De: "Paul Martz" &lt; pmartz&lt; at &gt;skew-matrix.com &gt; I thought this was an old issue already fixed. Are you saying this is still occurring on the current OSG trunk? What versions of OSG have you tested? -Paul On 5/19/2012 9:03 AM, Frederic Bouvier wrote: _______________________________________________ osg-users mailing list osg-users&lt; at &gt;lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users&lt; at &gt;lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users&lt; at &gt;lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users&lt; at &gt;lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users&lt; at &gt;lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org </pre> Frederic Bouvier 2012-05-23T08:41:29 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74875 <pre>Hi Pau, On 23 May 2012 08:31, Pau Estalella &lt;pau.estalella-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: You don't need to enable the alias of the vertex arrays if you are using shaders, it's only for cases where OpenGL provides no built-ins for vertex array data such as when using OpenGL ES 2 or the core profile of OpenGL 3.x+. See the osgshaders and other shader related examples. Robert. </pre> Robert Osfield 2012-05-23T07:48:44 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74874 <pre>Hi Robert, I was hoping to be able tu use OSG functionalities like text labels, realtime stats or 3ds model loading without having to write and apply shaders to all of them. Shaders which have to be custom tailored to the ways of OSG (tex unit numbering, illumination models, etc) At the same time, I need to use my own shaders for my own needs. ... Thank you! Cheers, Pau ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47818#47818 </pre> Pau Estalella 2012-05-23T07:31:53 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74873 <pre>Hi Robert, I was hoping to be able tu use OSG functionalities like text labels, realtime stats or 3ds model loading without having to write and apply shaders to all of them. Shaders which have to be custom tailored to the ways of OSG (tex unit numbering, illumination models, etc) At the same time, I need to use my own shaders for my own needs. ... Thank you! Cheers, Pau ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47817#47817 </pre> Pau Estalella 2012-05-23T07:31:37 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74872 <pre> Hi, Janosch, Picking works based on traversing the scene, and not necessarily just what's drawn on the screen. You said that you render part of your scene to a texture. Are you sure you're not picking from that same scene? --"J" On 05/22/2012 03:47 PM, Janosch Machowinski wrote: </pre> Jason Daly 2012-05-22T20:08:26 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74871 <pre>Hi, sorry I just figured out that I didn't make my problem clear. I can pick ghost objects. Even if nothing is drawn at a particular position on my screen, I get picks to objects that were rendered to the texture. Greetings Janosch On 22.05.2012 20:48, Janosch Machowinski wrote: </pre> Janosch Machowinski 2012-05-22T19:47:17 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74870 <pre>Hello, I got a problem with picking and render to texture. I use an osg::Camera to render a part of my graph to a texture and display it in an HUD. My problem now is that when I pick, I can also pick objects that were rendered to the texture. My question would now be how could I avoid that any object of the subgraph that is rendered to the texture gets picked ? Alternatively it would be ok, if I could pick on the quad showing the texture and get the object that was rendered to it. Greetings Janosch </pre> Janosch Machowinski 2012-05-22T18:48:25 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74869 <pre>No projection is set in my example. What I want to know is why main camera and slave camera produce different result. When you use setCamera(.) rather than addSlave(.), the result is perfect by default. On Wed, May 23, 2012 at 1:17 AM, Trystan Larey-Williams &lt;trystan-l79J1C/qZ3BAfugRpC6u6w&lt; at &gt;public.gmane.org </pre> GeeKer Wang 2012-05-22T18:16:39 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74868 <pre>I don't see a projection matrix being explicitly set. I think OSG does a perspective projection be default. Especially depending on the default FOV, this can produce a pronounced distortion. See the camera methods setProjectionMatrixAsPerspective and setProjectionMatrixAsOrtho. If you want no distortion then you probably want the latter. -Trystan ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47811#47811 </pre> Trystan Larey-Williams 2012-05-22T17:17:18 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74867 <pre>Thanks for the reply. What I ended up doing was to have a separate FBO (obtained trough native OGL calls) in the PostDrawCallback. Then I bind the texture (same one used in the FBO that performs the render) to this FBO in the callback and was then able to do a glReadBuffer/glReadPixels on the GL_COLOR_ATTACHMENTi buffers successfully via a PBO (although I'm not sure the PBO is really helping in this case). So, this seems to confirm that the FBO I had the texture attached to for the render is indeed released before the callback. It would save a lot of hassle if the one of the DrawCallbacks could be invoked while the render targets for the camera were still intact. But I assume there's some reason for the current behaviour. Anyone venture a guess? Thanks, Trystan ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47810#47810 </pre> Trystan Larey-Williams 2012-05-22T16:35:16 http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/74866 <pre>Hi Filip, On 22 May 2012 15:39, Filip Arlet &lt;filip89-9Vj9tDbzfuSlVyrhU4qvOw&lt; at &gt;public.gmane.org&gt; wrote: The DatabasePager has lots of elements in it's design that are fundamentally linked to cull traversal, both for loading of tiles and expiry of no longer required tiles. It's not a general purpose tool for loading data in bakground, and my guess is that you may well not actually require the DatabasePager but would be better served by developing your own thread management for you specific needs. Writing a loader that works in the background and sync's with the main scene graph during the update phase is pretty straight forward, one needn't go to all the complexity that the DatabasePager has to for load balancing so you should be able to keep the implementation simple. Robert. </pre> Robert Osfield 2012-05-22T15:14:20 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.graphics.openscenegraph.user