[osg-users] setTexCoordPointer
hi, what does the first parameter=unit in state.setTexCoordPointer mean? the documentation just tells me its called unit ;) is this glEnableClientState(GL_TEXTURE_COORD_ARRAY); glTexCoordPointer(2,GL_FLOAT,0,texCoordArray); the same as _state.setTexCoordPointer(0,2,GL_FLOAT,0,texCoordArray); ? _state is a member variable of ShapeDrawable. thanks in advance, andi *** Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *** ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Matrix::getRotate return non-normalized Quat
Hi folks -- I've noticed that, under some circumstances, Matrix::getRotate() returns a non-normalized Quat. For example, given the following code: osg::Matrix m( +0.00057735, +0., +0., +0., +0., +0.00057735, +0., +0., +0., +0., +0.00057735, +0., -0.57735026, +1.42264974, -0.57735026, +1. ) ; std::cout m.getRotate() ; I get this output: 0.00 0.00 0.00 0.500433 This seems odd because, given the same source Matrix, Matrix::decompose() returns a normalized rotation Quat (0, 0, 0, 1). Given that both Quats represent a rotation from the same Matrix, I'd expect them to be identical. (Mathematically, they are identical, except the getRotate() return value isn't normalized.) Is this a bug that needs to be fixed? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setTexCoordPointer
hi, what does the first parameter=unit in state.setTexCoordPointer mean? the documentation just tells me its called unit ;) It's the texture unit for multitexturing. Sounds like you didn't read the OSG Quick Start Guide. http://www.lulu.com/content/767629 Hope that helps, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem to consider: Shadow maps and LOD computation
Hello everyone, I have following problem: Shadow Mapping - so called duelling frusta case ie light direction opposite to view direction. Objects drawn into Shadow Map also contain LOD nodes. When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Is there a way to overcome this problem and force LODs drawn into shadow map to be base on distances from main cam ? Thanks in advance, any ideas would be appreciated, Wojtek Lewandowski___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Hi Wojtek, When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Oh, nice problem there... It's probably just an oversight, and the fact that osgShadow tries to be as transparent and as unobtrusive as possible will make it harder to overcome... I don't have any suggestions for this, perhaps Robert will have some thoughts as it comes down more to how to design the interaction between shadowing and LODs. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ephemeris Data
Hi Folks We doing some work with the OSG ephemeris and one of our engineers has started to kick in to shape for 2.3x, some quirks though seems to be a Jimmy Hendrix and Purple haze message rather than a blue sky but I digress Does any one have a link to the imagery data the OSG ephemeris data ( imagery etc for the sun, moon, planets etc), the old pages point to cvs which is not there and Dons andesengineering.com has been inaccessible to me for several weeks Thanks Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 571-265-2612 Telephone (Work): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Ideally, you would want the shadow caster's LOD to be selected based on the distance between the eyepoint and the shadow receiver, wouldn't you? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Hi J-S, I am not sure what is the difference between EyePoint and ViewPoint but really hope that EyePoint/ViewPoint duo was introduced for problems like mine. If I only knew how to use them to my advantage ;-) Cheers, Wojtek - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, February 26, 2008 3:29 PM Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD computation Hi Wojtek, When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Oh, nice problem there... It's probably just an oversight, and the fact that osgShadow tries to be as transparent and as unobtrusive as possible will make it harder to overcome... I don't have any suggestions for this, perhaps Robert will have some thoughts as it comes down more to how to design the interaction between shadowing and LODs. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Hi Paul, Ideally, you would want the shadow caster's LOD to be selected based on the distance between the eyepoint and the shadow receiver, wouldn't you? Actually I would like it to be based on the distance from eyepoint to Shadow Caster (measured in main camera view space). If its based on / or adjusted to distance from Shadow Receiver we may end up with one LOD used on main camera screen and other LOD used in shadow map texture. Ie shape of shadow would be different than object on the screen casting the shadow. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ephemeris Data
On Feb 26, 2008, at 8:31 AM, Gordon Tomlinson wrote: Hi Folks We doing some work with the OSG ephemeris and one of our engineers has started to kick in to shape for 2.3x, some quirks though seems to be a Jimmy Hendrix and Purple haze message rather than a blue sky but I digress Does any one have a link to the imagery data the OSG ephemeris data ( imagery etc for the sun, moon, planets etc), the old pages point to cvs which is not there and Dons andesengineering.com has been inaccessible to me for several weeks This appears to be working: http://andesengineering.com/Projects/OsgEphemeris/ here is the cvs command. I just tried it out. cvs -d :pserver:[EMAIL PROTECTED]:/cvs/osg co osgEphemeris Hope that helps. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ephemeris Data
Thanks Doug For what ever reason Don's sight is not reachable for me, I'll have to try something else -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCorkle Sent: Tuesday, February 26, 2008 10:00 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data On Feb 26, 2008, at 8:31 AM, Gordon Tomlinson wrote: Hi Folks We doing some work with the OSG ephemeris and one of our engineers has started to kick in to shape for 2.3x, some quirks though seems to be a Jimmy Hendrix and Purple haze message rather than a blue sky but I digress Does any one have a link to the imagery data the OSG ephemeris data ( imagery etc for the sun, moon, planets etc), the old pages point to cvs which is not there and Dons andesengineering.com has been inaccessible to me for several weeks This appears to be working: http://andesengineering.com/Projects/OsgEphemeris/ here is the cvs command. I just tried it out. cvs -d :pserver:[EMAIL PROTECTED]:/cvs/osg co osgEphemeris Hope that helps. Doug ___ 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] Matrix::getRotate return non-normalized Quat
Hi Paul, Paul Martz wrote: Hi folks -- I've noticed that, under some circumstances, Matrix::getRotate() returns a non-normalized Quat. For example, given the following code: osg::Matrix m( +0.00057735, +0., +0., +0., +0., +0.00057735, +0., +0., +0., +0., +0.00057735, +0., -0.57735026, +1.42264974, -0.57735026, +1. ) ; std::cout m.getRotate() ; I get this output: 0.00 0.00 0.00 0.500433 This seems odd because, given the same source Matrix, Matrix::decompose() returns a normalized rotation Quat (0, 0, 0, 1). Given that both Quats represent a rotation from the same Matrix, I'd expect them to be identical. (Mathematically, they are identical, except the getRotate() return value isn't normalized.) Is this a bug that needs to be fixed? I'm not sure if it should be called a bug or missing feature :/ AFAIK, the current getRotate code does not handle cases where the matrix itself is scaled. At some point I made modifications to getRotate to first unscale the matrix, but: 1) It makes it slower for all the normal unscaled cases 2) There were other gotchas (e.g. non-uniform scaling and reflection) I did not find a suitable solution. I've never tried decompose, maybe that is the answer. If you look at the code in osgunittests that exercises the getRotate method, I think you'll find some code in there that can test for the scaled matrix case. regards jp Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ephemeris Data
Could you grab a snaphot from here: http://andesengineering.com/Projects/OsgEphemeris/ or you cannot even get to the main website? Doug On Feb 26, 2008, at 9:20 AM, Gordon Tomlinson wrote: Thanks Doug For what ever reason Don's sight is not reachable for me, I'll have to try something else -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCorkle Sent: Tuesday, February 26, 2008 10:00 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data On Feb 26, 2008, at 8:31 AM, Gordon Tomlinson wrote: Hi Folks We doing some work with the OSG ephemeris and one of our engineers has started to kick in to shape for 2.3x, some quirks though seems to be a Jimmy Hendrix and Purple haze message rather than a blue sky but I digress Does any one have a link to the imagery data the OSG ephemeris data ( imagery etc for the sun, moon, planets etc), the old pages point to cvs which is not there and Dons andesengineering.com has been inaccessible to me for several weeks This appears to be working: http://andesengineering.com/Projects/OsgEphemeris/ here is the cvs command. I just tried it out. cvs -d :pserver:[EMAIL PROTECTED]:/cvs/osg co osgEphemeris Hope that helps. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Matrix::getRotate return non-normalized Quat
AFAIK, the current getRotate code does not handle cases where the matrix itself is scaled. Thanks for the info. I added code comments to getRotate() to document this assumption in the code. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting Home position in OSG Viewer
Can anyone help me out with this? John - Original Message - From: Image Modelling Limited (IML) [EMAIL PROTECTED] To: OSG Mail List osg-users@lists.openscenegraph.org Sent: Tuesday, February 12, 2008 9:41 AM Subject: [osg-users] Setting Home position in OSG Viewer Hi all, New to this list so please be kind I currently use the good old SGI Perfly viewer to look at individual models and utilise the option in perfly to set the initial start position and attitude using the -p and -e options. It is currently possible, or could it be possible, to do this in the OSGViewer. I have had a look and play with it but it wasn't immediatly obvious. Just for the record, I am not a programmer but a modeller, so going in and hacking the code is not really an option. I would really like to get to use the osg viwer as I would guess the OpenFlight loader support is at a newer version that the 15.7 I am fixed at in perfly... TIA, John Wintle Image Modelling Limited. www.image-modelling.co.uk ___ 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 to consider: Shadow maps and LOD computation
It looks like you'll need to create a custom cull visitor that stores the desired eye point and overrides the CullVisitor::getViewPoint method to return the stored eye point instead of the CullStack view point. I've never used (or even looked at osg::ShadowMaps) so I could be completely wrong :) Brian [EMAIL PROTECTED] wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Wojciech Lewandowski [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 02/26/2008 09:54AM Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD computation Hi Paul, Ideally, you would want the shadow caster's LOD to be selected based on the distance between the eyepoint and the shadow receiver, wouldn't you? Actually I would like it to be based on the distance from eyepoint to Shadow Caster (measured in main camera view space). If its based on / or adjusted to distance from Shadow Receiver we may end up with one LOD used on main camera screen and other LOD used in shadow map texture. Ie shape of shadow would be different than object on the screen casting the shadow. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Ideally, you would want the shadow caster's LOD to be selected based on the distance between the eyepoint and the shadow receiver, wouldn't you? Actually I would like it to be based on the distance from eyepoint to Shadow Caster (measured in main camera view space). If its based on / or adjusted to distance from Shadow Receiver we may end up with one LOD used on main camera screen and other LOD used in shadow map texture. Ie shape of shadow would be different than object on the screen casting the shadow. That might be the solution you want, but I don't think it's a good general solution for proper rendering. If your eye is close to the shadow but far from the caster, then the shadow covers a large pixel area and the caster covers a small pixel area. This is exactly the case where you would want to use two different levels of detail for the caster -- one to create a high resolution shadow, and the lower LOD for the final rendered image of the caster. If the LOD distances are configured correctly, the user should not notice that the caster and shadow were rendered with two different levels of detail; the difference will be lost in screen resolution. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting Home position in OSG Viewer
Hi John My understanding is that at this time the OSG Viewer in 2.x does not currently support setting a home position via the command line Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __ Telephone (Cell): (+1) 571-265-2612 Telephone (Work): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Image Modelling Limited (IML) Sent: Tuesday, February 26, 2008 11:07 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Setting Home position in OSG Viewer Can anyone help me out with this? John - Original Message - From: Image Modelling Limited (IML) [EMAIL PROTECTED] To: OSG Mail List osg-users@lists.openscenegraph.org Sent: Tuesday, February 12, 2008 9:41 AM Subject: [osg-users] Setting Home position in OSG Viewer Hi all, New to this list so please be kind I currently use the good old SGI Perfly viewer to look at individual models and utilise the option in perfly to set the initial start position and attitude using the -p and -e options. It is currently possible, or could it be possible, to do this in the OSGViewer. I have had a look and play with it but it wasn't immediatly obvious. Just for the record, I am not a programmer but a modeller, so going in and hacking the code is not really an option. I would really like to get to use the osg viwer as I would guess the OpenFlight loader support is at a newer version that the 15.7 I am fixed at in perfly... TIA, John Wintle Image Modelling Limited. www.image-modelling.co.uk ___ 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] Setting Home position in OSG Viewer
Hello John, Can anyone help me out with this? Robert answered some time ago, the osgviewer application itself is not designed to do this, but it can be done programmatically. So if you're not willing to roll up your sleeves or get someone to do it for you, it looks like you're out of luck. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23925/focus=24053 J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting Home position in OSG Viewer
sorry i didn't see the original reply from robert john - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, February 26, 2008 4:31 PM Subject: Re: [osg-users] Setting Home position in OSG Viewer Hello John, Can anyone help me out with this? Robert answered some time ago, the osgviewer application itself is not designed to do this, but it can be done programmatically. So if you're not willing to roll up your sleeves or get someone to do it for you, it looks like you're out of luck. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23925/focus=24053 J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Hi Brian, It looks like you'll need to create a custom cull visitor that stores the desired eye point and overrides the CullVisitor::getViewPoint method to return the stored eye point instead of the CullStack view point. Thats sounds like it something I might be able to do ;-). Do you know if changed viewPoint would affect other types of nodes apart from LOD ? Thanks, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting Home position in OSG Viewer
MAGIC! You will have a willing tester! john - Original Message - From: Mike Weiblen [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, February 26, 2008 5:32 PM Subject: Re: [osg-users] Setting Home position in OSG Viewer osgviewer is driven by the requirements Robert deems appropriate. fwiw I have been putting together a super osgviewer/perfly tentatively called superfly where I put all the bells and whistles driven by my requirements; your home position requirement meshes with my goals for superfly. It's not available yet, but I'll clean up the sharp edges and get it posted to the osgToy SVN prob this weekend. cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Image Modelling Limited (IML) Sent: Tuesday, February 26, 2008 10:50 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Setting Home position in OSG Viewer it's a shame, as it would make it a lot more usable for us non programmer types who need to look at models efficiently, and I don't just mean individual items, as it will do this for you, but larger more complex items where you need to position yourself uniquely. No-one does it as well as SGI did with Perfly...! John - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, February 26, 2008 4:31 PM Subject: Re: [osg-users] Setting Home position in OSG Viewer Hello John, Can anyone help me out with this? Robert answered some time ago, the osgviewer application itself is not designed to do this, but it can be done programmatically. So if you're not willing to roll up your sleeves or get someone to do it for you, it looks like you're out of luck. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23925/f ocus=24053 J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users 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 to consider: Shadow maps and LOD computation
Wojtek, I don't know. I just looked at the LOD::traverse method and saw that it called the node visitor getDistanceToViewPoint method, which for the CullVisitor calls the CullStack::getViewPointLocal method. Ooops, looks like you'll need to override CullVisitor::getDistanceToViewPoint, not CullVisitor::getViewPoint. Also, the view point will need to be relative to the LOD object. I searched the entire OSG tree and only LOD and PagedLOD call getDistanceToViewPoint, so it should be pretty safe. Caveat - I've only looked at the code and haven't tried this. Brian [EMAIL PROTECTED] wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Wojciech Lewandowski [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 02/26/2008 12:15PM Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD computation Hi Brian, It looks like you'll need to create a custom cull visitor that stores the desired eye point and overrides the CullVisitor::getViewPoint method to return the stored eye point instead of the CullStack view point. Thats sounds like it something I might be able to do ;-). Do you know if changed viewPoint would affect other types of nodes apart from LOD ? Thanks, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting Home position in OSG Viewer
osgviewer is driven by the requirements Robert deems appropriate. fwiw I have been putting together a super osgviewer/perfly tentatively called superfly where I put all the bells and whistles driven by my requirements; your home position requirement meshes with my goals for superfly. It's not available yet, but I'll clean up the sharp edges and get it posted to the osgToy SVN prob this weekend. cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Image Modelling Limited (IML) Sent: Tuesday, February 26, 2008 10:50 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Setting Home position in OSG Viewer it's a shame, as it would make it a lot more usable for us non programmer types who need to look at models efficiently, and I don't just mean individual items, as it will do this for you, but larger more complex items where you need to position yourself uniquely. No-one does it as well as SGI did with Perfly...! John - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, February 26, 2008 4:31 PM Subject: Re: [osg-users] Setting Home position in OSG Viewer Hello John, Can anyone help me out with this? Robert answered some time ago, the osgviewer application itself is not designed to do this, but it can be done programmatically. So if you're not willing to roll up your sleeves or get someone to do it for you, it looks like you're out of luck. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23925/f ocus=24053 J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users 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 to consider: Shadow maps and LOD
Hi Wojciech, Robert and I discussed this issue in great detail over a year ago. Here are some related email threads: http://osgcvs.no-ip.com/osgarchiver/archives/August2006/0307.html http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-October/003697.html Eventually, Robert made some changes to OSG (including the addition of the View class) which eliminated this problem. It fixed my own shadows completely. I wonder if your shadows are just finding some corner case that is tricking Robert's fix into not working -- Terry Welsh - mogumbo 'at' gmail.com www.reallyslick.com | www.mogumbo.com Message: 5 Date: Tue, 26 Feb 2008 15:18:13 +0100 From: Wojciech Lewandowski [EMAIL PROTECTED] Subject: [osg-users] Problem to consider: Shadow maps and LOD computation To: osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=windows-1250 Hello everyone, I have following problem: Shadow Mapping - so called duelling frusta case ie light direction opposite to view direction. Objects drawn into Shadow Map also contain LOD nodes. When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Is there a way to overcome this problem and force LODs drawn into shadow map to be base on distances from main cam ? Thanks in advance, any ideas would be appreciated, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ephemeris Data
Gordon, I've tar'd up a fresh copy of the osgephemeris tree and placed it at http://snowy.arsc.alaska.edu/music/osgephemeris-cvs-20080226.tar Yep, the location is a bit odd, but this is what I have for posting atm. There are several textures (moon, sun, sky) within, but no planets. This is not a permanent archive. Please let me know when you have what you need. hth -bob On Tue, 26 Feb 2008, Gordon Tomlinson wrote: Yeh just Don's site times out for me I'll see if I can do it from another location I can see on my cell just not from my PC's wierd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCorkle Sent: Tuesday, February 26, 2008 10:50 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data Could you grab a snaphot from here: http://andesengineering.com/Projects/OsgEphemeris/ or you cannot even get to the main website? Doug On Feb 26, 2008, at 9:20 AM, Gordon Tomlinson wrote: Thanks Doug For what ever reason Don's sight is not reachable for me, I'll have to try something else -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCorkle Sent: Tuesday, February 26, 2008 10:00 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data On Feb 26, 2008, at 8:31 AM, Gordon Tomlinson wrote: Hi Folks We doing some work with the OSG ephemeris and one of our engineers has started to kick in to shape for 2.3x, some quirks though seems to be a Jimmy Hendrix and Purple haze message rather than a blue sky but I digress Does any one have a link to the imagery data the OSG ephemeris data ( imagery etc for the sun, moon, planets etc), the old pages point to cvs which is not there and Dons andesengineering.com has been inaccessible to me for several weeks This appears to be working: http://andesengineering.com/Projects/OsgEphemeris/ here is the cvs command. I just tried it out. cvs -d :pserver:[EMAIL PROTECTED]:/cvs/osg co osgEphemeris Hope that helps. Doug ___ 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] ephemeris Data
Bob Thank you that was most kind of you, very much appreciated Downloaded many Thanks Gordon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Huebert Sent: Tuesday, February 26, 2008 1:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data Gordon, I've tar'd up a fresh copy of the osgephemeris tree and placed it at http://snowy.arsc.alaska.edu/music/osgephemeris-cvs-20080226.tar Yep, the location is a bit odd, but this is what I have for posting atm. There are several textures (moon, sun, sky) within, but no planets. This is not a permanent archive. Please let me know when you have what you need. hth -bob On Tue, 26 Feb 2008, Gordon Tomlinson wrote: Yeh just Don's site times out for me I'll see if I can do it from another location I can see on my cell just not from my PC's wierd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCorkle Sent: Tuesday, February 26, 2008 10:50 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data Could you grab a snaphot from here: http://andesengineering.com/Projects/OsgEphemeris/ or you cannot even get to the main website? Doug On Feb 26, 2008, at 9:20 AM, Gordon Tomlinson wrote: Thanks Doug For what ever reason Don's sight is not reachable for me, I'll have to try something else -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCorkle Sent: Tuesday, February 26, 2008 10:00 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ephemeris Data On Feb 26, 2008, at 8:31 AM, Gordon Tomlinson wrote: Hi Folks We doing some work with the OSG ephemeris and one of our engineers has started to kick in to shape for 2.3x, some quirks though seems to be a Jimmy Hendrix and Purple haze message rather than a blue sky but I digress Does any one have a link to the imagery data the OSG ephemeris data ( imagery etc for the sun, moon, planets etc), the old pages point to cvs which is not there and Dons andesengineering.com has been inaccessible to me for several weeks This appears to be working: http://andesengineering.com/Projects/OsgEphemeris/ here is the cvs command. I just tried it out. cvs -d :pserver:[EMAIL PROTECTED]:/cvs/osg co osgEphemeris Hope that helps. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VR2008 attendees?
Greetings, Are there any osg folks going to be attending the vr2008 conference next month? If so, would it be possible to get together and put some faces to names? -bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD
Thanks, So you say that OSG is supposed to work the way I want. I suspected that EyePoint/ViewPoint methods could be somehow used for this purpose but it looks like one of them was exactly added for this purpose. Thanks for clarification. So now it seems that my ShadowMap derived code might have another problem. I will look into it and see what goes wrong. Thanks again, Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Terry Welsh Sent: Tuesday, February 26, 2008 7:07 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD Hi Wojciech, Robert and I discussed this issue in great detail over a year ago. Here are some related email threads: http://osgcvs.no-ip.com/osgarchiver/archives/August2006/0307.html http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007- October/003697.html Eventually, Robert made some changes to OSG (including the addition of the View class) which eliminated this problem. It fixed my own shadows completely. I wonder if your shadows are just finding some corner case that is tricking Robert's fix into not working -- Terry Welsh - mogumbo 'at' gmail.com www.reallyslick.com | www.mogumbo.com Message: 5 Date: Tue, 26 Feb 2008 15:18:13 +0100 From: Wojciech Lewandowski [EMAIL PROTECTED] Subject: [osg-users] Problem to consider: Shadow maps and LOD computation To: osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=windows-1250 Hello everyone, I have following problem: Shadow Mapping - so called duelling frusta case ie light direction opposite to view direction. Objects drawn into Shadow Map also contain LOD nodes. When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Is there a way to overcome this problem and force LODs drawn into shadow map to be base on distances from main cam ? Thanks in advance, any ideas would be appreciated, Wojtek Lewandowski ___ 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 to consider: Shadow maps and LOD computation
Hi Guys, You are on the right track with ViewPoint - it exists to solve this problem - a RTT effect that needs to have LOD's chosen on the main cameras view point (eye point) not the RTT's camera's eye point. I introduced it when Terry Welsh came across this problem when he was doing his development of his implementation of parallel split shadow maps. I've just got back so I'm a bit cold on this topic right now, perhaps Terry will remember things better than I... Robert. On Tue, Feb 26, 2008 at 5:46 PM, Brian R Hill [EMAIL PROTECTED] wrote: Wojtek, I don't know. I just looked at the LOD::traverse method and saw that it called the node visitor getDistanceToViewPoint method, which for the CullVisitor calls the CullStack::getViewPointLocal method. Ooops, looks like you'll need to override CullVisitor::getDistanceToViewPoint, not CullVisitor::getViewPoint. Also, the view point will need to be relative to the LOD object. I searched the entire OSG tree and only LOD and PagedLOD call getDistanceToViewPoint, so it should be pretty safe. Caveat - I've only looked at the code and haven't tried this. Brian [EMAIL PROTECTED] wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Wojciech Lewandowski [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 02/26/2008 12:15PM Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD computation Hi Brian, It looks like you'll need to create a custom cull visitor that stores the desired eye point and overrides the CullVisitor::getViewPoint method to return the stored eye point instead of the CullStack view point. Thats sounds like it something I might be able to do ;-). Do you know if changed viewPoint would affect other types of nodes apart from LOD ? Thanks, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ 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] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Hi Robert, all, ... but I just thought if the OS/driver can give us the info for the physical screen setup we could avoid having that in the config file too. I just looked at src/osgViewer/GraphicsWindowWin32.cpp and noticed that the Win32WindowingSystem (subclass of osg::GraphicsContext::WindowingSystemInterface) has a method getScreenPosition(si, x, y, w, h) which gives me the information I need (i.e. the relative position of each screen, hence their physical arrangement). In other words, for 2 side-by-side screens, it will return screen 1 = 0, 0, 1280, 1024 screen 2 = 1280, 0, 1280, 1024 and for 2 screens one above the other, it will return screen 1 = 0, 0, 1280, 1024 screen 2 = 0, 1024, 1280, 1024 The only problem is that this class is not exposed, so I cannot use that method. I could copy the code into my project, but that's unclean, plus I wouldn't get any support for other OSes... Assuming the same thing is possible for X and/or MacOS, would it be possible to expose this method in osg::GraphicsContext::WindowingSystemInterface? It would then be possible to get osgViewer to support screen arrangements other than a basic horizontal linear setup, plus it would be nice for applications to use as well :-) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Thanks Terry, Brain and Robert, I will follow all your ViewPoint suggestions tomorrow. Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Osfield Sent: Tuesday, February 26, 2008 9:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD computation Hi Guys, You are on the right track with ViewPoint - it exists to solve this problem - a RTT effect that needs to have LOD's chosen on the main cameras view point (eye point) not the RTT's camera's eye point. I introduced it when Terry Welsh came across this problem when he was doing his development of his implementation of parallel split shadow maps. I've just got back so I'm a bit cold on this topic right now, perhaps Terry will remember things better than I... Robert. On Tue, Feb 26, 2008 at 5:46 PM, Brian R Hill [EMAIL PROTECTED] wrote: Wojtek, I don't know. I just looked at the LOD::traverse method and saw that it called the node visitor getDistanceToViewPoint method, which for the CullVisitor calls the CullStack::getViewPointLocal method. Ooops, looks like you'll need to override CullVisitor::getDistanceToViewPoint, not CullVisitor::getViewPoint. Also, the view point will need to be relative to the LOD object. I searched the entire OSG tree and only LOD and PagedLOD call getDistanceToViewPoint, so it should be pretty safe. Caveat - I've only looked at the code and haven't tried this. Brian [EMAIL PROTECTED] wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Wojciech Lewandowski [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 02/26/2008 12:15PM Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD computation Hi Brian, It looks like you'll need to create a custom cull visitor that stores the desired eye point and overrides the CullVisitor::getViewPoint method to return the stored eye point instead of the CullStack view point. Thats sounds like it something I might be able to do ;-). Do you know if changed viewPoint would affect other types of nodes apart from LOD ? Thanks, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org--- - This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - --- ___ 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] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Jean-Sébastien Guay schrieb: Assuming the same thing is possible for X and/or MacOS, would it be possible to expose this method in osg::GraphicsContext::WindowingSystemInterface? It would then be possible to get osgViewer to support screen arrangements other than a basic horizontal linear setup, plus it would be nice for applications to use as well :-) I am using a similar mechanism for the OS X implementation of GraphicsWindow. GraphicsWindowCarbon::realize gets the delta form the WindowingInterface for a given screenIdentifier, so the window gets positioned on the right screen. One functionality is missing right now: if you move a window from one screen to another, the screen-identifier gets not updated, so if you go fullscreen, the window gets expanded on the wrong screen. If there's a proposal for the new method I can code the stuff for OS X. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FBO, osg::image and compositeviewer
Hi all, I'm having a problem that is maybe well the result of my lack knowledge but smells like a bug; I have a composite viewer with two views, one camera each. Both cameras share the rendering context. One renders to a window (defined in the traits passed to generate the render context) and the other renders to a FBO. The later has an image attached to the color Buffer, whose size is supposed to determine the FBO size. This is in fact what happens at first, but if I interact a bit with the visible and only window ( where the other camera is rendering)for example moving it, the size of the image attached to the FBO is set to the same value as the window. What I am missing here? Thanks a lot, Nicolas. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem issue
Yes, I noticed that a little while after posting. I looked and thought why do I have the western hemisphere and not the eastern. Then I noticed it. Well live and learn. Michael On Mon, 2008-02-25 at 08:45 +, Robert Osfield wrote: HI Michael, You'll kick yourself, parse the command line and you find no space between las_shallow_topo_east.tif and --geocentric. Robert. On Sun, Feb 24, 2008 at 8:35 PM, Michael W. Hall [EMAIL PROTECTED] wrote: I have the following files land_shallow_topo_east.tif and land_shallow_topo_west.tif. I run the following command: osgdem --bluemarble-west -t ../land_shallow_topo_west.tif --bluemarble-east -t ../land_shallow_topo_east.tif--geocentric -l 12 -o earth.ive When I view the earth.ive file in my program I am only getting a flat image of the western hemisphere. I thought this would generate a model of the earth? What am I missing? It looks like it is only generating six layers also. Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB and PagedDatabase performance.
First, thank you to everyone for their work putting OSG and VPB, this is really an amazing piece of software. Q1: Is there any advantage to having a single large osga model built from say a 16kx16k input or having lots of smaller 4kx4k tiled sections in separate files? Q2: Will rebuilding the database with more levels help smooth out lag spikes when the various LOD nodes come into view ? Q2: What are the parameters can I tweak in an OSG application to tweak how the program runs? Q3: Can I force the OSG application not to swap out the database and just recalculate the mesh ? Background: I have a 16kx16 texture and 4kx4k height map that I have used VPB to build a model of following the walk through on the wiki. While using some simple dynamics to fly over the terrain, my frame rates will nose dive at certain points when database need to be paged in. The terrain takes up about 500 meg on disk and I think might all fight in memory. Thank you all, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Selective lighting in OSG
Hi Pavlos, I tried using osg::Lights briefly as well, but didn't have any luck. I kept seeing the wrong lights being applied and never figured out why. What I said in my previous email about needing to transform BoundingSpheres was wrong. I had a problem in my code that led me to think that. BoundingSpheres in the scenegraph are always transformed just fine and ready for use when computing light influences. My shader method is pretty refined now. I use #defines to create shaders that handle 0, 1, 2, or 3 lights. This improves my framerates slightly over using one shader with 3 lights and leaving unused lights black. On NVidia graphics cards I see really bad hiccups in my framerate (I have not yet tested on ATI cards). The problem seems to diminish over time. Using one shader with 3 lights, the problem drags on for several minutes before mostly disappearing. Using multiple shaders with 0, 1, 2, and 3 lights, the initial hiccups are longer but seem to disappear after a very short time. I have read that NVidia graphics cards do a behind-the-scenes shader recompile when you change the uniforms on a fragment shader. This may be the problem with this lighting technique since I am changing uniforms multiple times per frame. I can confirm that this is only a problem with fragment shaders: if I pass my lighting information as uniform variables to the vertex shader and then send them to the fragment shader through varying variables, the problem goes away. Unfortunately, this solution is impractical because it uses too many shader resources. - Terry Message: 7 Date: Tue, 05 Feb 2008 10:59:03 +0200 From: Pavlos Mavridis [EMAIL PROTECTED] Subject: Re: [osg-users] Selective lighting in OSG To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Terry, Not much progress here. I was using the following completely unconventional and undocumented way to set up a light that affects only one particular node of the scenegraph: osg::ref_ptrosg::Light light = new osg::Light(); int num = lightManager-allocate(); //get an unused opengl light slot light-setLightNum(num); //set misc light parameters (position, ambient, diffuse ...) //node is the osg::Node that I want to apply the light on osg::StateSet* stateset = node-getOrCreateStateSet(); stateset-setAttributeAndModes(light.get(), osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE); The above code works very well when each object has the same number of local lights affecting it (which in your case is always true, if I'm not mistaken). But i recently discovered that I'm getting wrong lighting when the number of local lights varies per object, or if I also use normal osg::LightSources in my scene. I'm not sure why the above approach does not always work, I'll be glad if someone explained this to me. As for the renderstages, to my understanding it's a mechanism to do multipass rendering in osg. Robert suggested to render each object on a different pass/renderstage with the appropriate lights enabled on each pass. But i have yet to figure out the exact way to do it with osg. The only relative example i could find is the depthpartinion one, but it does not help much . Note that this is a completely different way than your shader based approach. In the end I will probably implement a shader based approach, much like yours. But in the meantime I'm busy with some other aspects of our engine. Pavlos Terry Welsh wrote: I made some pretty good progress with selective lighting. How about you, Pavlos? Right now I have a class that stores all my light world-space positions, colors, and attenuation ranges (I'm only doing simple point lights for now). On any node where I want to apply lighting I set a CullCallback and all the lighting Uniforms necessary for 3 lights. The callback retrieves the node's bounding sphere and uses it to decide which, if any, lights have the most influence on the node. Then those lights' parameters are assigned to the node's Uniforms. If there are less than 3 lights that have influence, then black is assigned to some of the light color Uniforms so they won't affect the final image. Currently, this only works for nodes that have no transforms above them. But I believe I can use the NodePath in the NodeVisitor passed to the callback to get all the transformation information I need. Then I can transform the BoundingSphere before using it to calculate light influences. A bigger concern is that I'm doing all my light computations in world-space in my shader. It's usually faster to do lighting computations in view-space (this is how native OpenGL does them). If I was only rendering one view, I could set a view matrix before doing my culling and use it to transform all my light
