Re: [osg-users] How to make sure that both the back and the front side of a polygon are lit...
Hi Sunil, Sunil S Nandihalli writes: Hello everybody, I would like to have both the front and the back side of the polygons I draw lit. Right now I have specified the normals and only the side which is on the same side as that of the normals is being lit.. Should I render the same-geometry twice and add normals to it so that it is lit on both sides.. I realized this might not be the right way to do it.. Does any of you have any suggestion? You are already doing it right. Just render once, disable the face culling with osg::StateSet in order to allow both sides to be seen, and specify a material for the back side or at the same time you defined the front one. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Future of osgIntrospection + genwrapper, volunteers required.
Hi Mike, It would be appreciated if you and others can contribute to the 'newborn' osgIntrospection project. I've just finished updating all the cmake scripts and a new example which explains how to use the wrappers to construct and view a simple scene. Now people who use osgIntrospection in there own applications can have a complete test to see if there are any bugs or inconvenience. There are some more work in my todo list at present: 1. Merge the genwrapper utility and see if we can have a set of custom commands to automatically generate and compile wrappers from an input OSG directory. With this, we can remove those wrapper code directories out of the osgIntrospection source in the future. 2. Add a few more examples to help people be familar with this powerful library and make use of it. The newly submitted simple_example would be a not bad example, I hope. :) 3. Add examples and front-ends for binding OSG with other languages if possible. 4. Make sure the project can work on most platforms. I'm not used to the packaging on debian and ubuntu. Would you like to use CPack to create tarballs and automatically setting up packages? I believe it will be really useful to developers who prefer prebuilts. To submit changes, just start new threads on the osg-users (or osg-submissions? Is it permitted, Robert?). I'm looking forward to work with you to improve the osgIntrospection project. Cheers, Wang Rui 2010/6/29 Mike Wozniewski m...@mikewoz.com Hi Robert / Wang Rui, I'd be willing to help on this as well. Particularly, I'd like to help get a debian ( ubuntu) package out soon that includes osgIntrospection and genwrapper. Robert, can you add genwrapper to the new repository? Specific things that I am interested in: - ensuring that genwrapper builds properly - ensuring that genwrapper can find OSG's headers and build the wrappers - when the 2.9.9 tag is made for OSG, make a corresponding tag for osgIntrospection (and a tarball) - use the tarball to set up packaging for debian and ubuntu launchpad I'm more familiar with autotools, and would be willing to do all this in that style. However, cmake seems easy enough, so I could tackle this using cmake assuming that I could ask everyone some questions. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OT: Magic Planet
Hi all, has anyone used something like this before? http://www.globalimagination.com/products.html jp -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to make sure that both the back and the front side of a polygon are lit...
Hi Sunil, Just to be clear, you also need to specify a two-sided light model to make OpenGL apply both front and back materials. The osg::LightModel class allows this. Cheers, -Tony ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin to Node Kit?
Hi Brad, The plugins are designed to be entirely encapsulated within themselves and not to export any symbols, save for any C function entry points for enabling static linking of plugins. This decoupled approach does mean that you don't have any public interface to access internals classes/methods. In general this isn't an issue though. What specifically about the DirectShowTexture header do you need access to? It may be that you do what you want within any specific access to it. Keeping a loose coupling is generally the best programming approach as it enables you to change you backend implementation easily - such as if you needed to support a new platform. Robert. On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote: Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that I’m trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what I’m trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps I’m not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ 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
Hi Robert, On Monday 28 June 2010, Robert Osfield wrote: Yes, even if we tweak the API a bit in StateSet any new elements will sorted virtue of being in StateSet. Whatever we do StateSet's will remain the container for all things state in the scene graph, and the what basis of coarsed grained state sorting and lazy state updating that the OSG provides by default. Ok. So in effect you will know the final shader combination for a render leaf at cull time. Right? Yes, once you've traversed down the graph to the osg::Drawable leaves you know all the state inheritance and can compute the final program and uniform combination that will be required. Ok. Wouldn't it be better to match the final shaders programs at cull time instead of draw time? The only reason there might be an advantage is that if you draw traversal was more CPU limited than the draw. In general I would expect the cost of selecting the appropriate programs during draw will be very low relative to the cost of dispatching the data itself. Yes. The only part that might be expensive is the composition of the shader mains and then compiling these main shaders, but again the cost of composing the main shaders is likely to be much lower than the OpenGL side of compiling them, and you have to do the compiling in the draw traversal any so the saving again is likely to be be pretty small if detectable. True, compiling is expensive. But that is exactly what should be better done just once when a new shader combination appears. The final program should just be stored and reused once it is compiled *and* linked. I am sure that compiling a shader is expensive. But I am also sure that linking is *not* about for free. I expect that drivers will again do some optimizations once linking happens. For example there are GPU's out there which do not have jump instructions. In this case, linking must at least do inlining again. Also there are plenty of optimization opportunities that start to be available when the whole program is known. So, I expect that at link time the shader optimizer is started again and again improoves the shader code. So, what I think is that we need minimize shader compilation as well as shader *linking* as much as possible. If the implementation you have in mind really does this, then fine. If you intent to relink on about every StateAttribute::compose(osg::State) call, I expect to run into problems. Doing more work in the cull will mean we'll have to pass more data to draw which itself may result in a performance overhead as the extra data structures will need to be dynamically allocated/destroyed. Sure, malloc is to be avoided for real time. Anyway, I am thinking more about something that computes a probably scalar key or pointer to an already existing object that is able to identify the final shader program combination in the cull stage and sets that key into the render leaf. On apply this key is taken to apply the opengl shader object containing the already finished shader program. May be this key could be the to be cached final shader program. So, no per draw dynamic memory management with this kind of approach. Right I want to get things working, the API and the backend are going to be new and complex enough that I want to take the route of least resistance and not worry to much about small possible optimization. Moving more work into cull might be an optimization that would be worth doing, but then it could just as easily be worse for performance. Ok. The only thing that might then turn out problematic is that then there is the StateAttribute::compose(State) call which directly operates on the State object. Once this is in place, backward compatibility will never make that go away. In effect this will make a switch to a StateAttribute::compose(CullTimeShaderComposer) call impossible... That is the reason I am thinking about that current proposal for such a long time. May be the State should provide such a 'ShaderCompositon' object as a member and you let the state attribute work on this member of the State? Then this could be moved easier if this turns out to be critical? So, again the critical thing from my point of view: If you can make sure that we never relink during draw once no new shader combination appears, I believe we are fine. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Future of osgIntrospection + genwrapper, volunteers required.
Hi Wang Rui, Good to see osgIntrospection updates coming through ;-) On Tue, Jun 29, 2010 at 8:51 AM, Wang Rui wangra...@gmail.com wrote: To submit changes, just start new threads on the osg-users (or osg-submissions? Is it permitted, Robert?). It would be fine to keep discussions of osgIntrospection/genwrapper on osg-users and submissions on osg-submissions. While these are now a separate project we are still all one of the same family. Personally I'd use osg-submissions for code changes as I find it far easier to use it as a clear in tray, sending code changes to osg-users is really fraught with missing stuff amongst the higher traffic. One thing you might also consider is adding Mike to the list of writers, Jose Luis Hidalogo will need to set this up, but as this doesn't normally take too long to sort out. Is suspect with such a small project it probably won't be necessary to have too many writers. Cheers, Robert. ___ 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
Hi Mathias, 2010/6/29 Mathias Fröhlich m.froehl...@science-computing.de: So, what I think is that we need minimize shader compilation as well as shader *linking* as much as possible. If the implementation you have in mind really does this, then fine. If you intent to relink on about every StateAttribute::compose(osg::State) call, I expect to run into problems. I think you've mis-understood my intentions. My plan has been to cache the osg::Program and main shaders once they are generated, Roland's implementation also takes the route. Calls to StateAttribute::compose(osg::State) or it equivalent would only been done when a new shader combination is required. The only thing that might then turn out problematic is that then there is the StateAttribute::compose(State) call which directly operates on the State object. Once this is in place, backward compatibility will never make that go away. In effect this will make a switch to a StateAttribute::compose(CullTimeShaderComposer) call impossible... I don't think a CullTimeShaderComposer is a good idea, but a subclass from ShaderComposer is fine, so I don't think there is a tightly coupling issue at all. We just need to get the design right so we can alter subclass from ShaderComposer as well as write our own sets of shaders. That is the reason I am thinking about that current proposal for such a long time. May be the State should provide such a 'ShaderCompositon' object as a member and you let the state attribute work on this member of the State? As for the end of last week osg::State already has a ShaderComposer* get/setShaderComposer method :-) ShaderComposer is just a placeholder right now. Then this could be moved easier if this turns out to be critical? I think we'll need to be pretty easy going with what the final design is until we've played with actually implementing the code. Is pretty rare for a design to work perfectly once you start trying to solve real problems with it. For me the real test will be how well we can implement the fixed function pipeline within shader composition - if this works neatly and conveniently then we'll be well on track. So, again the critical thing from my point of view: If you can make sure that we never relink during draw once no new shader combination appears, I believe we are fine. I believe we'll all be in agreement here. This is certainly what I'm aiming for, all the designs I'm working on use a program cache as a fundamental part of the design, with state changes minimized. I don't see it all as much different to what we do know with creating texture objects, VBO's, display lists, it's just we'll be operating on a slightly higher level, it should all be the same principle - the OSG worries about doing things efficiently, and the scene graph developer just concentrates on composing the scene graph and state classes to get the result they want. Robert. ___ 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
I've not at the computer full time for the last couple of days so haven't been able to push the shader composition implementation on yet. Design wise I've been doing bits here and there. My latest thought is that we probably need to encapsulate the component that will go to make up shader composition as a single class/object. This class would contain a list of required shaders, the list of shader modes, and the shader main code injection rules. What to call this class is a problem... perhaps ShaderSet? ShaderComponent? ShaderChunk? Thoughts? For my own design doodling I've run with the name ShaderSet for this class, so will follow this in rest of the email, if we go for something different later then so be it. The role of the ShaderSet would be: 1) Provide a way of encapsulating all the details required to contribute a single chunk of functionality that will be combined with other active ShaderSet to provide final composed osg::Program. 2) Provide a convenient mapping of a single ShaderSet representing a single implementation that can be shared by multiple osg::StateAttribute objects, for instance all osg::Light objects would shader a single ShaderSet for all directional lights, another ShaderSet for all positional lights etc. If different state attribute objects shader the same ShaderSet then there it will be easily to test whether shaders are the same simply be testing the pointer value, we needn't look into the contents. This approach works well for the OSG right now with how we manage osg::StateSet or the StateAttribute within them, so I'm pretty comfortable that this approach will be useful when doing shader composition and keeping the costs of lazy state updating down. 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader objects would target which ever part of the overall program that the ShaderSet effects - be in multiple osg::Shader for vertex programs, one of vertex program one for fragment, or any combination. The individual osg::Shader objects could also be shared by multiple ShaderSet where appropriate. 4) The StateAttribute would have a ShaderSet which defines all the shader setup required, this ShaderSet would typically be shared by all instances of that type of StateAttribute. The StateAttribute also have zero more uniforms that pass in values to the shaders in the ShaderSet, these uniforms wouldn't typically be shared, but would be solely owned by each separate StateAttribute object. The StateAttribute's ShaderSet would only ever be queried if the shader modes associated with that ShaderSet and hence StateAttribute are enabled, and no cached osg::Program for the current configuration of enabled shader modes is available. 5) It might well be that some StateAttribute have unifoms but no ShaderSet, it might also be appropriate for some StateAttribute to have no uniforms and a ShaderSet. It might even be appropriate for a single StateAttribute to have multiple ShaderSet depending upon what mode it is in - for instance osg::Light might be implemented in such a way that you have one ShaderSet for a directional light, and one ShaderSet for position light, another for spot lights, another for per pixel lighting etc, and select the appropriate one depending upon the set up of the osg::Light. 6) Given osg::StateSet already has support for managing osg::Uniform directly perhaps we might even want to make it possible to assign ShaderSet directly along side them rather than nesting them within StateAttribute. A pure shader composition approach could do this, but for seamless support of existing fixed function StateAttribute based scene graph we won't be able to just this. However, have two ways of doing the same thing might just lead to confusion... so it's something I think we just need to implement and test to see how we get on. Anyway these are my latests thoughts. I will be out for much of today, but later in the week should get more time to start implementing some code to start experimenting with basic shader composition. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude
Hi, is there a way to set noRotation option again to the default value? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29479#29479 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setting a color to material
hi all, can i set a both color array and material in one geometry? thanks, Nitin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setting a color to material
yes. You can set the color directly for the Geometry and the Material as a State -Nick On Tue, Jun 29, 2010 at 5:37 PM, Nitin Rangari rangari.niti...@gmail.comwrote: hi all, can i set a both color array and material in one geometry? thanks, Nitin ___ 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] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude
Gianni Ambrosio writes: Hi, is there a way to set noRotation option again to the default value? I don't know if it is possible from the command line. You could osgconvert the files that are in odd orientations. Programmatically, just don't use the same osgDB::Options object in the next read. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] terrain cracks
sorry for the late reply ! i build another terrain with other dem and imagery and it worked fine i don't know why ... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29483#29483 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude
Alberto Luaces wrote: Programmatically, just don't use the same osgDB::Options object in the next read. Yes Alberto, I mean programmatically. What do you mean by that? What if I would like to use the existing osgDB::ReaderWriter::Options as is but just without the noRotation setting? If I overwrite the Options object I think I would loose all the other options. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29484#29484 ___ 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
Hi Robert, On Tuesday 29 June 2010, Robert Osfield wrote: I believe we'll all be in agreement here. This is certainly what I'm aiming for, all the designs I'm working on use a program cache as a fundamental part of the design, with state changes minimized. I don't see it all as much different to what we do know with creating texture objects, VBO's, display lists, it's just we'll be operating on a slightly higher level, it should all be the same principle - the OSG worries about doing things efficiently, and the scene graph developer just concentrates on composing the scene graph and state classes to get the result they want. Fine then. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setFont
Hi All, I looked at the OSG examples in vain to understand how to load a font properly. OSG examples work fine if started from my dev environment (VS) but setFont(fonts/blablabla.ttf) does not work if I run my app normally double clicking on the .exe file. The osgtext example have the same problem and I read unable to load \fonts/fudd.ttf\ and the same for all fonts. Is there a way in OSG to load fonts without copying the ttf file in the exe dir or set the file in the resources? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29485#29485 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude
Hi Gianni, Gianni Ambrosio writes: Alberto Luaces wrote: Programmatically, just don't use the same osgDB::Options object in the next read. Yes Alberto, I mean programmatically. What do you mean by that? What if I would like to use the existing osgDB::ReaderWriter::Options as is but just without the noRotation setting? If I overwrite the Options object I think I would loose all the other options. Then you can use osgDB::ReaderWriter::Options::getOptionString(), remove noRotation there and then apply it again with osgDB::ReaderWriter::Options::setOptionString(). Or better, have two osgDB::ReaderWriter::Options objects... -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setFont
Gianni Ambrosio writes: Is there a way in OSG to load fonts without copying the ttf file in the exe dir or set the file in the resources? Setting the environment variable OSG_FILE_PATH. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setFont
Hello Gianni, I looked at the OSG examples in vain to understand how to load a font properly. OSG examples work fine if started from my dev environment (VS) but setFont(fonts/blablabla.ttf) does not work if I run my app normally double clicking on the .exe file. The osgtext example have the same problem and I read unable to load \fonts/fudd.ttf\ and the same for all fonts. TrueType fonts are loaded by the FreeType plugin (osgdb_freetype). The DLL for this plugin must be in your osgPlugins-version directory like any other plugin (loader), and if it has any depedencies (like a freetype DLL for example) these also must be findable by your app at runtime (in your PATH, or in your app's directory). If this is all findable, then the problem might be that your path to the font file is not correct. A font file is like an image, you need to give the right path. You might want to distribute your fonts with your app to make sure it can find them (make sure you use fonts you can redistribute in this way - check the license terms for the fonts you use or use open source fonts). So to sum up, a font file is like any other data file. Your path to load it must be correct, and OSG must have the plugin and its dependencies to be able to load it. You might be thinking of the system font directory, you could use that by using the WINDIR environment variable and then add \fonts\fontname.ttf to the end, but I wouldn't advise you use that since then you're dependent on what fonts the user has installed, and it's not portable to other operating systems. Much better to find an open source font you like and distribute it with your app. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.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] Rotating a vector by a quat
Hi, I am looking for an easy way to rotate a vec3d by a quat(roll, pitch, yaw). So if my vector is defined by (x,y,z) how do I figure out what the resultant of a spatial rotation of (roll, pitch, yaw) would be? I have calculated the final position of the vector using math but is there any other, more simpler way to do it in osg? Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29490#29490 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setFont
OK, so there isn't a special way to handle fonts in OSG. Thanks, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29491#29491 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transform Feedback
Hi, I guess my first question was too vague. Sorry about that. I am still trying to use transform feedback on an entire scene inside osg. I have created a CustomDrawable class with a drawImplementation that can perform transform feedback on anything drawn inside it. I am now trying to draw the entire scene inside my drawImplementation using a node visitor to traverse the graph and locate and draw all of the drawables with transform feedback enabled. I do not understand the parameters of void draw(osg::RenderInfo renderInfo) const function. Can you please explain what information RenderInfo contains? Is the RenderInfo different for each drawable or global for the scene? Is it possible to determine the RenderInfo of a drawable? Thanks, Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29492#29492 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin to Node Kit?
Robert, Here is what I would like to do: We have an existing app that has a GUI which builds a directshow graph including selecting a capture device and properties on that capture device and building the necessary intermediate filters. If I can pass a Directshow Pin (or pointer to pin) into the directshow texture then my work is done. Obviously this does require the tighter coupling of which you speak. Within the plugin architecture- the current abilities of osgDirectshow are not expressive enough. The alternative that I see would be way more complex and would be something like making the plugin read the .grf file format which allows specifying complex graphs. Also I would need to make our app able to write these files which it doesn't currently. Very much overkill in my opinion. The third alternative would be for me to expose DirectshowTexture but not to have commits accepted back to the community. Thoughts? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, June 29, 2010 3:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, The plugins are designed to be entirely encapsulated within themselves and not to export any symbols, save for any C function entry points for enabling static linking of plugins. This decoupled approach does mean that you don't have any public interface to access internals classes/methods. In general this isn't an issue though. What specifically about the DirectShowTexture header do you need access to? It may be that you do what you want within any specific access to it. Keeping a loose coupling is generally the best programming approach as it enables you to change you backend implementation easily - such as if you needed to support a new platform. Robert. On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote: Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that Im trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what Im trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps Im not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ 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] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude
Hi Alberto, Alberto Luaces wrote: remove noRotation probably my question is too stupid ... how can I remove it? I tried with: osgDB::ReaderWriter::Options* options = osgDB::Registry::instance()-getOptions(); options-removePluginData(noRotation) but it does not seem to work. I mean the Options object still contains the noRetation string inside. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29493#29493 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OBJ plugin loader places model at wrong position and with wrong attitude
OK, I think I didn't get the usage of the option string. I thought I could set a single option but it seems I have to set the whole option string again. So I have to parse the string to remove the noRotation substring ... if so, from my point of view it is not a user friendly API. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29496#29496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin to Node Kit?
Hi Brad, if the only thing you want is to pass paramters / objects to the plugin, so it sets up its stuff accordingly you can use ReaderWriter::Options::setPluginData and extend the DirectoShow-Plugin to use these plugin-data if available. So you can feed you directshow-pin to the plugin and set it up accordingly and you can submit these changes back to the community. This should work the other way round, too. Add the data you are interested in to the options-object, and use them afterwards. Just thinking loud, cheers, Stephan Am 29.06.10 17:57, schrieb Brad Huber: Robert, Here is what I would like to do: We have an existing app that has a GUI which builds a directshow graph including selecting a capture device and properties on that capture device and building the necessary intermediate filters. If I can pass a Directshow Pin (or pointer to pin) into the directshow texture then my work is done. Obviously this does require the tighter coupling of which you speak. Within the plugin architecture- the current abilities of osgDirectshow are not expressive enough. The alternative that I see would be way more complex and would be something like making the plugin read the .grf file format which allows specifying complex graphs. Also I would need to make our app able to write these files which it doesn't currently. Very much overkill in my opinion. The third alternative would be for me to expose DirectshowTexture but not to have commits accepted back to the community. Thoughts? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, June 29, 2010 3:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, The plugins are designed to be entirely encapsulated within themselves and not to export any symbols, save for any C function entry points for enabling static linking of plugins. This decoupled approach does mean that you don't have any public interface to access internals classes/methods. In general this isn't an issue though. What specifically about the DirectShowTexture header do you need access to? It may be that you do what you want within any specific access to it. Keeping a loose coupling is generally the best programming approach as it enables you to change you backend implementation easily - such as if you needed to support a new platform. Robert. On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote: Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that I’m trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what I’m trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps I’m not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin to Node Kit?
Stephan, Excellent idea. I'm still cutting my teeth on this stuff. I'll pursue this option. I'll see if I can find some examples of passing non-primitive types through the plugin options. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Stephan Maximilian Huber Sent: Tuesday, June 29, 2010 10:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, if the only thing you want is to pass paramters / objects to the plugin, so it sets up its stuff accordingly you can use ReaderWriter::Options::setPluginData and extend the DirectoShow-Plugin to use these plugin-data if available. So you can feed you directshow-pin to the plugin and set it up accordingly and you can submit these changes back to the community. This should work the other way round, too. Add the data you are interested in to the options-object, and use them afterwards. Just thinking loud, cheers, Stephan Am 29.06.10 17:57, schrieb Brad Huber: Robert, Here is what I would like to do: We have an existing app that has a GUI which builds a directshow graph including selecting a capture device and properties on that capture device and building the necessary intermediate filters. If I can pass a Directshow Pin (or pointer to pin) into the directshow texture then my work is done. Obviously this does require the tighter coupling of which you speak. Within the plugin architecture- the current abilities of osgDirectshow are not expressive enough. The alternative that I see would be way more complex and would be something like making the plugin read the .grf file format which allows specifying complex graphs. Also I would need to make our app able to write these files which it doesn't currently. Very much overkill in my opinion. The third alternative would be for me to expose DirectshowTexture but not to have commits accepted back to the community. Thoughts? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, June 29, 2010 3:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, The plugins are designed to be entirely encapsulated within themselves and not to export any symbols, save for any C function entry points for enabling static linking of plugins. This decoupled approach does mean that you don't have any public interface to access internals classes/methods. In general this isn't an issue though. What specifically about the DirectShowTexture header do you need access to? It may be that you do what you want within any specific access to it. Keeping a loose coupling is generally the best programming approach as it enables you to change you backend implementation easily - such as if you needed to support a new platform. Robert. On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote: Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that I'm trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what I'm trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps I'm not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ 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 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
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
[osg-users] Load of 8 bits image for creating texture
Hi, I try to load a 8bits image and create an osg::Texture2D with it. I search all the day but without sucess. It seems that the image load by osgDB::readImageFile(...) is transform in a 32 bits image. Is it possible to load it as 8bits image with an associated look up table ? (I didn't find attribut in osg::Image that could correspond to a lut, is there one ?) However if I can load my image as a 8 bits image, I don't know how I can associate the color table to the texture, is there a way to do that ? In fact and to clarify what I mean, here is the code in OpenGL I would like to translate in OpenSceneGraph : glColorTableEXT(GL_TEXTURE_2D, GL_RGBA8, 256, GL_RGBA, GL_UNSIGNED_BYTE, colorTable); glTexImage2D(GL_TEXTURE_2D, 0, GL_COLOR_INDEX8_EXT, width, height, 0, GL_COLOR_INDEX, GL_UNSIGNED_BYTE, texture); I hope I was enough clear. Sorry if I wasn't. Thank you very much for your help. Cheers, Adrien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29500#29500 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Graphical issues with display lists on ATI 5870 cards
Hi everyone, My company has been developing products using OSG for a few years now, and recently we've noticed some rendering issues on two machines that are both running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We wanted to know if anyone running similar hardware has seen these issues. We are using the 2.8.2 release of OSG. We notice two major graphical problems: * Incorrect lighting on primitives - flat geometry with equal vertex normals at all vertices appears to have incorrect lighting over the surface (using the default osgviewer lighting) * Corrupted textures - either a single pixel color over the entire surface or it looks like the UV coordinates were run through a blender We have tested rendering using the OSGViewer with a simple .osg file containing two triangles (forming a quad) with identical per-vertex normals and simple per-vertex UVs. What we have found is that we either have to disable display lists on the geometry in order to have the quad render correctly, or else we seem to be able to get correct results by adding additional (bogus) values to the per-vertex normal and UV lists to pad them. We believe this means that somewhere between OSG and the GPU the per-vertex data in the display list is getting corrupted and normals/UVs are getting lost. We have not experienced this issue in any other 3D apps on this hardware, including ones that use display lists. We also do not have the rendering issues with our app on other hardware (tested using several nVidia cards and and older ATI card). We think this may be an ATI driver bug, but we're not sure at this point and would like to hear if anyone else has run into these issues. Thanks. - Andy Peruggi Applied Research Associates, Inc[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29501#29501 ___ 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
Hi Robert and others, unfortunately I am experiencing some stressfull time at work which does not really allow me to contribute to this thread as much as I would like to. I am trying to keep up with the posts, but not all posts are clear to me. robertosfield wrote: 1) Provide a way of encapsulating all the details required to contribute a single chunk of functionality that will be combined with other active ShaderSet to provide final composed osg::Program. Isn't this what I solved with the ShaderMode class? Or is it that you are trying to separate the shader mode associated with a StateAttribute from the part that is responsible for adding of the piece of shader functionality. robertosfield wrote: 2) Provide a convenient mapping of a single ShaderSet representing a single implementation that can be shared by multiple osg::StateAttribute objects, for instance all osg::Light objects would share a single ShaderSet for all directional lights, another ShaderSet for all positional lights etc. If different state attribute objects share the same ShaderSet then there it will be easily to test whether shaders are the same simply be testing the pointer value, we needn't look into the contents. In my contribution I implemented a single ShaderMode that implements all fixed function lighting possibilities. For new types of lighting it seems more logical to indeed make a more fine grained breakup of ShaderModes. However there's a (minor) advantage to this one size fits all lighting code currently. To enable or disable lighting you simply can override a single mode. In the case where there are multiple lighting modes (directional, spot etc.) overall disabling of lighting needs to be done per lighting type. It might be needed that multiple ShaderSets implementing the same aspect/feature can be switched on or off all together with a single override. This will also be needed for instance in shadow map creation where in the first pass you would like to render geometry into a shadowmap as cheaply as possible and therefore without lighting. Perhaps multiple ShaderSets implement a the same aspect/feature in the final program that need to be disabled or enabled collectively. Again in the case of shadowmap creation you would like to only render geometry, no texturing, no lighting, no fog, but you do want to take into account skinned mesh deformation, wind deflection etc. robertosfield wrote: 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader objects would target which ever part of the overall program that the ShaderSet effects - be in multiple osg::Shader for vertex programs, one of vertex program one for fragment, or any combination. I guess you are more targeting shader linking instead of the code generation that I implemented. robertosfield wrote: The individual osg::Shader objects could also be shared by multiple ShaderSet where appropriate. It could, but is this likely to happen? robertosfield wrote: 5) It might well be that some StateAttribute have unifoms but no ShaderSet, I see no logical use case for this. What need is a uniform if there's no ShaderSet using it? robertosfield wrote: it might also be appropriate for some StateAttribute to have no uniforms and a ShaderSet. Like the normalize in the fixed function pipeline? robertosfield wrote: It might even be appropriate for a single StateAttribute to have multiple ShaderSet depending upon what mode it is in - for instance osg::Light might be implemented in such a way that you have one ShaderSet for a directional light, and one ShaderSet for position light, another for spot lights, another for per pixel lighting etc, and select the appropriate one depending upon the set up of the osg::Light. OK, understandable if you are targetting shader linking and taking into account what I wrote above. Some other notes: Like I discussed before I still would like to emphasize the need to be able to tune performance by balancing between shader program size and number of program switches. There is no optimal solution before knowing the actual usage scenario and therefore a user or internal OSG balancing system should be able to adapt this balance to improve rendering performance. A thing not solved in my ShaderModes based implementation is support for CPU side calculations needed by the simulation or renderer. This includes intersection testing and bounding box calculation. When implementing a new piece of shader functionality (for instance wind deflection) is typically is not hard to implement the same on the CPU side. If there exists a mechanism to make the intersection visitor walk through the same ShaderMode tree (or linked ShaderSets) it could made be possible to actually intersect a tree swaying in the wind. To clearify the aspect/feature override part mentioned above here's a different use case I have in mind. In a
[osg-users] Understanding Transparent Textures with an transparent image with alpha channels
I am attempting to utilize a transparent image as a texture map. I can successfully display the transparent image as a texture on a simple rectangular geometry. But, I would like to be able to see through to the background wherever the image is transparent. I've utilized the osgHelp program GeometryTexture as a baseline and I can load my image, but the transparent parts of the image show through to the default gray material of the underlying geometry. I see a gray rectangle with my image on top of it. Even though my image has many transparent areas. I would like to be able to see through the transparent areas of the image into the background. i.e. If all I have on the screen is a single rectangular geometry with my transparent image, then I'd like to see the blue background through the transparent parts of my image. Can anyone give me a pointer or advise? Thanks in Advance. Tim -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29503#29503 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphical issues with display lists on ATI 5870 cards
Hi Andy, I have seen some funky effects recently on Radeon 5970 4890. I was not able to install 10.6 on Windows 7 64 bit on 5970. Driver kept crashing with classic BSOD. But texture corruption you mention was present in 10.5 on Radeon 4890 as well. In both cases we switched back to Catalyst 10.4. We have read on the forums that ATI started to experiment with GL 3.3 4.0 recently and broke OpenGL 2.0 compatibility in latest drivers. My other observations on Catalyst 10.4 are related to Texture Matrix default not being identity in the shaders. Light attenuation factors seem to be incorrect in shaders as well. Frankly I don't have much experience with testing on Radeons, I ony have recently made few experiments. I could not count them as successful. Good thing about Windows 7 is one can have both NVidia ATI installed together. Card that displays main screen renders all OpenGL so usually after some frustrating tests on ATI, I quickly switch main monitor to NVidia ;-). Cheers, Wojtek -- From: Andy Peruggi aperu...@ara.com Sent: Tuesday, June 29, 2010 8:02 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Graphical issues with display lists on ATI 5870 cards Hi everyone, My company has been developing products using OSG for a few years now, and recently we've noticed some rendering issues on two machines that are both running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We wanted to know if anyone running similar hardware has seen these issues. We are using the 2.8.2 release of OSG. We notice two major graphical problems: * Incorrect lighting on primitives - flat geometry with equal vertex normals at all vertices appears to have incorrect lighting over the surface (using the default osgviewer lighting) * Corrupted textures - either a single pixel color over the entire surface or it looks like the UV coordinates were run through a blender We have tested rendering using the OSGViewer with a simple .osg file containing two triangles (forming a quad) with identical per-vertex normals and simple per-vertex UVs. What we have found is that we either have to disable display lists on the geometry in order to have the quad render correctly, or else we seem to be able to get correct results by adding additional (bogus) values to the per-vertex normal and UV lists to pad them. We believe this means that somewhere between OSG and the GPU the per-vertex data in the display list is getting corrupted and normals/UVs are getting lost. We have not experienced this issue in any other 3D apps on this hardware, including ones that use display lists. We also do not have the rendering issues with our app on other hardware (tested using several nVidia cards and and older ATI card). We think this may be an ATI driver bug, but we're not sure at this point and would like to hear if anyone else has run into these issues. Thanks. - Andy Peruggi Applied Research Associates, Inc[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29501#29501 ___ 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] moving object along rotated vector
Hi, I am attaching a screenshot of what I am trying to do. In the screenshot you can see 2 objects placed on a terrain. The lower one is rotated about Z axis and I use the keyboard UP and DOWN keys to move the object along the Y-axis in the terrain. However even after I have rotated the object, I am not able to figure out how to get the new vector along which the object is now pointing. I figured I would find the angle I have rotated the object by using Quat and then depending on angle value 0-90, 90-180, 180-270 or 270-360, find the tangent of the angle and move it that way. But I'm sure im complicating things here. The code I'm using to move the object and rotate is pasted below: (i've only copied the cases for Up and rotate right as down and left are identical) else if ( ea.getKey()==osgGA::GUIEventAdapter::KEY_Up) { std::cout textBox-getText() std::endl; positionArray = PATCurrent-getPosition(); //vector = PATCurrent-getAttitude().asVec3(); PATCurrent-getAttitude().getRotate(angle,vector); angleDegrees = osg::RadiansToDegrees(angle); y = positionArray.y(); x = positionArray.x(); x += vector.x(); y += 1; positionArray.y()=y; positionArray.x()=x; PATCurrent-setPosition(positionArray); return true; } else if ( ea.getKey()==osgGA::GUIEventAdapter::KEY_Right) { //use key right to rotate the object to the right quat = PATCurrent-getAttitude(); quat.getRotate(angle, vector); angleDegrees = osg::RadiansToDegrees(angle); //if angle is 0 make it 360 if(angleDegrees = 1) { angleDegrees = 360; } angleDegrees -= 1; quat.makeRotate(osg::DegreesToRadians(angleDegrees),vector); PATCurrent-setAttitude(quat); //PATCurrent-setPosition(vector); } If you can tell me what I am missing out here I'd be very thankful. Also, if there is some literature out there that deals with this, I'd be more than happy to study it. Thanks, Sincerely, Sanat -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29505#29505 Attachments: http://forum.openscenegraph.org//files/test_sc1_368.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org