[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);

[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.,

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

[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

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

[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

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

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

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

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

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:

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,

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

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

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

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 :)

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

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:

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.

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

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

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

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

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

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

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

Re: [osg-users] ephemeris Data

] 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

[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

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

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

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

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]

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

[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

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

[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

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.