Re: [osg-users] Big fonts in current SVN
Hi Paul, On Dec 16, 2007 7:53 PM, Paul Martz [EMAIL PROTECTED] wrote: Thanks, Robert -- Unfortunately, this change had no effect. Maybe another avenue of attack might be to add DEBUG_INFO messages to osgText to display components that contribute to the final size of SCREEN-aligned glyphs? Then we could compare my DEBUG_INFO output against yours to see if that sheds any light? Today is going to be a very busy day for me so I won't be able to go chase this up right now. A close review of the changes that David made might reveal some possibilities. Adding more debugging as you suggest might also provide more time. Something for later in the week, unless others can jump in and help. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgFX::Cartoon makes gray
Hello, I am using osgFX::Cartoon node to optionally draw some molecules using cel-shading, the problem is that osgFX::Cartoon makes everything look gray and the color of the objects seems to be lost, is that intentional or am I missing something? All I do is to set the osgFX::Cartoon as the root node of the scene and then all the other nodes are made child of it. Thanks, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
Michele Bosi schrieb: Hello, I am using osgFX::Cartoon node to optionally draw some molecules using cel-shading, the problem is that osgFX::Cartoon makes everything look gray and the color of the objects seems to be lost, is that intentional or am I missing something? All I do is to set the osgFX::Cartoon as the root node of the scene and then all the other nodes are made child of it. Thanks, Michele You have to set a 1D texture to texture unit 0 for the cartoon shader. This texture defines the intensity or color ramp used for the cartoon lighting. You can use different colored ramps for different objects. regards Ralph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
I setup a texture to the shader node but it doesn't seem to solve the probem, here's how I setup my shader: mOsgRoot = new osg::Group; osgFX::Cartoon* toon = new osgFX::Cartoon; viewer- setSceneData(mOsgRoot); mOsgRoot-addChild(toon); toon-addChild(mEditor-osgGroup().get()); // this is the scene graph with various objects // apply the texture osg::ref_ptrosg::Texture2D texture = TextureManager::get()-loadTexture( cartoon.tga ); // half translucent red textue toon-getOrCreateStateSet()-setTextureAttributeAndModes( 0, texture.get(), osg::StateAttribute::ON || osg::StateAttribute::OVERRIDE ); I tried with different textures, black, gray, white, with and without alpha channel without luck. Is there a specified needed size for such a texture? do I need only the color information or also the alpha? I also attached a file showing the gray molecule. Thanks, Michele attachment: mol.PNG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
I guess you have to use a osg::Texture1D instead of osg:Texture2D regards Ralph Michele Bosi schrieb: I setup a texture to the shader node but it doesn't seem to solve the probem, here's how I setup my shader: mOsgRoot = new osg::Group; osgFX::Cartoon* toon = new osgFX::Cartoon; viewer- setSceneData(mOsgRoot); mOsgRoot-addChild(toon); toon-addChild(mEditor-osgGroup().get()); // this is the scene graph with various objects // apply the texture osg::ref_ptrosg::Texture2D texture = TextureManager::get()-loadTexture( cartoon.tga ); // half translucent red textue toon-getOrCreateStateSet()-setTextureAttributeAndModes( 0, texture.get(), osg::StateAttribute::ON || osg::StateAttribute::OVERRIDE ); I tried with different textures, black, gray, white, with and without alpha channel without luck. Is there a specified needed size for such a texture? do I need only the color information or also the alpha? I also attached a file showing the gray molecule. Thanks, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
Thank you for your suggestion I tried it but, again, no luck. Di you manage to have coloured cartoon-shaded objects? If so, what kind of texture did you use? Thanks, Mic On Dec 17, 2007 1:02 PM, Ralph Kern [EMAIL PROTECTED] wrote: I guess you have to use a osg::Texture1D instead of osg:Texture2D regards Ralph Michele Bosi schrieb: I setup a texture to the shader node but it doesn't seem to solve the probem, here's how I setup my shader: mOsgRoot = new osg::Group; osgFX::Cartoon* toon = new osgFX::Cartoon; viewer- setSceneData(mOsgRoot); mOsgRoot-addChild(toon); toon-addChild(mEditor-osgGroup().get()); // this is the scene graph with various objects // apply the texture osg::ref_ptrosg::Texture2D texture = TextureManager::get()-loadTexture( cartoon.tga ); // half translucent red textue toon-getOrCreateStateSet()-setTextureAttributeAndModes( 0, texture.get(), osg::StateAttribute::ON || osg::StateAttribute::OVERRIDE ); I tried with different textures, black, gray, white, with and without alpha channel without luck. Is there a specified needed size for such a texture? do I need only the color information or also the alpha? I also attached a file showing the gray molecule. Thanks, Michele ___ 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] Really Big Scenes and clipping
I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with osgText
Hey.. I'm using OSG 1.0 (I know It's little bit old...) I using VS2005 in c# application and using manage c++ layer between the GUI and the OSG window. When I first run my app I draw lines and osgText to the window. and all seems to work fine. Then I close the OSG form (not the application) and after I try to open again with different win32 HWND, I see the lines fine BUT in stand of the numbers I draw in osgText (the ones I saw good at the first run) I see quad polygons !!! please help... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor:: DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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] ANN: Reference Manual for v2.2 now available
I haven't been tempted by the reference manual book because I know how to navigate the source code and can't see how the relatively sparse comments therein would be more helpful compiled together. I think the situation is even worse once you get i thought this would be my experience too, after writing it, but i've been surprised. simply seeing all the methods laid out in a logical fashion (rather than how they might be typed into the header), seeing the documentation for a class side-by-side with it's _full_ inheritance hierarchy, and seeing some context (early chapters for osg overview, env var documentation, etc) have actually been interesting. i've even learned a few things in the process of writing / editing these things. yes, you can teach an old dog new tricks. outside the core OSG classes, so a credible documentation job would mean a lot of work for someone. i'll second that comment. at best, these things pay for beer and aspirin, both necessary after beating one's head against doxygen and latex. :) bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] implementing a bsp tree
Micah Heyer wrote on Saturday, December 15, 2007 12:25 PM: Hi every one, This may be stupid n00b question but, how would you recommend implementing a bsp tree in OSG?The three ways I thought of were: 1) use standard osg::Groups for each node and Geodes for leaf nodes. 2) subclass osg::Group for just the entire tree and instead of storing nodes in a std::list store in a custom bsp structure in which leaf nodes have a pointer to a geode. 3)subclass osg::Drawable and have it do all rendering independent of osg. The first option would seem to me to have a lot of overhead for a bsp. the second would be my preferred route,though I'm not sure I could implement it in a very elegant fasion. The third option would seem to reinvent the wheel but if that's the only drawback then maybe thats ok I don't know. Anyway I just thought I ask all you smart and experienced people out there if you have any advice for me. thanks, Micah You can probably implement (1) with the least amount of custom code, but it also requires some knowledge of how OSG actually handles rendering (RenderBins and the like). Basically, you can subclass osg::Group to create a SeparatingPlane Node that calls setBinNumber() on the StateSets of its 2 children. Based on the results of the plane test, the child closer to the eye should get bin number 0 and the farther child should get bin 1 (this gets more complicated if you've got transparent objects in addition to opaque objects, since transparent objects go in different RenderBins). That approach basically gets OSG to do a lot of the work for you, but your option (2) and (3) could work as well. Actually, (3) sound better than (2) because you wouldn't have to duplicate what the osgUtil::CullVisitor does with RenderLeafs, and it feels more natural since you're basically rendering what is a black box from OSG's perspective either way. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CullStack::getViewport() while using an RTT camera
Hi, hopefully this is an easy one! I am subclassing MatrixTransform and overriding the accept(NodeVisitor) method in order to perform some custom auto-scaling. It works fine until I put the node under an RTT camera. Upon doing so, the CullStack::getViewport() method still returns the viewport corresponding to the main camera -- what I'm looking for are the dimensions of the RTT surface. What is the correct call in this case? Thanks in advance. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
HI Michele, I'm not the author of osgFX:Cartoon so am too familiar with the details of the implementation, but I just test a couple of models here with osgfxbrowser and it shoes the the Cartoon effect does support underlying colour, but this doesn't show for all models. It looks to me like the shader ignores OpenGL lighting glMaterial(osg::Material), and the colour problem just comes from glColor (i.e. colour array attached to your osg::Geometry.) Robert. On Dec 17, 2007 10:56 AM, Michele Bosi [EMAIL PROTECTED] wrote: Hello, I am using osgFX::Cartoon node to optionally draw some molecules using cel-shading, the problem is that osgFX::Cartoon makes everything look gray and the color of the objects seems to be lost, is that intentional or am I missing something? All I do is to set the osgFX::Cartoon as the root node of the scene and then all the other nodes are made child of it. Thanks, Michele ___ 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] Problem with osgText
Hi Shoham, The issue you have is that the scene graph has holds internal ID's for all the texture objects and display lists, you've deleted the graphics context undernearth it so these ID are no longer valid, but the scene graph doesn't know that they are invalid so when it dispatches them to OpenGL then just match up to gargbage. OSG 2.x has support for cleaning the scene graph from these now invalid ID's but 1.0 doesn't. So you only recourse is to increment the contextID for the new context. Or.. just upgrade to 2.2 Robert. On Dec 17, 2007 1:59 PM, Shoham Ben-Har [EMAIL PROTECTED] wrote: Hey.. I'm using OSG 1.0 (I know It's little bit old...) I using VS2005 in c# application and using manage c++ layer between the GUI and the OSG window. When I first run my app I draw lines and osgText to the window. and all seems to work fine. Then I close the OSG form (not the application) and after I try to open again with different win32 HWND, I see the lines fine BUT in stand of the numbers I draw in osgText (the ones I saw good at the first run) I see quad polygons !!! please help... ___ 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] Really Big Scenes and clipping
Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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] ANN: Reference Manual for v2.2 now available
HI Bob, On Dec 17, 2007 2:18 PM, Bob Kuehne [EMAIL PROTECTED] wrote: i thought this would be my experience too, after writing it, but i've been surprised. simply seeing all the methods laid out in a logical fashion (rather than how they might be typed into the header), seeing the documentation for a class side-by-side with it's _full_ inheritance hierarchy, and seeing some context (early chapters for osg overview, env var documentation, etc) have actually been interesting. I'm longed pondered on the possibility of a documentation process informing design itself, as its once you see high level constructions which are put together into a coherent form that you really see they beauty and the ugly parts of a design. As project lead/developer I'm not interested in the ugly bits, as these are the bits that need some TLC to put right. From a general user/developer point of the view the beauty is probably more important - it gives you a bit of encouragement and inspiration for your own code, and... allows you to forgive the ugly bits when you come across them :-) This type of perspective its hard to get when stuck in the trenches fixing bugs, tweaking bits of API or adding another feature. I do miss the early days of OSG development when I spent a lot of time pondering the high level structure, and doing major refactoring to meet widening goals or taking advantage of new insights - the alchemy period of the OSG. Alas the OSG got too popular and used by people that my time ended being swamped by low level day to day, its gotta work duties. i've even learned a few things in the process of writing / editing these things. yes, you can teach an old dog new tricks. Kinda nice thing about computing, fifteen-twenty years into your career and you are still learning stuff. I have learnt a huge amount about software over the years, but still feel a bit like the % of things to know that I already know about software is actually diminishing over time... Perhaps one day I learn how to write english in a way that is human readable too... ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CullStack::getViewport() while using an RTT camera
Hi Glenn, I can't really give a straight answer without spending some time on the code, but it does sound like CullStack should be returning the viewport of the nested Camera, and if it isn't there is probably a bug lurking somewhere in CullVisitor::apply(Camera) so I'd recommend having a look at the internals of CullVisitor to see the management of the viewport stack, a little fix is probably all that is required. Robert. On Dec 17, 2007 4:09 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Hi, hopefully this is an easy one! I am subclassing MatrixTransform and overriding the accept(NodeVisitor) method in order to perform some custom auto-scaling. It works fine until I put the node under an RTT camera. Upon doing so, the CullStack::getViewport() method still returns the viewport corresponding to the main camera -- what I'm looking for are the dimensions of the RTT surface. What is the correct call in this case? Thanks in advance. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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] osgFX::Cartoon makes gray
Thank you Robert, that is exactly the problem, it seems from the source code that the shader doesn't support GL_COLOR_MATERIAL enabled, in order to do so I think one should write another shader that reads the current color and not the current material.diffuse component. Also it seems that the effect doesn't show up specular highlights, do you see any specular highlights in your models? Thanks, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
Hi Michele, Cell shading doesn't have specular highlights normally, if you want this you'd need to do it in a custom shader. What you may need to do is subclass from osgFX::Carton to add your own shaders, or just set up the scene graph by hand to do the effect you want. Robert. On Dec 17, 2007 4:41 PM, Michele Bosi [EMAIL PROTECTED] wrote: Thank you Robert, that is exactly the problem, it seems from the source code that the shader doesn't support GL_COLOR_MATERIAL enabled, in order to do so I think one should write another shader that reads the current color and not the current material.diffuse component. Also it seems that the effect doesn't show up specular highlights, do you see any specular highlights in your models? Thanks, Michele ___ 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] osgFX::Cartoon makes gray
Thank you very much Robert, for now I will try to modify the shader in a subclass/cut-and-paste-class of osgFX::Cartoon so that it can handle color-material and cartoon-like speculars, if I manage to have something working I will post it back here (crossing fingers). Regards, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX::Cartoon makes gray
Hello Michele, Cell shading doesn't have specular highlights normally, Actually, since the color for cel shading is determined according to the angle to the light, you can do a fake specular highlight by just playing with your color ramp (the 1D texture). For example, it could go from black to dark green to light green smoothly, and then in the last few pixels, go up to white very sharply. That way, there will be a white highlight where the surface is angled towards the light source. Of course, Robert is right that without modifying the shader, it's not real specular highlighting, since it's viewpoint independent (like diffuse lighting). But in your case, it might be sufficient. Lots of different effects can be achieved by just playing with the color ramp and looking at what the results are. See for example screenshots of Valve's Team Fortress 2 (and if you enable the commentary mode in the game, there is one point where they actually explain what they did with their shaders to get the look they ended up with - not in programming terms, but still very interesting). Good luck, J-S P.S. Sorry to correct you Robert... Yes it's cel, which is the old contraction of celluloid - the transparent plastic sheets used to draw traditional cartoons on, see http://en.wikipedia.org/wiki/Cel_shading . Though in your case cell might apply too (sorry for the really bad pun) :-) -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CullStack::getViewport() while using an RTT camera
Robert, I think I found the problem. I am using version 1.2 (which I forgot to mention, again), and CullVisitor does not push and pop the viewport on the CullStack. Looks like this has already been resolved in revision 6224. Thanks again -gw On Dec 17, 2007 11:39 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, I can't really give a straight answer without spending some time on the code, but it does sound like CullStack should be returning the viewport of the nested Camera, and if it isn't there is probably a bug lurking somewhere in CullVisitor::apply(Camera) so I'd recommend having a look at the internals of CullVisitor to see the management of the viewport stack, a little fix is probably all that is required. Robert. On Dec 17, 2007 4:09 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Hi, hopefully this is an easy one! I am subclassing MatrixTransform and overriding the accept(NodeVisitor) method in order to perform some custom auto-scaling. It works fine until I put the node under an RTT camera. Upon doing so, the CullStack::getViewport() method still returns the viewport corresponding to the main camera -- what I'm looking for are the dimensions of the RTT surface. What is the correct call in this case? Thanks in advance. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lucas Goss wrote: Hmm, that might be alright, though I don't really like writing shell scripts, haha. Of course if that is an advantage for some they can still do it that way, they don't have to use OSG's implementation. But it would be nice to have an implementation still, as OSG provides an interface for it and those that want a quick way of resolution changing without messing with shell scripts can get it there. The reason for SDL's craziness and why I have suggested a shell script is easy - you can make a some kind of X hack that works on your computer using one extension, but I compile the program on my computer and it is very likely that either the resolution is not available, the extension is not available/working with my X and driver or some other weird problem happens. In that case relying on external (and supposedly working) tools can save your bacon. I wouldn't like to have to implement resolution switching logic for X having to juggle X11 calls to the older extensions, newer RandR stuff (that is incompatible with them) and most recently the various OpenGL compositing managers like Compiz, where the situation is yet different (you could be running on a nested X server and your application calls are actually proxied). Are you ready to handle all of this? Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHZsw2n11XseNj94gRAlE6AJ9GPz2UCa2Gf2ha2OALHCtj+RlLnACgiZNc 06tH32ylbosbDgEjuFsvwOw= =nZvm -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Jan, On Dec 17, 2007 7:21 PM, Jan Ciger [EMAIL PROTECTED] wrote: The reason for SDL's craziness and why I have suggested a shell script is easy - you can make a some kind of X hack that works on your computer using one extension, but I compile the program on my computer and it is very likely that either the resolution is not available, the extension is not available/working with my X and driver or some other weird problem happens. In that case relying on external (and supposedly working) tools can save your bacon. I wouldn't like to have to implement resolution switching logic for X having to juggle X11 calls to the older extensions, newer RandR stuff (that is incompatible with them) and most recently the various OpenGL compositing managers like Compiz, where the situation is yet different (you could be running on a nested X server and your application calls are actually proxied). Are you ready to handle all of this? I wonder about a compromise... call an external application to do the change of resolution for us from within osgViewer just by issuing a system call. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...
Hi all, would someone please inform me as to where I may find the OSG2.2 dsw project file for MS VS 2005 (C++ ver 8.x)? I can not find it in the binaries or the source .zips / .exes for Windows. I can not seem to run any example because the ones I'm running are attempting to use the osgDB::readNodeFile(s) and it crashes every time on this call. The only thing I can think of is that I MUST compile OSG on my platform (XP w/ SP2, MS VS 2005) and hope this cures my run-time problem using the osgDB::readNodeFile(s) commands. Thanks every one. I really appreciate the help. -- Sincerely, Allen Senior Software Engineer EDO-CAS, Inc Ps 34:5 I sought the Lord, and he heard me; and he delivered me from all my fears ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...
Hi Allen, From OSG 1.9.x onwards the OSG hasn't included VS project files, instead it now used CMake to generate the platform specific (and VS version specific) project/makefile for you. CMake also automatically detects dependencies and sets everything up for you so that it only builds plugins etc that you have dependencies for. For more details see: http://www.openscenegraph.org/projects/osg/wiki/Build/CMake As for the problem with loading plugins.. I not a windows user myself, perhaps others on list will be able to pinpoint the problem. There is possibility that its related to a problem with manifests in the binary distribution. Robert. On Dec 17, 2007 8:10 PM, Allen [EMAIL PROTECTED] wrote: Hi all, would someone please inform me as to where I may find the OSG2.2 dsw project file for MS VS 2005 (C++ ver 8.x)? I can not find it in the binaries or the source .zips / .exes for Windows. I can not seem to run any example because the ones I'm running are attempting to use the osgDB::readNodeFile(s) and it crashes every time on this call. The only thing I can think of is that I MUST compile OSG on my platform (XP w/ SP2, MS VS 2005) and hope this cures my run-time problem using the osgDB::readNodeFile(s) commands. Thanks every one. I really appreciate the help. -- Sincerely, Allen Senior Software Engineer EDO-CAS, Inc Ps 34:5 I sought the Lord, and he heard me; and he delivered me from all my fears ___ 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] Looking towards 2.4, and what might go into it.
Hi Jan, On Dec 17, 2007 8:21 PM, Jan Ciger [EMAIL PROTECTED] wrote: That would be quite a hackery, IMO. Are you going to handle all the issues with path, detection whether certain binaries are available or not and potentially which versions they are in the application code? An external script that invokes the 3D app only works when entering an application, not once its running, so it does have a bit of limited applicability. That is far easier and safer to do at the operating system level and it also leaves the door open for the potential packager to adapt the script to the conventions used by the particular distro. If it is part of the binary, one cannot do this unless the application is shipped with source. That could be an issue for commercial software vendors using OSG. You can always make the app called and the path application/user definable with a sensible default for each platform one doesn't need to hard wire it - if a platform doesn't have anything sensible then you'd just have a blank app string and would therefore not call the res changing app. BTW, I'm just trying to explore possible solutions here. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...
would someone please inform me as to where I may find the OSG2.2 dsw project file for MS VS 2005 (C++ ver 8.x)? I can not find it in the binaries or the source .zips / .exes for Windows. You need to generate the VS project files using CMake. Try searching for Cmake at openscenegraph.org for more info. I can not seem to run any example because the ones I'm running are attempting to use the osgDB::readNodeFile(s) and it crashes every time on this call. The only thing I can think of is that I MUST compile OSG on my platform (XP w/ SP2, MS VS 2005) and hope this cures my run-time problem using the osgDB::readNodeFile(s) commands. Sounds like osgDB is having problem finding the plugins. Others have reported similar problems with the Windows binaries. Maybe if Mike Weiblen is reading this, he can post a status update? I don't recall that anyone has arrived at a bullet-proof solution for this problem. IIRC, as a workaround, you can take the contents of your plugin directory and move it up one level to the bin directory. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.3.0 dev release tagged.
Hi All, After a weeks delay I've finally got on top of submissions, and able to tag the 2.3.0 dev release. Details can be found at: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases My entry on this page is: * OpenSceneGraph-2.3.0, released on 17th December 2007. Changes include : Bug and typo fixes, new double and external data support in Vec*Array classes, new double and Dbase .dbx support in ShapeFile plugin, new .cfg Producer config file loader, 64 bit OSG Archive support under Windows, support for continuation records in OpenFlight plugin, improvements to COLLADA plugin, new osgText::Text3D class for 3D geometry text, enhancements to PolytopeIntersector and addition of live video support in Quicktime plugin. source package : OpenSceneGraph-2.3.0.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.0 OpenSceneGraph The OpenSceneGraph-2.3.0.zip link is currently broken though, so it looks like the script on the server for building release is down. Luigi?? Can you help us? :-) Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] implementing a bsp tree
Micah Heyer wrote on Monday, December 17, 2007 12:54 PM: Hi, thanks for you reply.I'm afraid my knowledge of osg internals is quite limited but I will look into it and see if I can understand renderbins and what ever else. I'm currently trying to implement the my second method.I looked at the source for CullVisitor I was wondering is there any reason to subclass my BSPTreeNode from osg::Group instead of osg::Node?Node already has a virtual traverse method and doesn't implement any sort of list to store its children in, so I wouldn't have redundant references to all the children. You can use osg::Node just fine if you don't need the children functionality that Group adds. The tricky part with using Group or Node is that you can't just make OpenGL calls; the CullVisitor is not necessarily operating in a valid OpenGL context. The CullVisitor arranges RenderBins and attaches RenderLeafs to them so that the draw pass (which does have an OpenGL context) does all the rendering. Each RenderLeaf has one of the Drawables from the scenegraph and calls draw() on the Drawable when it is time to render (after setting up the appropriate OpenGL state). I hope I'm not scaring you too much. It can be done, but there's a lot of complexity in there that you need to understand to make things work right. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ 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] Really Big Scenes and clipping
Richard S. Wright Jr. wrote on Monday, December 17, 2007 5:22 PM: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) To have the skydome always rendered last, give it a StateSet and call setRenderBinMode(USE_RENDERBIN_DETAILS) and setRenderBinNumber(3). Most stuff uses RenderBin 0, (or 1 and 2 if there's transparent stuff), so this should force it to be last (you can certainly set a higher number if needed). Nested cameras and anywhere else you don't use the default StateSet RenderBinMode will complicate things, though (RenderBins can nest, and the numbers are relative order within the current RenderBin). HTH! On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Richard On Dec 17, 2007, at 6:41 PM, Thrall, Bryan wrote: Richard S. Wright Jr. wrote on Monday, December 17, 2007 5:22 PM: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) To have the skydome always rendered last, give it a StateSet and call setRenderBinMode(USE_RENDERBIN_DETAILS) and setRenderBinNumber(3). Most stuff uses RenderBin 0, (or 1 and 2 if there's transparent stuff), so this should force it to be last (you can certainly set a higher number if needed). Nested cameras and anywhere else you don't use the default StateSet RenderBinMode will complicate things, though (RenderBins can nest, and the numbers are relative order within the current RenderBin). HTH! On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ 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] Really Big Scenes and clipping
Doh!! Thanks! Richard On Dec 17, 2007, at 8:46 PM, Jason Daly wrote: Richard S. Wright Jr. wrote: Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Negative numbers also work for render bins. You can use -10, for example, to get it drawn first. --J ___ 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] Really Big Scenes and clipping
Richard S. Wright Jr. wrote: Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Negative numbers also work for render bins. You can use -10, for example, to get it drawn first. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Hello Richard, Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Why do you want to render it first, and then have it be overwritten by your objects, which might (worst case) result in having drawn the whole screen twice for nothing? Render it last, but only setting pixels at the far plane. That way, pixels that contain other objects will not be overwritten by your skydome. For example, this is from the skybox code in my current project, but I can't take credit as most of it was lifted from a post to this very mailing list. Unfortunately, it's from the old list server and I can't seem to find the message in the current archives. The old link was: http://openscenegraph.org/archiver/osg-users/2005-June/0581.html osg::StateSet* stateset = new osg::StateSet; // Set texture mode to REPLACE osg::TexEnv* te = new osg::TexEnv; te-setMode(osg::TexEnv::REPLACE); stateset-setTextureAttributeAndModes(0, te, osg::StateAttribute::ON); // Turn off lighting and cull face stateset-setMode(GL_LIGHTING, osg::StateAttribute::OFF); stateset-setMode(GL_CULL_FACE, osg::StateAttribute::OFF); // Basic principle of skyboxes: render it last, and with a depth func // that only sets pixels at the far plane. That way, if the sky is not // visible at all for example, the sky won't be drawn (and possibly // fragment shaders will not be called) whereas rendering it first will // cause all pixels to be written, then overwritten by objects, and // possibly fragment shaders will have been called for nothing. // Clear the depth to the far plane. osg::Depth* depth = new osg::Depth(osg::Depth::LEQUAL, 1.0, 1.0); stateset-setAttributeAndModes(depth, osg::StateAttribute::ON); // Make pretty darn sure it is drawn last. stateset-setRenderBinDetails(1000, RenderBin); // Create a drawable for the skybox. osg::Geometry* drawable = new osg::Geometry; // Create vertices for box // [...] // Create texture coordinates for cubemaps // [...] // Create an index array for the box // [...] // Create a geode for the skybox osg::Geode* geode = new osg::Geode; geode-setName(Skybox); // Disable culling geode-setCullingActive(false); // Set the stateset geode-setStateSet(stateset); // Add the skybox geode-addDrawable(drawable); // Next is setting the texture and the transform node... // [...] -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Traversing
Hi, everyone.
I have a class called Point that is derived from MatrixTransform. An
instance of this class always has a Geode child, which has a Drawable, which
is a ShapeDrawable. For better understanding of things, I'll use a simple
shape for a drawable, let's say a sphere.
Let's suppose I have an instance of my Point class, which is attached
to the viewer, being displayed on the screen
I use a PickHandler class that is as follows:
bool PickHandler::handle(const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa)
{
osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*( aa );
osgUtil::LineSegmentIntersector::Intersections intersections;
if(!viewer)
{ return false; }
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::PUSH):
{
if(Intersecao(viewer, ea))
{ ... } // I'LL TALK ABOUT THESE BRACKETS FURTHER AHEAD
}
}
}
bool PickHandler::Intersecao(osgViewer::Viewer* viewer, const
osgGA::GUIEventAdapter ea,
osg::Util::LineSegmentIntersector::Intersections intersections)
{
return (viewer-computeIntersections(ea.getX(),ea.getY
(),intersections));
}
So, I guess my question is: what do I write inside those brackets
that I marked above to traverse till the drawable and change its color? What
I really need here is some language learning, not only theoretical, OK? In
other words: if you could write a little bit of source code to clarify what
you are saying, that'd be great.
Thanks, everyone. If you manage to explain
how it's done to the newbie you're talking to, I'd be grateful.
Renan M Z Mendes
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] realizeImplementation error with GraphicsWindowEmbedded
I'm using osgviewerQT as my windowing system, so the graphicswindow it uses
is GraphicsWindowEmbedded.
But when it comes to realizeImplementation() function of PixelBufferWin32
class, I got the following runtime error:
Run-Time Check Failure #3 - The variable 'hglrc' is being used without being
defined.
I traced the stack, and found in bool
PixelBufferWin32::realizeImplementation()
if (_traits-sharedContext)
{
HGLRC hglrc;
GraphicsWindowWin32* graphicsWindowWin32 =
dynamic_castGraphicsWindowWin32*(_traits-sharedContext);
if (graphicsWindowWin32)
{
hglrc = graphicsWindowWin32-getWGLContext();
}
else
{
PixelBufferWin32* pixelBufferWin32 =
dynamic_castPixelBufferWin32*(_traits-sharedContext);
if (pixelBufferWin32)
{
hglrc = pixelBufferWin32-getWGLContext();
}
}
wglShareLists(hglrc, _hglrc);
}
Since my graphicswindow is GraphicsWindowEmbedded, then the two dynamic_cast
will all return NULL.
And then the hglrc will be uninitialized when wglShareLists is invoked. That
causes the error. However, I've no idea how to fix this runtime error.
BTW, This error doesn't happen when I first setup my scene and view it, but
when I modified the scene and changed one of its node.
Any help will be great appreciated, thanks a lot.
Sincerely yours,
Shuxing Xiao
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
