Re: [osg-users] [ANN] OpenSceneGraph 3 Cookbook Published!
Hi Rui, On 1 April 2012 07:40, Wang Rui wangra...@gmail.com wrote: I'm glad to announce the publication of the book OpenSceneGraph 3.0 Cookbook, which is yet another OSG book written by me, with the help of Dr. Qian Xuelei. Thanks to my technique reviewers: Torben Dannhauer, Vincent Bourdier, and Chris Hanson. Congratulations on the new book ;-) I'll post a link to it on openscenegraph.org... once we get it back online! Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New FrontFace Modes
Hi Felix, I'm a bit perplexed by what exactly you are proposing. StateAttribute are designed to just pass data to OpenGL, they typically aren't active objects that on the fly decide what state they are in. Also osg::State object just tracks and applies what state is required, hardwiring to specific state only happens for very special StateAttribute like osg::Program and this has to be done to properly mange osg::Uniform. Also RenderStage is loosely coupled with State that is applied. This loose coupling is deliberately designed into the OSG to allow it to be extensible and easily to extend. What you suggests sounds like it breaks quite a few of these design aspects. I'm also not clear on why you really need to go to such lengths. There may well be far easier ways to handle what you are doing. Robert. On 2 April 2012 00:01, Felix Nawothnig felix.nawoth...@googlemail.com wrote: Hey. A while ago we added a few new FrontFace modes to deal with multi-instanced mirrored geometry showing up in our data: - AUTO, which sets the front face to GL_CW when the MVM has negative determinant (mirror transformation)., GL_CCW otherwise. - AUTO_FLIPPED, doing the inverse - FLIP, which inverts the previous setting in apply() (The latter we don't actually use, I just added it for completeness - could be useful if the mirroring is done by a uniform instead of the MVM) This obviously required some changes to RenderLeaf, State and FrontFace. If this feature is considered useful I'll clean up the code and send a patch. Felix ___ 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] Website, Version control and Server migration
Hi All, Occasionally over the past 6 months we've discussed moving server and services from the present server, but as yet nothing concrete has happened. I'm now ready to knuckle down and make it happen. However, there is still decisions to make and work to do. This I need both your suggestions, feedback on how well certain server technologies work for you, and time in migrating content across once we've got the new website and services setup. One the version control front my plan is to migrate from subversion to git, and myself taking ownership of the openscenegraph over on github would probably be easiest to do in terms of work from myself and community. Given we have plenty of other work to handle in server migration having one of the tasks happen smoothly is good, and is something we should be able to do rapidly. I tagged openscenegraph-3.1.2 dev release last Friday, so this could well be the last activity I need to make in Subversion! While migrating across to use github's openscenegraph is easy, there are other projects that our current server provides - VirtualPlanetBuilder is the main one, this I will probably need to manage the migration of, and my intention is to sit it alongside openscenegraph in github. There are also other smaller Tracs/subversion projects hosted like as part of osgforge.org : osglua, osgpython, osgdotnet, osgtutorial and osgProducer. There is very little activity or any discussion about these that I'm aware of - so my assumption that these are largely inactive/dormant. To keep life simple I'd like those who are responsible for these projects, or would like to assume responsibility for them to step forward and tell us what you'd like to with them. Please come forward now if you want to take on these, otherwise assume that these little ancillary projects will disappear. For mailing lists and forum we currently don't use the present server so these services need no changes. All we need to do is keep links to these on the new server/website when it goes live. Now we get to the big task before us - new server and web technologies for the new website and services. I would like to be able to provide a professional looking website with the main elements easily accessible for end users and for easy for the website maintainers to provide content for and manage. I would also like a section of the website to remain a wiki/enable community provided content. A wik/user content opens the door to spammers using the website for their own nefarious deeds so we'll need a robust user account system and system for monitoring commits from the community by review my wiki administrators so we can catch the spammers before they do too much damage. I'd like the user account system to be easier to manage than the present one - needing the server admin to grant permissions adds extra work for everyone. In terms of server I have a Dreamhost account that includes full hosting so moving the OSG website to dreamhost is fine by me - currently I use Dreamhost's Mailman support to provide the osg-users mailing list and the blog.openscenegraph.org is hosted by Dreamhost. Dreamhost allows use to install various web technologies for our hosted websites, technologies like MediaWiki, WordPress, Joomla and Tracs amoung others. I'm open to suggestion on what technology to go for, so please step forward now with feedback on various CMS techologies you've used and what think would work well for the OSG. I'm also no web/server amin person, I'm user of these systems rather than admin so I'm having to learn about them, and right now feel rather overwhelmed by all the options and terminology so feel free to provide links to good resources about learning about these. Also if you've seen other software project websites that you feel work really well and would be worth learning from please come forward with links and tell us what parts work well or work less well. Once we've got a short listed set of technologies I'll get these set up/work with other to get them set up and then we can start experimenting with website mock ups to test things. I can set up an openscenegraph.org subdomain for this purpose or just reuse the openscenegraph.com for this while we are experimenting. Once we've decided upon the tech we can then progress onto migrating the existing openscenegraph.org content across. The layout and style of the website will be partly determined by what is possible with the tech we choose, but we'll still have a pretty open hand to do what we want. The current website looks OK, but it's not great, I think we can do better, but not being a graphics artist type I'm not one to really push forward a great new look and layout. Here, again I welcome suggestions and direct help in refining things. When populating the new website we may be able to migrate quick a bit of content but also I think it's time for us to write some new content - many of even the main pages haven't been updated for years.
[osg-users] Shadows and LOD
Hi, FlightGear now includes a deferred renderer that produce shadows. As the lighting is done from a Gbuffer in a fullscreen quad render, I can't (correct me if I'm wrong) use osgShadow. So in my implementation, I render the geometry of the whole scenegraph to a depth texture using an orthographic projection in the direction of the light. The view matrix sets the sun position at 1m from a position ahead of the viewer. But when the viewer is near an object that has a LOD node that has a range of 0 - 9000m, the model is not renderer in the shadow map and the viewer doesn't see a shadow. So the question : is there special code in osgShadow that address this kind of situation : a LOD range for the viewer unsuitable for the light source ? I tried to override the LOD::traverse method in a specific cull visitor that calls Group::traverse instead, but I was said it is a bad thing, and I can understand it breaks PagedLOD and any descendant too. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Website, Version control and Server migration
On 02.04.2012 13:45, Robert Osfield wrote: Hi All, [...] In terms of server I have a Dreamhost account that includes full hosting so moving the OSG website to dreamhost is fine by me - currently I use Dreamhost's Mailman support to provide the osg-users mailing list and the blog.openscenegraph.org is hosted by Dreamhost. Dreamhost allows use to install various web technologies for our hosted websites, technologies like MediaWiki, WordPress, Joomla and Tracs amoung others. I'm open to suggestion on what technology to go for, so please step forward now with feedback on various CMS techologies you've used and what think would work well for the OSG. Don't use Redmine stick to Trac, the biggest reason for this is administration remains easy with trac-admin. You can easily backup, migrate and configure each project while multiple projects are still possible with minimal effort. Compared Redmine with Trac, Redmine's backup and configuration is a nightmare as you have to dump mysql databases manually, backup uploaded files separately, etc. More over, you are not able to migrate single projects. Some Redmine settings apply to all projects, the wiki does not allow custom image resolutions for embedded images due to a XSS related bug. Some configuration is done in-source e.g. custom routes, so software updates will overwrite your settings then. I say this as we are currently using Redmine for our project (openwalnut.org also using OSG) and I am very unhappy with it. BTW, we also encounter problems with spammers (buybacklinkz.com etc) even recaptcha plugins for Redmine won't protect you and you have to use manual account activation as a last resort. please ignore clumsy english as I am in (a?) hurry Mathias -- Institut für Informatik Universität Leipzig Johannisgasse 26, 04103 Leipzig Phone: +493419732283 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
Hi osg::Camera have methods to tweak lod scale (setLODScale(float val), check osg::CullSettings class reference), so you can tweak your shadow camera Cheers, Sergey. 02.04.2012, 16:12, Frederic Bouvier fredlis...@free.fr: Hi, FlightGear now includes a deferred renderer that produce shadows. As the lighting is done from a Gbuffer in a fullscreen quad render, I can't (correct me if I'm wrong) use osgShadow. So in my implementation, I render the geometry of the whole scenegraph to a depth texture using an orthographic projection in the direction of the light. The view matrix sets the sun position at 1m from a position ahead of the viewer. But when the viewer is near an object that has a LOD node that has a range of 0 - 9000m, the model is not renderer in the shadow map and the viewer doesn't see a shadow. So the question : is there special code in osgShadow that address this kind of situation : a LOD range for the viewer unsuitable for the light source ? I tried to override the LOD::traverse method in a specific cull visitor that calls Group::traverse instead, but I was said it is a bad thing, and I can understand it breaks PagedLOD and any descendant too. Regards, -Fred ___ 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] Shadows and LOD
Hi Fred, The osg::Camera has support for setting the reference frame so that it inherits the viewpoint for LOD calculation so that you get the same LOD's for your render to texture pass as you would for your main view. In osgShadow you'll this used and set up thus: _camera-setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); This doesn't require any other changes so no need to try Sergey's suggestion of LODScale() which would achieve rather different results. Robert. On 2 April 2012 13:12, Frederic Bouvier fredlis...@free.fr wrote: Hi, FlightGear now includes a deferred renderer that produce shadows. As the lighting is done from a Gbuffer in a fullscreen quad render, I can't (correct me if I'm wrong) use osgShadow. So in my implementation, I render the geometry of the whole scenegraph to a depth texture using an orthographic projection in the direction of the light. The view matrix sets the sun position at 1m from a position ahead of the viewer. But when the viewer is near an object that has a LOD node that has a range of 0 - 9000m, the model is not renderer in the shadow map and the viewer doesn't see a shadow. So the question : is there special code in osgShadow that address this kind of situation : a LOD range for the viewer unsuitable for the light source ? I tried to override the LOD::traverse method in a specific cull visitor that calls Group::traverse instead, but I was said it is a bad thing, and I can understand it breaks PagedLOD and any descendant too. Regards, -Fred ___ 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] Shadows and LOD
Thank you Robert, may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? Regards, -Fred De: Robert Osfield Hi Fred, The osg::Camera has support for setting the reference frame so that it inherits the viewpoint for LOD calculation so that you get the same LOD's for your render to texture pass as you would for your main view. In osgShadow you'll this used and set up thus: _camera-setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); This doesn't require any other changes so no need to try Sergey's suggestion of LODScale() which would achieve rather different results. Robert. On 2 April 2012 13:12, Frederic Bouvier wrote: Hi, FlightGear now includes a deferred renderer that produce shadows. As the lighting is done from a Gbuffer in a fullscreen quad render, I can't (correct me if I'm wrong) use osgShadow. So in my implementation, I render the geometry of the whole scenegraph to a depth texture using an orthographic projection in the direction of the light. The view matrix sets the sun position at 1m from a position ahead of the viewer. But when the viewer is near an object that has a LOD node that has a range of 0 - 9000m, the model is not renderer in the shadow map and the viewer doesn't see a shadow. So the question : is there special code in osgShadow that address this kind of situation : a LOD range for the viewer unsuitable for the light source ? I tried to override the LOD::traverse method in a specific cull visitor that calls Group::traverse instead, but I was said it is a bad thing, and I can understand it breaks PagedLOD and any descendant too. Regards, -Fred ___ 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] Shadows and LOD
Hi, On Monday 02 April 2012, Frederic Bouvier wrote: may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? Cameras should inherit from their parent cameras which should still be our master camera or a basically aequivalent slave for a different view, even for your code. True? So I assume this also holds for the above detail. 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 -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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
Re: [osg-users] Shadows and LOD
On 2 April 2012 14:21, Frederic Bouvier fredlis...@free.fr wrote: may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? The OSG inherits state/settings from parents, there isn't any sibling inheritance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
On 2 April 2012 14:21, Frederic Bouvier fredlis...@free.fr wrote: may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? The OSG inherits state/settings from parents, there isn't any sibling inheritance. Ok, thank you. I was a bit clueless until now about the use of the ABSOLUTE_RF_INHERIT_VIEWPOINT purpose. Maybe it's explained in Wang Rui's book. I will dive in the OSG source with that in mind Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Website, Version control and Server migration
Hi All, I am currently looking at Joomla, while I read up about it, has anyone else out there worked with Joomla? Thoughts? If Joomla doesn't look to daunting I'll try Dreamhosts One Click install and put up something basic on openscenegraph.com and see how I get on. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Website, Version control and Server migration
And the next step in my experimentation/learning experience - I've got Joomla installed on: http://www.openscenegraph.com/ No OpenSceneGraph specific content yet kinda run of working day to get much more done right now. I'll see if I can get a banner up before I disappear for the evening. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Website, Version control and Server migration
Hi All, As a test of Dreamhost server/services I have put up MediaWiki site for us to experiment with: http://wiki.openscenegraph.com I haven't ever worked with MediaWiki before let alone set one up so it's all rather a new experience. If I've done something dumb, or neglected to set things up right just let me know. At this stage I think it would be appropriate for us to experiment with creating user accounts and then looking just creating a few pages, uploading images, videos with the purpose of testing rather than building a new community section of the website. Let me know how you get on. I'd also like to know from users who would be happy to help manage/administer/work as editors/reviewers for any final wiki we plump for. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Website, Version control and Server migration
On 04/02/2012 10:57 AM, Robert Osfield wrote: Hi All, I am currently looking at Joomla, while I read up about it, has anyone else out there worked with Joomla? Thoughts? Hi, Robert, We use Joomla for pretty much all of our web presence here in our lab, as well as for some additional work we do with the UCF programming team. The basic web stuff is pretty straightforward in Joomla. We've also written some Joomla extensions to support the programming team work (we run programming contests completely within the Joomla environment). One thing we've not really done is host a software repository as part of the site itself, but I don't think that would be difficult. Feel free to take a look at our sites if you like: http://www.irl.ucf.edu http://www.ucfprogrammingteam.org You might also want to check out joomlashack.com for templates and extensions. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New FrontFace Modes
2012/4/2 Robert Osfield robert.osfi...@gmail.com: I'm a bit perplexed by what exactly you are proposing. StateAttribute are designed to just pass data to OpenGL, they typically aren't active objects that on the fly decide what state they are in. Also osg::State object just tracks and applies what state is required, hardwiring to specific state only happens for very special StateAttribute like osg::Program and this has to be done to properly mange osg::Uniform. Also RenderStage is loosely coupled with State that is applied. This loose coupling is deliberately designed into the OSG to allow it to be extensible and easily to extend. What you suggests sounds like it breaks quite a few of these design aspects. Well, I agree with you on that one. I wasn't particularly happy with my solution either. But I definitely need the functionality it provides and I think it can be argued that such functionality is useful in general. I'm also not clear on why you really need to go to such lengths. There may well be far easier ways to handle what you are doing. ... and I would very much prefer a solution which wasn't that intrusive. So - my actual problem: I have (rather deep) multi-parent (for memory reasons - really can't change that) sub-graphs which contains lots of Geodes with GL_CULL_FACE enabled (performance reasons - don't want to change that). When the geodes are culled some of the parental paths yield a MVM with a positive determinant (no mirroring) and some of the parental paths yield a MVM with a negative determinant (mirroring along a single axis), the latter causing the front/back faced to be switched. No matter what FrontFace / CullFace is set in the graph - it's not possible to get both sets of subgraphs to be rendered, unless you somehow allow the attribute's value to depend on the MVM calculated by this specific NodePath. So because it's not possible to do this with attributes alone I added a feature which basically says I don't want to manage the front face attribute manually, just automatically apply whatever value the current MVM requires. This is why I need something like my proposed AUTO. Why I think FLIP is quite useful: You seldom want a specific front face setting or a specific cull face setting - usually you just want it to be the the inverse of what it currently is (because front face, cull face and a negative determinant in the MVM each cancel each other out). Also one might not use the cull traversals real MVM (instead using some uniforms to the same effect), in which case my AUTO would not work. Another area where I am using these settings is the StateSet of Cameras used for planar reflections (which also bring a negative determinant to the MVM). And then there is a point to be made about it being not very nice that the whole scene has to use a consistent back/front setting here when all every node cares about is inverting the setting... Don't get me wrong though - I'm not saying that this must or should be done by adding another FrontFace (or CullFace) mode... this was just the easiest way I saw. Cheers, Felix ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] (no subject)
a href=http://hlisted.com/wp-content/themes/typebased/cache/02efpk.html; http://hlisted.com/wp-content/themes/typebased/cache/02efpk.html/a___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text Class Sizing Issue!
robertosfield wrote: Hi David, On 29 March 2012 17:34, David Glenn wrote: Well, since it not a submission per say. Here is the sample source code that John wanted me to so you all. The program doesn't compile for me, I presume because it has been updated to compile against recent OSG versions. Might I suggest that one tries a recent version of the OSG to see if that problem still exists. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Hi Robert! Right now we are stuck in OSG 2.8.1 because in the long development cycle we have here at or lab! We will move to the newest stable release after the end of this development cycle, or if it fills a requirement that we need bad enough to upgrade. So far, nether event has happened. I Know that John did visualy compare the code and he told me that it does address an issue that is current in the present OSG 3.0.1 as we know it, and that the exampe code should be compatable in most cases. However, becouse we are not current on or own development systems at this time, one of us will have to set up on another box for testing the code under the current stable OSG version. I can do this when we can devote the time and resorces to do so in the future. Oh! For what its worth, we test things using QT develoment GUI. It makes it much faster to build quick makefiles though I dont recall any QT stuff being used in this example. Also, we did not try this under Windows OS, I'm not sure of the behaver there! In fact, I'm not doing any Windows OS development with OSG at the moment! David Glenn --- D Glenn 3D Computer Graphics amp; Media Systems. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46747#46747 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
Hi Robert, On 2 April 2012 14:21, Frederic Bouvier fredlis...@free.fr wrote: may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? The OSG inherits state/settings from parents, there isn't any sibling inheritance. One more thing: it happens that I implement cascaded shadow map with a single shadow map and 4 cascades. My scenegraph is like this : master camera = slave shadow camera (hold an fbo on a S x S depth texture) = cascade1 : child camera, viewport (S/2 x S/2 @ 0, 0) = cascade2 : child camera, viewport (S/2 x S/2 @ 0, S/2) = cascade3 : child camera, viewport (S/2 x S/2 @ S/2, 0) = cascade4 : child camera, viewport (S/2 x S/2 @ S/2, S/2) I want to know if the inherited viewpoint is propagated to the cascade camera if I set the reference frame of the main shadow camera and the 4 cascades to ABSOLUTE_RF_INHERIT_VIEWPOINT Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problem with svn (atomic counter?)
Hello all,
I have been just doing some testing of OSG (latest from the SVN).
Whilst executing osggeomertyshaders I am getting a crash:
CALL STACK:
msvcp90d.dll!std::_Debug_message(const wchar_t *
message=0x07fee9bb9b68, const wchar_t * file=0x07fee9bb9bb0,
unsigned int line=779) Line 24 C++
osg92-osgd.dll!std::vectorint,std::allocatorint
::operator[](unsigned __int64 _Pos=0) Line 780C++
osg92-osgd.dll!osg::Program::PerContextProgram::linkProgram(osg::State
state={...}) Line 784 + 0xf bytes C++
osg92-osgd.dll!osg::Program::compileGLObjects(osg::State
state={...}) Line 233 C++
osg92-osgd.dll!osg::StateSet::compileGLObjects(osg::State
state={...}) Line 1335 C++
osg92-osgUtild.dll!osgUtil::GLObjectsVisitor::apply(osg::StateSet
stateset={...}) Line 114 C++
LOCALS:
+ end (3452816845,Bad Ptr)
std::_Treestd::_Tmap_traitsunsigned
int,std::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessunsigned int,std::allocatorstd::pairunsigned int const
,std::basic_stringchar,std::char_traitschar,std::allocatorchar ,0
::iterator
+ it (3452816845,Bad Ptr)
std::_Treestd::_Tmap_traitsunsigned
int,std::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessunsigned int,std::allocatorstd::pairunsigned int const
,std::basic_stringchar,std::char_traitschar,std::allocatorchar ,0
::iterator
bufferIndex [0]() std::vectorint,std::allocatorint
bufferIndexToUniformIndices [14757395258967641292]()
std::mapint,std::vectorint,std::allocatorint
,std::lessint,std::allocatorstd::pairint const
,std::vectorint,std::allocatorint
activeAtomicCounterBuffers 3435973836 unsigned int
uniformIndex[0]() std::vectorunsigned
int,std::allocatorunsigned int
+ this0x02838be0 {_program=0x027f8540
_extensions={...} _glProgramHandle=4 ...}
osg::Program::PerContextProgram * const
Sorry for the garbage! I am using Windows VS 2008 as my compliler :)
Unfortunately I have updated my Nvidia drivers to the latest a few days ago
so I am unsure if it's a driver or the later openGL4.2 stuff that has been
introduced in OSG just recently having review the logs of program.cpp ?
Regards
Martin Naylor
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow PSSM light source issue
I noticed this problem as well. To fix this I modified PSSM to use the same code as the selectLight() method in StandardShadowMap. However osgShadow's PSSM implementation has a lot of other quirks as well... On 3/23/2012 5:47 AM, Daniel Schmid wrote: I have an issue with PSSM. The light source in my scene is not taken into account properly (sun). It calculates shadows like if sun as in perfect orbit. All other shadow implementations work correctly, and changes in light position are calculated correctly, but PSSM is stuck somehow. Does anybody know this problem ? Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] OpenSceneGraph 3 Cookbook Published!
Wang, Just wanted to let you know that I had pre-ordered the cookbook through Amazon, and got it on the day it published - very nicely done. It's already proved useful in couple of cases. Thanks! Brandon From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wang Rui Sent: Sunday, April 01, 2012 1:40 AM To: OpenSceneGraph Users Subject: [osg-users] [ANN] OpenSceneGraph 3 Cookbook Published! Hi all, First of all, this is NOT a joke on April Fool's Day. :-) I'm glad to announce the publication of the book OpenSceneGraph 3.0 Cookbook, which is yet another OSG book written by me, with the help of Dr. Qian Xuelei. Thanks to my technique reviewers: Torben Dannhauer, Vincent Bourdier, and Chris Hanson. Also many thanks to Robert Osfield and the whole OSG community! Exactly 100 recipes are introduced in this book (some may not appear in any of the pages because of the page count limitation, please refer to the source code repo). You should be familiar with the basic concepts of the OpenSceneGraph API before reading this book as it includes some advanced techniques like a initial deferred shading implementation, quick integration with physics engines, and so on. There are totally 9 chapters focusing on different fields, including the installation, nodes, geometries, camera manipulating, animations, effects, terrain building, data management, GUI integration, and a bonus chapter which is removed from the book content because of the too high page count but added as a free sample chapter on the Packt website. You can buy the book at the Packt Publishing website: http://www.packtpub.com/openscenegrap-3-for-advanced-3d-programming-usin g-api-cookbook/book and/or Amazon.co.uk: http://www.amazon.co.uk/OpenSceneGraph-3-Cookbook-R-Wang/dp/184951688X The source code can be downloaded freely at: https://github.com/xarray/osgRecipes Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
Hi Robert, On 2 April 2012 14:21, Frederic Bouvier fredlis...@free.fr wrote: may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? The OSG inherits state/settings from parents, there isn't any sibling inheritance. One more thing: it happens that I implement cascaded shadow map with a single shadow map and 4 cascades. My scenegraph is like this : master camera = slave shadow camera (hold an fbo on a S x S depth texture) = cascade1 : child camera, viewport (S/2 x S/2 @ 0, 0) = cascade2 : child camera, viewport (S/2 x S/2 @ 0, S/2) = cascade3 : child camera, viewport (S/2 x S/2 @ S/2, 0) = cascade4 : child camera, viewport (S/2 x S/2 @ S/2, S/2) I want to know if the inherited viewpoint is propagated to the cascade camera if I set the reference frame of the main shadow camera and the 4 cascades to ABSOLUTE_RF_INHERIT_VIEWPOINT to complement the question, I am asking myself if the code in SceneView::cullStage line 972 of SceneView.cpp (v3.0.1) that reads : cullVisitor-pushModelViewMatrix(mv.get(),osg::Transform::ABSOLUTE_RF); is right. It seems to ignore the reference frame settings of the slave camera and assume ABSOLUTE_RF. Should I manually set the viewpoint of my main shadow camera ? and how ? Regards, -Fred ___ 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] OpenSceneGraph 3 Cookbook Published!
Hi Wang, Great I just ordered it and delivered to my tablet :) Cheers Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
On 2 April 2012 14:21, Frederic Bouvier fredlis...@free.fr wrote: may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? The OSG inherits state/settings from parents, there isn't any sibling inheritance. One more thing: it happens that I implement cascaded shadow map with a single shadow map and 4 cascades. My scenegraph is like this : master camera = slave shadow camera (hold an fbo on a S x S depth texture) = cascade1 : child camera, viewport (S/2 x S/2 @ 0, 0) = cascade2 : child camera, viewport (S/2 x S/2 @ 0, S/2) = cascade3 : child camera, viewport (S/2 x S/2 @ S/2, 0) = cascade4 : child camera, viewport (S/2 x S/2 @ S/2, S/2) I want to know if the inherited viewpoint is propagated to the cascade camera if I set the reference frame of the main shadow camera and the 4 cascades to ABSOLUTE_RF_INHERIT_VIEWPOINT to complement the question, I am asking myself if the code in SceneView::cullStage line 972 of SceneView.cpp (v3.0.1) that reads : cullVisitor-pushModelViewMatrix(mv.get(),osg::Transform::ABSOLUTE_RF); is right. It seems to ignore the reference frame settings of the slave camera and assume ABSOLUTE_RF. Should I manually set the viewpoint of my main shadow camera ? and how ? to end my jabber, and for the record, I fixed my issue by setting the reference frame of the main shadow camera to ABSOLUTE_RF and a dummy view matrix where the eye point is at viewer's position. This view matrix is updated every frame. Cascade cameras use ABSOLUTE_RF_INHERIT_VIEWPOINT reference frame. Initially my cascade was not drawn because the frustum culling on the main camera was in the way, so instead of setting a projection volume that enclose the 4 volumes of its child, I disable culling with setCullingMode(NO_CULLING) Hope that can help Regards, -Fred ___ 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] problem with svn (atomic counter?)
Hi Martin
I use VS 2010, Windows 7 64 bit, Nvidia 460M, Driver 296.10, osg 3.1.2
build in 32 bit
and osggeometryshader work fine.
As I am a little bit paranoiac with the crappy VS developpement tools :
Have you restart Windows and/or VS after NVidia driver update ?
Have you rebuild OSG since your last SVN update or just do a 'build' ?
Are you sure to use good osg dll ?
HTH
David Callu
2012/4/2 Martin Naylor martinnay...@virginmedia.com
Hello all,
I have been just doing some testing of OSG (latest from the SVN).
Whilst executing osggeomertyshaders I am getting a crash:
CALL STACK:
msvcp90d.dll!std::_Debug_message(const wchar_t *
message=0x07fee9bb9b68, const wchar_t * file=0x07fee9bb9bb0,
unsigned int line=779) Line 24 C++
osg92-osgd.dll!std::vectorint,std::allocatorint
::operator[](unsigned __int64 _Pos=0) Line 780C++
osg92-osgd.dll!osg::Program::PerContextProgram::linkProgram(osg::State
state={...}) Line 784 + 0xf bytes C++
osg92-osgd.dll!osg::Program::compileGLObjects(osg::State
state={...}) Line 233 C++
osg92-osgd.dll!osg::StateSet::compileGLObjects(osg::State
state={...}) Line 1335 C++
osg92-osgUtild.dll!osgUtil::GLObjectsVisitor::apply(osg::StateSet
stateset={...}) Line 114 C++
LOCALS:
+ end (3452816845,Bad Ptr)
std::_Treestd::_Tmap_traitsunsigned
int,std::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessunsigned int,std::allocatorstd::pairunsigned int const
,std::basic_stringchar,std::char_traitschar,std::allocatorchar
,0
::iterator
+ it (3452816845,Bad Ptr)
std::_Treestd::_Tmap_traitsunsigned
int,std::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::lessunsigned int,std::allocatorstd::pairunsigned int const
,std::basic_stringchar,std::char_traitschar,std::allocatorchar
,0
::iterator
bufferIndex [0]() std::vectorint,std::allocatorint
bufferIndexToUniformIndices [14757395258967641292]()
std::mapint,std::vectorint,std::allocatorint
,std::lessint,std::allocatorstd::pairint const
,std::vectorint,std::allocatorint
activeAtomicCounterBuffers 3435973836unsigned
int
uniformIndex[0]() std::vectorunsigned
int,std::allocatorunsigned int
+ this0x02838be0 {_program=0x027f8540
_extensions={...} _glProgramHandle=4 ...}
osg::Program::PerContextProgram * const
Sorry for the garbage! I am using Windows VS 2008 as my compliler :)
Unfortunately I have updated my Nvidia drivers to the latest a few days ago
so I am unsure if it's a driver or the later openGL4.2 stuff that has been
introduced in OSG just recently having review the logs of program.cpp ?
Regards
Martin Naylor
___
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 using OSG GLSL uniforms and vertex attributes
Ok, here's what I did to solve it.
First, I rebuilt my binaries and retested. Strangely, I had different results,
though it may be that I didn't do something the first time that I did the
second. I can't imagine rebuilding OSG would help, but it appears as though it
did.
Second, I retested the 120 shader version, and transitioned from gl_ to osg_
builtins one at a time. Here the secret divulged itself:
osg_ModelViewProjectionMatrix and osg_Vertex must *not* be declared, but
everything else must. That is, declaring the first two generated duplicate
declaration errors, but omitting any other built-ins generated undeclared
idnetifier errors. Note that I only tested osg_Normal, osg_ModelViewMatrix,
and osg_NormalMatrix in addition to the first two.
I still enabled the built-ins using:
Code:
(*itr)-getState()-setUseModelViewAndProjectionUniforms(true);
(*itr)-getState()-setUseVertexAttributeAliasing(true);
For posterity's sake, I've included the source I used to test.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46756#46756
/* OpenSceneGraph example, osgvertexattributes.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osgUtil/ShaderGen
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
class ConvertToVertexAttibArrays : public osg::NodeVisitor
{
public:
typedef std::pairunsigned int, std::string AttributeAlias;
ConvertToVertexAttibArrays():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
_manualVertexAliasing = false;
// mappings taken from
http://www.opengl.org/registry/specs/NV/vertex_program.txt
_vertexAlias = AttributeAlias(0, osg_Vertex);
_normalAlias = AttributeAlias(2, osg_Normal);
_colorAlias = AttributeAlias(3, osg_Color);
_secondaryColorAlias = AttributeAlias(4, osg_SecondaryColor);
_fogCoordAlias = AttributeAlias(5, osg_FogCoord);
_texCoordAlias[0] = AttributeAlias(8, osg_MultiTexCoord0);
_texCoordAlias[1] = AttributeAlias(9, osg_MultiTexCoord1);
_texCoordAlias[2] = AttributeAlias(10, osg_MultiTexCoord2);
_texCoordAlias[3] = AttributeAlias(11, osg_MultiTexCoord3);
_texCoordAlias[4] = AttributeAlias(12, osg_MultiTexCoord4);
_texCoordAlias[5] = AttributeAlias(13, osg_MultiTexCoord5);
_texCoordAlias[6] = AttributeAlias(14, osg_MultiTexCoord6);
_texCoordAlias[7] = AttributeAlias(15, osg_MultiTexCoord7);
}
void bindAttribute(osg::Program program, const AttributeAlias alias)
{
program.addBindAttribLocation(alias.second, alias.first);
}
void replaceAndBindAttrib(osg::Program program, std::string source,
const std::string originalStr, const AttributeAlias alias, const std::string
declarationPrefix)
{
if (replace(source, originalStr, alias.second))
{
source.insert(0, declarationPrefix + alias.second +
std::string(;\n));
if (_manualVertexAliasing) bindAttribute(program, alias);
}
}
void replaceBuiltInUniform(std::string source, const std::string
originalStr, const std::string newStr, const std::string declarationPrefix)
{
if (replace(source, originalStr, newStr))
{
source.insert(0, declarationPrefix + newStr +
std::string(;\n));
}
}
void convertVertexShader(osg::Program program, osg::Shader shader)
{/*
std::string source = shader.getShaderSource();
// replace ftransform as it only works with built-ins
replace(source, ftransform(), gl_ModelViewProjectionMatrix *
gl_Vertex);
#if 1
replaceAndBindAttrib(program, source, gl_Normal, _normalAlias,
attribute vec3 );
replaceAndBindAttrib(program, source, gl_Vertex,
