Re: [osg-users] Renderer and SceneView classes
Hi Dan, SceneView is part of the original beginnings of the OSG, when it was single threaded, single context, and is now scheduled for deprecation. It will eventually be replaced entirely by functionality in osgViewer::Renderer, but for now I've simply reused SceneView. With any project that is a decade in the making you'll find a lot of history of it's evolution still in it, it's partly down to reusing code that does the job, and partly about maintaining backwards compatibility during transitions. So if you want to learn about the scene graph design and implementation keep this it mind that is living project, it's not only evolved alot through it's history, but it's still evolving a good old rate. As for creating a new scene graph in another language, I guess the OSG isn't too bad a place to start, but if you want to develop a really successful project you'll need under stand about wider project management as well as just the technical aspects of design and implementation. It also take a lot of work to write a full featured scene graph, hundreds of thousands of lines of code, and many man hours. Robert. On Sat, Nov 7, 2009 at 12:46 PM, Dan R nice...@gmail.com wrote: Hello, I'm new to OSG and am just looking over the code structure to better learn how a proper scene graph library is laid out. I'm interested in using (porting a stripped down version) of osg for a project I'm working on in another language. I pretty much understand the flow of the graph, however, when it comes down to the actual rendering traversal I get a bit lost. So I have these two questions, but maybe being directed to some older posts would be good answers... 1) The osgViewer::Renderer class appears frequently throughout the code, however, it seems to be based around the osgUtils::SceneView class. The SceneView class says that it's deprecated. Does this also mean that the Renderer class is deprecated, or simply that any calls to SceneView are no longer used in the normal work flow? 2) In a SingleThreaded case, where are the operations that result in rendering the Drawables get added? I see that in the renderingTraversals method, it first traverses the graph with a getBound() call, then goes through each camera and does a cull() (this uses a Renderer object from my first question), then goes through each GraphicsContext and calls runOperations. Where I get lost is, where are the operations for the GraphicsContext defined and added, that actually end up doing the work of rendering the drawables? Any direction in this case would clear a lot up for me, thanks, Dan ___ 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] Renderer and SceneView classes
OK thank you for the information. So whatever aspects of SceneView that Renderer is using now will eventually become part of the Renderer itself. I see that now. I'm not really interested in creating a separate library I just want to get OSG working for this project, but I can see that it would be a huge task porting it to a different language with different constraints. Anyway it's been a great learning experience going through the code. One further question, does actual rendering get invoked via the Renderer-cull() method? It looks like that then calls cull() and then draw() on the SceneView. Or is it the GraphicsContext-runOperations() that ends up rendering? Thanks, Dan On Sun, Nov 8, 2009 at 12:26 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Dan, SceneView is part of the original beginnings of the OSG, when it was single threaded, single context, and is now scheduled for deprecation. It will eventually be replaced entirely by functionality in osgViewer::Renderer, but for now I've simply reused SceneView. With any project that is a decade in the making you'll find a lot of history of it's evolution still in it, it's partly down to reusing code that does the job, and partly about maintaining backwards compatibility during transitions. So if you want to learn about the scene graph design and implementation keep this it mind that is living project, it's not only evolved alot through it's history, but it's still evolving a good old rate. As for creating a new scene graph in another language, I guess the OSG isn't too bad a place to start, but if you want to develop a really successful project you'll need under stand about wider project management as well as just the technical aspects of design and implementation. It also take a lot of work to write a full featured scene graph, hundreds of thousands of lines of code, and many man hours. Robert. On Sat, Nov 7, 2009 at 12:46 PM, Dan R nice...@gmail.com wrote: Hello, I'm new to OSG and am just looking over the code structure to better learn how a proper scene graph library is laid out. I'm interested in using (porting a stripped down version) of osg for a project I'm working on in another language. I pretty much understand the flow of the graph, however, when it comes down to the actual rendering traversal I get a bit lost. So I have these two questions, but maybe being directed to some older posts would be good answers... 1) The osgViewer::Renderer class appears frequently throughout the code, however, it seems to be based around the osgUtils::SceneView class. The SceneView class says that it's deprecated. Does this also mean that the Renderer class is deprecated, or simply that any calls to SceneView are no longer used in the normal work flow? 2) In a SingleThreaded case, where are the operations that result in rendering the Drawables get added? I see that in the renderingTraversals method, it first traverses the graph with a getBound() call, then goes through each camera and does a cull() (this uses a Renderer object from my first question), then goes through each GraphicsContext and calls runOperations. Where I get lost is, where are the operations for the GraphicsContext defined and added, that actually end up doing the work of rendering the drawables? Any direction in this case would clear a lot up for me, thanks, Dan ___ 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] Texture is rendered strange
Hi, Ive got a Problem. I have a Texture file loaded to a osg::Geometry. It is rendered completely different to what it looks like in the gimp. Why? Here is the code: Code: osg::Geometry* WidgElementGeometry = new osg::Geometry(); osg::Vec3Array* WidgElementVert = new osg::Vec3Array; WidgElementVert-push_back(osg::Vec3(750,550,-1)); WidgElementVert-push_back(osg::Vec3(800,550,-1)); WidgElementVert-push_back(osg::Vec3(800,600,-1)); WidgElementVert-push_back(osg::Vec3(750,600,-1)); osg::DrawElementsUInt* WidgElementInd = new osg::DrawElementsUInt(osg::PrimitiveSet::POLYGON,0); WidgElementInd-push_back(0); WidgElementInd-push_back(1); WidgElementInd-push_back(2); WidgElementInd-push_back(3); osg::Vec2Array* texcoords = new osg::Vec2Array(4); (*texcoords)[0].set(0.0f, 0.0f); (*texcoords)[0].set(1.0f, 0.0f); (*texcoords)[0].set(1.0f, 1.0f); (*texcoords)[0].set(0.0f, 1.0f); WidgElementGeometry-setTexCoordArray(0,texcoords); osg::Texture2D* WidgElementTexture = new osg::Texture2D; WidgElementTexture-setDataVariance(osg::Object::DYNAMIC); osg::Image* WidgElementImage; WidgElementImage = osgDB::readImageFile(WidgElementCorner.tga); WidgElementTexture-setImage(WidgElementImage); osg::Vec3Array* WidgElementNormals = new osg::Vec3Array; WidgElementNormals-push_back(osg::Vec3(0.0f, 0.0f, 1.0f)); WidgElementGeometry-setNormalArray(WidgElementNormals); WidgElementGeometry-setNormalBinding(osg::Geometry::BIND_OVERALL); WidgElementGeometry-addPrimitiveSet(WidgElementInd); WidgElementGeometry-setVertexArray(WidgElementVert); osg::Geode* WidgGeode = new osg::Geode(); WidgGeode-addDrawable(WidgElementGeometry); osg::StateSet* WidgElementStateSet = new osg::StateSet(); WidgGeode-setStateSet(WidgElementStateSet); WidgElementStateSet-setTextureAttributeAndModes(0,WidgElementTexture, osg::StateAttribute::ON); WidgElementStateSet-setMode(GL_BLEND, osg::StateAttribute::ON); WidgElementStateSet-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF); WidgElementStateSet-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19331#19331 attachment: Bildschirmfoto.pngattachment: WidgElementCorner.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] OSG Users in Korea
Hi, PM me, I'm currently in S Korea Thank you! Cheers, Aila earn money today (http://www.wordpressgoldmine.com/blog/earn-money-today-with-these-good-money-making-ideas.html) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19324#19324 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Robert Osfield wrote: Hi Dan, SceneView is part of the original beginnings of the OSG, when it was single threaded, single context, and is now scheduled for deprecation. It will eventually be replaced entirely by functionality in osgViewer::Renderer, but for now I've simply reused SceneView. Hi Robert -- There are large projects out there based on SceneView and getting along just fine without osgViewer. Removing SceneView would, at best, require them to migrate SceneView out of OSG and into their own app (where it would continue to work, barring future incompatible changes in OSG). And at worst, cost them an expensive port and re-verification of their product. I support marking SceneView as deprecated and replaced by Renderer, but think it would be wise to avoid changes to OSG that render SceneView inoperable. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Python port of osgviewerQT
There is an example script osgviewerQt4.py in the osgswig project. (using a combination of osgswig and PyQt4) see http://code.google.com/p/osgswig/ Succes, Rene 2009/11/5 christophe chappet christophe.chap...@gmail.com chappet wrote: Hi, Is there someboby that has ported the osgviewerQT into Python ? http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osgviewerQT/osgviewerQT.cpp I have a problem with the multiple inheritance. Thank you! Cheers, christophe I have attached my python port of the osgviewerQT file but the ViewerQT class declaration is not correct and generates the following error : Traceback (most recent call last): File F:\dev\workspace\PYGMT\src\PyGMT\GMT3D\AdapterWidget.py, line 91, in module viewerWindow = ViewerQT() File F:\dev\workspace\PYGMT\src\PyGMT\GMT3D\AdapterWidget.py, line 71, in __init__ self.getCamera().setViewport(osg.Viewport(0,0,self.width(),self.height())) File c:\Python25\lib\site-packages\osg-2.2.0-msw\osg.py, line 3564, in getCamera def getCamera(*args): return _osg.View_getCamera(*args) NotImplementedError: Wrong number of arguments for overloaded function 'View_getCamera'. Possible C/C++ prototypes are: getCamera() getCamera() I hope it helps. Cheers, christophe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19227#19227 ___ 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
