Re: [osg-users] animating textures
ah - I should have been more specific with what I meant by animation. I want to fade between two textures so that the previous texture slowly gets weaker while the new texture slowly gets stronger. Can shaders manipulate the texture opacity? (I expect so.) And do you think this is a better approach than what OSG provides with the MultiTextureControl? Julia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9766#9766 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animating textures
Hi Julia, If you mean sliding images in a sequenced order you can look at osgimagesequence example. Or you mean rotating, translating, retexturing in new texture coordinate you can achieve these kind of operation by using fixed openGL functions or you can use GLSL to manipulate texture coordinate in fragment shader section. You code only couple of line in fragment shader. I have not ever tried osganimation or osgfx nodekit to get kind of result on textures. Best Regards. 2009/4/6 Julia Guo > Hi, > > I am trying to animate a transition between textures on a surface. > I had a look in osgAnimation ( > http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01556.html) > but that namespace seems to be just related to geometry. I found > osgFX::MultiTextureControl ( > http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00429.html), > which can control which textures are active and how to blend them, but > doesnt support animating. > > So to animate between textures should I create a callback to update the > texture control (like the rotate example in the manual)? Or is there a > better approach? > > Thank you. > Julia > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=9763#9763 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight-Plugin - How to store individual object in seperate geode?
Hi Brede, Thanks for the reply. I did a search on the setPermissibleOptimizationsForObject() fucntion and read your posting on osg-users mail-archive, and yup, I think very high chance that this will solve my problem [Wink] But unfortunately, I couldn't find any reference on how to use this function. The first parameter is an osg::Object pointer. Should I pass in every geode (using a geodeVisitor)? As for the second parameter, it will be all the optimization options, except MERGE_GEOMETRY? Also please advise if there's any reference manual that I can refer to? The one on osg wiki page doesn't give much info. Thanks in advanced. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9764#9764 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] animating textures
Hi, I am trying to animate a transition between textures on a surface. I had a look in osgAnimation (http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01556.html) but that namespace seems to be just related to geometry. I found osgFX::MultiTextureControl (http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00429.html), which can control which textures are active and how to blend them, but doesnt support animating. So to animate between textures should I create a callback to update the texture control (like the rotate example in the manual)? Or is there a better approach? Thank you. Julia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9763#9763 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgmultitexturecontrol example data base?
hi, Im also trying to run the example. Is the example data ready? Julia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9762#9762 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VertexArray from a loaded .osg file.
Hi, i'm using osggis to convert an esri shape file to an .osg file. i want to use the scenedata, more precisely the vertex positions from that file. i need them for an analyzing function, and won't add that loaded file directly into my scenegraph, because i don't want to display it before analyzing is done. is it possible to use the VertexArray from the loaded scenefile in a new created Drawable (which will display my analyzing results), AND add additional vertices, based on the analyzing process to it? Or will i have to allocate a new VertexArray for my Drawable and copy the loaded file's VertexArray by Value into it? Thanks in advance, christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9761#9761 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] when to use VertexBufferObjects or DisplayLists
hi, refering to osgforest as example, is a method like createTransformGraph, where the different looking trees are based on the same (scaled) tree model better from a performance point of view? i mean better than the two other fixed pipeline methods in this example thanks in advance, christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9760#9760 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to pass unhandled events to view behind + osgWidgets
Hi Jason, Good to hear you've found a solution. Managing the events with a composite viewer is a bit more complicated because of deciding who gets the event focus. The API of osgViewer::View/CompositeViewer probably needs evolving to make it easier, exactly what it should look yet I can't say. Putting an osg example together that does something similar to what your app is doing would probably help out with provide an awkward test case that pushes the current viewer usage beyond what it can do comfortable now. Once we have a good example we'd then be able to look at refactoring osgViewer to make the example cleaner, and make life for users following on from yourself just that little bit easier. Cheers, Robert. On Sun, Apr 5, 2009 at 5:29 PM, Jason H. wrote: > I think I have found a workaround. I have createad a new GUIEventHandler to > handle only mouse events. I then check whether menu viewer has handled the > message. If no, then I iterate through views of composite viewer, locate the > camera at mouse coordinates and put event into event queue of view > contianing mouse pointer. > > This workaround currently has one known issue. If I drag it too much and > cross boundary of view, trackball manipulator of next view kicks in. I think > this is somewhat easy to solve (by storing camera which the drag has begun > and stick to it until a release event), but it makes me wonder whether I > will have similar issues that I will need to tend to. > > Also, when this menu view is present (which occupies whole screen), > movement in viewports become visibly slower. > > I will try to dynamically adjust menu view rectangle when mouse hits there > or when a menu pops down. > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=9758#9758 > > > > > > ___ > 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] How to pass unhandled events to view behind + osgWidgets
I think I have found a workaround. I have createad a new GUIEventHandler to handle only mouse events. I then check whether menu viewer has handled the message. If no, then I iterate through views of composite viewer, locate the camera at mouse coordinates and put event into event queue of view contianing mouse pointer. This workaround currently has one known issue. If I drag it too much and cross boundary of view, trackball manipulator of next view kicks in. I think this is somewhat easy to solve (by storing camera which the drag has begun and stick to it until a release event), but it makes me wonder whether I will have similar issues that I will need to tend to. Also, when this menu view is present (which occupies whole screen), movement in viewports become visibly slower. I will try to dynamically adjust menu view rectangle when mouse hits there or when a menu pops down. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9758#9758 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] when to use VertexBufferObjects or DisplayLists
Hi Christian, VBO's are better for dynamic geometry, but do have a higher CPU overhead than display lists. However, whether you are using VBO or not, you probably still don't want to modify any geometry. It's far more efficient to updating vertex position via vertex shaders. I know too little about your code to be specific, but as a general note that graphics hardware works best with state geometry and primitive sets and with relatively large batches of geometry sent together. Sending lots of indivual trees geometries is inefficient for both the GPU and the CPU. Robert. On Sun, Apr 5, 2009 at 12:11 PM, Christian Sam wrote: > Hi, > > i have a question about using VBOs and Display Lists in osg > > according to my OpenGL book, both methods will optimize rendering due > geometry is moved to the graphics-hardware. it also says, a constraint when > using display lists is, that data can't be changed afterwards. so its great > for rendering the same object multiple times, but not when you want to > modify it. > > in my application i'm rendering a forest. i want to have a handful of > different tree sprites, which will vary in size and color (but not in > texture). as far as i know osg uses display lists by default - will i > benefit from a switch to vertex buffer objects, because in this case many > states will stay the same and only geometry will vary/be modifed through the > different tree sprites? > > > best regards, > christian > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=9755#9755 > > > > > > ___ > 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] osgdrawinstanced - supported on GeForce 7900GTX?
Hi Paul, > JS - Do you have GLView? > http://www.realtech-vr.com/glview/ > > It will tell you whether your card supports the draw instanced extension or > not. Oh, you're right, I have it on my work PC but not at home, I didn't think of that. I'll check it out. But with I think Robert's right, I don't have much hope. Time to get a new card methinks... Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] when to use VertexBufferObjects or DisplayLists
Hi, i have a question about using VBOs and Display Lists in osg according to my OpenGL book, both methods will optimize rendering due geometry is moved to the graphics-hardware. it also says, a constraint when using display lists is, that data can't be changed afterwards. so its great for rendering the same object multiple times, but not when you want to modify it. in my application i'm rendering a forest. i want to have a handful of different tree sprites, which will vary in size and color (but not in texture). as far as i know osg uses display lists by default - will i benefit from a switch to vertex buffer objects, because in this case many states will stay the same and only geometry will vary/be modifed through the different tree sprites? best regards, christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9755#9755 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SGI declares bankruptcy (UNCLASSIFIED)
For Pixar involvement, I just re-read it, it is in the Renderman Companion, in the last part of Pat Hanrahan foreword (May 1989). "... *During this time, we also began a joint project with Silicon Graphics to work on a three-dimensional graphics library usable for both interactive graphics and high-quality rendering* ..." (the time he's referring there is the time when the RISpec was built) Not sure though if that joint project is IrisGL, or if it's something else actually... Thanks for sharing! Raphael On Sun, Apr 5, 2009 at 12:25 AM, Paul Martz wrote: > Not sure about Pixar's involvement. > > The Genesis of OpenGL varies depending on who you ask. People inside SGI > say that OpenGL was driven by customer demand. Their users wanted to see > IrisGL deployed on non-SGI platforms. SGI tried this with a fee hardware > vendors, but the support was spotty, different vendors supported IrisGL in > different ways, and the same app did not run the same way across platforms. > So SGI came up with OpenGL and designed it in such a way that anyone could > support it well. > > However, if you talk to anyone in the PHIGS/PEX camp during the late > 80s/early 90s, they'll tell you that SGI was feeling threatened by the > widespread adoption of PHIGS/PEX, and decided to turn IrisGL into an open > standard ("OpenGL") in order to kill off PHIGS/PEX. > > PEX was an open standard adopted by just about anyone with X Windows on > their box, but SGI had not been invited to join the PEX consortium. So there > was some animosity there. > > Paul Martz > *Skew Matrix Software LLC* > http://www.skew-matrix.com > +1 303 859 9466 > > > -- > *From:* osg-users-boun...@lists.openscenegraph.org [mailto: > osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Raphael Sebbe > *Sent:* Saturday, April 04, 2009 3:28 AM > *To:* OpenSceneGraph Users > *Subject:* Re: [osg-users] SGI declares bankruptcy (UNCLASSIFIED) > > Jumping in... > Well, I would definitely be interested in getting more history background > about the original design of the OpenGL API. There was a collaboration > between Pixar and SGI in the late 80s, probably around the same time that > both IrisGL and the Renderman specification emerged. Pixar had been working > on this for some time, yet, I am unsure of how the whole process of OpenGL > (IrisGL) happened. Did Pixar propose the Renderman specification to SGI, > which then proposed a real-time api inspired on that? Or did SGI develop > this all internally and by chance came to some similar design? > > Raphael > > > > On Fri, Apr 3, 2009 at 10:42 PM, Paul Martz wrote: > >> As the British punk band The Stranglers used to say, "Everybody loves you >> when you're dead." >> >> Sure, SGI did some things pretty well, but let us not forget they also did >> some things pretty poorly, and in my opinion were really not much better >> or >> worse than many other hardware vendors. >> >> Things they did well: OpenGL 1.0 was a masterpiece of design that took the >> graphics world by storm and utterly crushed several other competing APIs >> of >> the era. This is an API that is so well-accepted that it has outlived its >> creator. >> >> Things they didn't do well: Too much focus on the high end. Bad business >> decisions. No focus on open standards until absolutely forced to do so. >> Not >> able to keep pace with the industry (look where they are now). >> >> And marketing faux pas... When OpenGL 1.0 first came out, SGI marketing >> constantly repeated the notion that immediate mode was the most important >> thing in the world. (This was a direct slam against the PHIGS/PEX APIs, >> which were focused on retained mode.) At the same time, SGI was promoting >> their 1.1 million triangles/second hardware. However, all their demos had >> a >> performance HUD that clearly showed significantly less than 1.1m tris/sec. >> When pressed on this, they eventually published a benchmark that >> demonstrated 1.1m tris/sec, but it used display lists. Oops. >> >> Paul Martz >> Skew Matrix Software LLC >> http://www.skew-matrix.com >> +1 303 859 9466 >> >> ___ >> 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] vpbmaster vs osgdem
On Sat, Apr 4, 2009 at 8:45 PM, Gert van Maren wrote: > Hi Robert, > > Did you manage to open the zip file? If not I can attach only the last bits > of the log files. > Yes they just download fine. The three secondary split level tasks in the directory: vpb_task_logs/logs/build_subtile_L6_X57_Y9/ Have one of the files blank, one completed and one is incomplete. If they complete successfully then there will be an Elapsed time statement at end. The task that complete did so in a much quicker time than the task that didn't complete. Unfortunately there is no error messages that indicate why the build may have failed. What we can tell is that the task that generated build_subtile_L13_X7394_Y1195.log failed, so you could try to run this task in isolation. The task in question is tasks/build_subtile_L6_X57_Y9/build_subtile_L13_X7394_Y1195.task, where reads: application : osgdem --run-path F:\K2Vi\work_in_progress\Melbourne\osgdem -s build_master.source --subtile 13 7394 1195 --task tasks/build_subtile_L6_X57_Y9/build_subtile_L13_X7394_Y1195.task --log logs/build_subtile_L6_X57_Y9/build_subtile_L13_X7394_Y1195.log date : 2009/3/1 15:16:31 duration : 4465.65 hostname : guru3 pid : 3936 source : build_master.source status : pending So try simply running: osgdem --run-path F:\K2Vi\work_in_progress\Melbourne\osgdem -s build_master.source --subtile 13 7394 1195 --task tasks/build_subtile_L6_X57_Y9/build_subtile_L13_X7394_Y1195.task --log logs/build_subtile_L6_X57_Y9/build_subtile_L13_X7394_Y1195.log Hopefully this task will fail again, if it does then try and run it in a debugger to get a stack trace. Beyond this we don't really have any clues what have gone wrong. Another thing you could try is building under another OS. Windows isn't the best platform to do heavy duty lifting like large builds on as the file system is just too slow for this type of work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org