Re: [osg-users] [osgPlugins] GoogleMode
Please unsubscribe temporarily. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Fwd: Mesa and gldirect]
In situations where your customer has bought hardware for another primary use
(try tens of thousands of laptops), ATI or even Intel wins out over Nvidia on
cost it seems.
Then we are stuck with integrated graphics, and poor drivers.
Where the developer has a choice of hardware, just saying no to ATI makes sense.
When your hardware is dictated, you have to do whatever you can.
I have never used Direct3D/DirectX and don't know a thing about it. Maybe we
are on the losing end of this battle.
Chris
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz
Sent: Monday, March 23, 2009 3:48 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] [Fwd: Mesa and gldirect]
There's a very simple answer to the ATI problem: don't buy ATI. Seriously,
their poor OpenGL support has been well-known for at least seven years, if not
longer. In light of this knowledge, why do people keep buying ATI cards for
OpenGL use? It just doesn't make any sense.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien
Guay
Sent: Monday, March 23, 2009 2:04 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] [Fwd: Mesa and gldirect]
Hi Jan,
> Honestly, I think this will be counterproductive. It will only give
> companies an excuse to neglect OpenGL support further or to drop it
> completely ("You can use the emulation!"). The latter would be
> disastrous for all non-Microsoft platforms.
Since the OpenGL over Direct3D layer will only work on Microsoft platforms for
obvious reasons, I don't see how this will affect other platforms at all. If
some developer wants to do 3D on Linux, they have to use OpenGL.
Basically, this is a follow-up to an earlier discussion (a rather long and
heated one as I recall) saying that there were two ways to improve the OSG
experience on Windows platforms or for ATI/AMD hardware, where OpenGL drivers
are pretty bad compared to nVidia:
1. Demand better OpenGL support in drivers (which may be hard and does not
depend on us, i.e. we can ask but we have no control over the result)
2. Create a technological solution, of which an OpenGL over Direct3D layer is
one example.
Of course, it would be much preferable if vendors would, out of their own
volition, improve OpenGL driver quality on Windows. However, since most games
run on Direct3D, there is little incentive for them to do this. In most markets
where OpenGL support is important, the software is already cross-platform, and
thus moving to Linux is less of an issue.
This means that the situation with OpenGL driver quality on Windows is likely
to get worse as developers who depend on OpenGL move to other platforms and
stop demanding good OpenGL driver quality.
> I fail to see the benefits of such move - why to run OpenGL on top of
> Direct3D? Is there *any* usable hardware that has only D3D drivers and
> does not support OpenGL?
Perhaps not, but for most hardware which has Direct3D support, the Direct3D
driver quality is higher than the OpenGL driver quality on Windows (either in
speed, number of serious/show-stopper bugs, etc.).
There's a big difference between supporting OpenGL and supporting it *well*,
and since there are no enforced conformance tests, vendors can support it only
partly if they want...
Basically, I'm trying to find a way so that OpenGL apps can run well on
Windows, independent of what vendor made the graphics card. Since there is a
large pool of Direct3D applications on Windows, making OpenGL calls go through
Direct3D before getting to the video card driver might be one way of doing that.
Of course, this is all theoretical, we can't know what the trade-offs are until
we get a prototype running. And in any case, I'm just relaying info I got,
seeing as this discussion was raised before. If the majority of people don't
see the benefit, nothing will come of it and it'll just die, and we'll just go
on as we have in the past.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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] OSG and GDAL
Hi all, I need to start a new project where I will be reading some GeoTiffs, and possibly CIB/CADRG. I wanted to use GDAL to help with the georeferencing. The only example I saw of using this with OSG is with the gdal-plugin, which works when the file's extension is .gdal. Is this the best place to steal some code from, or is there a better example somewhere? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] getting translate rotate scale right.
As usual, when I spend a day or two on something, I figure out the answer immediately after I post a question to this list. Problem was, I was fooling with the matrix afterwards, and recomposing it. GetRotate and GetScale mess up if matrix has both. Decompose is needed. Heh... I just noticed that Gazi posted this as well. Thanks Chris -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Dorosky, Christopher G Sent: Thursday, January 15, 2009 11:40 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] getting translate rotate scale right. I thought I understood this just fine, but I apparently don't. I have a model that is half the size it needs to be. So, I need to scale it by 2.0 in all directions. It is also in the wrong position, so I need to translate it out to (1000, 2000, 3000); Once it is translated, I need to rotate it. This involves quats, but for simplicities sake, lets say the rotations are 10,20,30. Order is irrelevant, since I am just trying to print these things for now. So, I have a matrix transform. I set the matrix by: Mt->setMatrix(osg::Matrix::scale( scalevec) * osg::Matrix::rotate( rotquat) * osg::Matrix::trans (transvec)); Seems fine. Then, if I print out the values, I get some goofiness. Using the matrix getScale(), getTrans(), getRot() routines, I get them and print out values. Trans is fine. Rot and scale are goofy. This doesn't entirely surprise me, since the order of operations is dependent. In the scene graph, it looks wrong. If I use a position attitude transform, and explicitly set the trans, rot, scale separately, then it works. Before, I would have had a series of matricies that looks like this: Scenegraph root ->trans->rot->scale->model; What's the right way to do this? I'm thinking a translate -> rotate -> -translate is involved somehow. BTW if the scale is 1.0 in all directions, this works just fine. Thanks... Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] getting translate rotate scale right.
I thought I understood this just fine, but I apparently don't. I have a model that is half the size it needs to be. So, I need to scale it by 2.0 in all directions. It is also in the wrong position, so I need to translate it out to (1000, 2000, 3000); Once it is translated, I need to rotate it. This involves quats, but for simplicities sake, lets say the rotations are 10,20,30. Order is irrelevant, since I am just trying to print these things for now. So, I have a matrix transform. I set the matrix by: Mt->setMatrix(osg::Matrix::scale( scalevec) * osg::Matrix::rotate( rotquat) * osg::Matrix::trans (transvec)); Seems fine. Then, if I print out the values, I get some goofiness. Using the matrix getScale(), getTrans(), getRot() routines, I get them and print out values. Trans is fine. Rot and scale are goofy. This doesn't entirely surprise me, since the order of operations is dependent. In the scene graph, it looks wrong. If I use a position attitude transform, and explicitly set the trans, rot, scale separately, then it works. Before, I would have had a series of matricies that looks like this: Scenegraph root ->trans->rot->scale->model; What's the right way to do this? I'm thinking a translate -> rotate -> -translate is involved somehow. BTW if the scale is 1.0 in all directions, this works just fine. Thanks... Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] mipmap source code.
I want to generate a mipmap on the CPU, not throught the graphics card. This is for compatability and speed reasons (threaded). I wanted to use osg::Image::scale(), but it just prints out things saying that volume scaling isn't implemented yet. Does anybody know of any source code for mipmapping that I could have? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Possibly Slightly OT - Mipmap interaction with wireframe.
I have a terrain model, that has some high resolution texture. This texture is mipmapped. If I view the model at a slight distance, it appears blurrier than I would like. If I go into wireframe, it sharpens up. The polygon density is such that it almost appears filled. To make sure this isn't an optical illusion, I quantified this by loading in different colors for the different miplevels. I get a noticable (sharper) shift in the colors loaded for the same view, with wireframe on. Is this a standard GL behavior, or possibly an OSG setting, maybe video card? I have OSG 2.4, nvidia 7950 with recent driver, XP. Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use of osg::Projection without DO_NOT_COMPUTE_NEAR_FAR
Fixed it. It wasn't that. For the archives, I verified that by setting the clear color of the first camera to red, and the second camera to blue. The screen was red. My problem was that when I set the projection matrix, I tried to just change the near and far clip planes. You can't do that if you are setting by frustum, since the variables are not independent. I'm sure there are calls to do this, but I was simply changing the n&f values, which was bad. Thanks for the help. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, August 18, 2008 3:46 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Use of osg::Projection without DO_NOT_COMPUTE_NEAR_FAR Hi Chris, On Sun, Aug 17, 2008 at 10:52 PM, Dorosky, Christopher G <[EMAIL PROTECTED]> wrote: > Thanks, I looked at that, but I haven't quite made it work in my > application. > > I don't quite understand the relationships between the viewer, view > and camera, particularly in regards to adding a geometry node to > either the view (via setSceneData) or the camera (addChild). > > Since I want my new view to be rendered first, I did a > setRenderOrder(PRE_RENDER) on the camera attached to the new view. > > I verified this is somewhat working since I set the clear color to > RED, and the scene shows red where the second view isn't drawing. > > However, I can't get anything to draw from the first view. I have > duplicated the projection matrix and the view matrix each frame, set > the graphics context (once), and disabled the compute_near_far. The problem is most likely down to you not disabling the color clear of the main camera. > Can you shed some light on the relationships between the viewer, view, > and camera, or point me to a good guide? I've written lots on the mailing list over the last year, so have a look at the archives. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use of osg::Projection without DO_NOT_COMPUTE_NEAR_FAR
Thanks, I looked at that, but I haven't quite made it work in my application. I don't quite understand the relationships between the viewer, view and camera, particularly in regards to adding a geometry node to either the view (via setSceneData) or the camera (addChild). Since I want my new view to be rendered first, I did a setRenderOrder(PRE_RENDER) on the camera attached to the new view. I verified this is somewhat working since I set the clear color to RED, and the scene shows red where the second view isn't drawing. However, I can't get anything to draw from the first view. I have duplicated the projection matrix and the view matrix each frame, set the graphics context (once), and disabled the compute_near_far. Can you shed some light on the relationships between the viewer, view, and camera, or point me to a good guide? Thanks, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Saturday, August 16, 2008 11:02 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Use of osg::Projection without DO_NOT_COMPUTE_NEAR_FAR HI Chris, osg::Projection is deprecated by osg::Camera, which is far more flexible for doing this type of work - with osg::Camera embedded in the scene graph you can control the compute near far locally. See the osghud example. Robert. On Sat, Aug 16, 2008 at 12:04 AM, Dorosky, Christopher G <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to integrate some complex openGL code into my scene. > It draws a sky, and works nicely if I set the DO_NOT_COMPUTE_NEAR_FAR. > > So, we had an example of how to make the precipitation effects work, > which involved using osg::Precipitation. > > to do the precipitation, which requires a very close near clip You > grab the osgViewer->getCamera()->getProjectionMatrixAsFrustum(left, > right, bottom, top, near, far) > then turn off the depth test / writing, and do a > setProjectionMatrixAsFrustum(left,right,bottom,top,1.0, 5000) on a > osg::Projection node. > > And it all works fine. Easy way to reset the near far clip, since the > precipitation is drawn last. > > Now I need to do the opposite. I need to extend the far clip way out, > and then allow OSG to do it's regular NEAR_FAR compute. > > So I do this: > > osg::Projection *proj = new osg::Projection. > osgViewer->getCamera()->getProjectionMatrixAsFrustum(left, right, > osgViewer->bottom, > top, near, far); > proj->setMatrix(osg::Matrix::frustum(left, right,bottom,top,1000, > proj->100); > > // additional stuff to proj to turn off depth testing. > > proj->addChild(mySky); > SceneData->addChild(proj); > > But it doesn't work. Lots of flashing. > > The Sky renderbin is -1, so I know it renders first. > > How does osg handle osg::Projections when the DO_NOT_COMPUTE_NEAR_FAR > is not set? > > I would like to leave that functionality on so that it can give me the > best ratio for the rest of the scene. > > Now that I am thinking about it, I am wondering if the camera and node > projections are stacking. > What's the best way to simply have the near/far for my sky node be > different? This shouldn't be bad since depth isn't involved. > > Thanks, > > Chris > > ___ > 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Use of osg::Projection without DO_NOT_COMPUTE_NEAR_FAR
Hi, I'm trying to integrate some complex openGL code into my scene. It draws a sky, and works nicely if I set the DO_NOT_COMPUTE_NEAR_FAR. So, we had an example of how to make the precipitation effects work, which involved using osg::Precipitation. to do the precipitation, which requires a very close near clip You grab the osgViewer->getCamera()->getProjectionMatrixAsFrustum(left, right, bottom, top, near, far) then turn off the depth test / writing, and do a setProjectionMatrixAsFrustum(left,right,bottom,top,1.0, 5000) on a osg::Projection node. And it all works fine. Easy way to reset the near far clip, since the precipitation is drawn last. Now I need to do the opposite. I need to extend the far clip way out, and then allow OSG to do it's regular NEAR_FAR compute. So I do this: osg::Projection *proj = new osg::Projection. osgViewer->getCamera()->getProjectionMatrixAsFrustum(left, right, bottom, top, near, far); proj->setMatrix(osg::Matrix::frustum(left, right,bottom,top,1000, 100); // additional stuff to proj to turn off depth testing. proj->addChild(mySky); SceneData->addChild(proj); But it doesn't work. Lots of flashing. The Sky renderbin is -1, so I know it renders first. How does osg handle osg::Projections when the DO_NOT_COMPUTE_NEAR_FAR is not set? I would like to leave that functionality on so that it can give me the best ratio for the rest of the scene. Now that I am thinking about it, I am wondering if the camera and node projections are stacking. What's the best way to simply have the near/far for my sky node be different? This shouldn't be bad since depth isn't involved. Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Matrix Manipulators and set coordinate frame callback. Different behavior in 2.4?
Works as expected for manipulators 2-4 (flight, drive, terrain). Doesn't
work for #1, which is the trackball manipulator.
Or maybe there is some problem selecting the trackball manipulator, but
I don't think so.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Monday, August 04, 2008 10:07 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Matrix Manipulators and set coordinate frame
callback. Different behavior in 2.4?
Hi Chris,
Just to be clear, does everything work as expected now?
Robert.
On Mon, Aug 4, 2008 at 4:00 PM, Dorosky, Christopher G
<[EMAIL PROTECTED]> wrote:
> Robert,
>
> Thanks for the reply.
>
> I goofed. When using Producer, whatever the default GA is,for #1, it
> doesn't seem to call the callback.
> Using #2 - #4 are fine. By #'s I mean pressing keyboard key 1-4 to
> change the manipulator.
>
> So now I am using #4.
>
> Chris
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Robert Osfield
> Sent: Sunday, August 03, 2008 7:09 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Matrix Manipulators and set coordinate frame
> callback. Different behavior in 2.4?
>
> Hi Chris,
>
> I'm not entirely clear on what bit isn't working, is it that you are
> using osgProducer::Viewer from osgProducer SVN with
> OpenSceneGraph-2.4 and this is behaving differently from osgProducer
> and OpenSceneGaph-1.2?
>
> Robert.
>
> On Mon, Jul 28, 2008 at 4:19 PM, Dorosky, Christopher G
> <[EMAIL PROTECTED]> wrote:
>>
>> Hello all,
>>
>> Under OSG 1.2, I controlled the orientation of an osgGA manipulator
>> through the use of a coordinate frame callback.
>>
>> Under 2.4, I am using the same exact code, but the callback never
>> happens.
>>
>> Here is the code snippet. Viewer is osgProducer (yes, still).
>> This loop runs 4 times.
>>
>> Viewer->getKeySwitchMatrixManipulator()->setHomePosition(eyeECEF,
>> centerECEF, upECEF, false);
>>cECEFFrameCB *cb = new cECEFFrameCB;
>>
>> for(unsigned int i = 0; i<
>> Viewer->getKeySwitchMatrixManipulator()->getNumMatrixManipulators();
>> i++)
>>{
>>osgGA::MatrixManipulator *mm =
>> Viewer->getKeySwitchMatrixManipulator()->getMatrixManipulatorWithInde
>> Viewer->x
>> Viewer->(i
>> );
>>if(mm)
>>{
>>mm->setCoordinateFrameCallback(cb);
>>mm->setHomePosition(eyeECEF, centerECEF,
>> upECEF, false);
>>}
>>}
>>
>> Where the ECEFFrameCB is derived from the
>> osgGA:MatrixManipulator::CoordinateFrameCallback.
>>
>> I put a print in there, and it is never called.
>> Has this functionality been disabled?
>>
>> What I am trying to do is set the up, side, and front vectors so that
>> the manipulator behaves better.
>>
>> Thanks,
>>
>> Chris
>> ___
>> 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.
> or
> g
> ___
> 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.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Matrix Manipulators and set coordinate frame callback. Different behavior in 2.4?
Robert,
Thanks for the reply.
I goofed. When using Producer, whatever the default GA is,for #1, it
doesn't seem to call the callback.
Using #2 - #4 are fine. By #'s I mean pressing keyboard key 1-4 to
change the manipulator.
So now I am using #4.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Sunday, August 03, 2008 7:09 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Matrix Manipulators and set coordinate frame
callback. Different behavior in 2.4?
Hi Chris,
I'm not entirely clear on what bit isn't working, is it that you are
using osgProducer::Viewer from osgProducer SVN with
OpenSceneGraph-2.4 and this is behaving differently from osgProducer and
OpenSceneGaph-1.2?
Robert.
On Mon, Jul 28, 2008 at 4:19 PM, Dorosky, Christopher G
<[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> Under OSG 1.2, I controlled the orientation of an osgGA manipulator
> through the use of a coordinate frame callback.
>
> Under 2.4, I am using the same exact code, but the callback never
> happens.
>
> Here is the code snippet. Viewer is osgProducer (yes, still).
> This loop runs 4 times.
>
> Viewer->getKeySwitchMatrixManipulator()->setHomePosition(eyeECEF,
> centerECEF, upECEF, false);
>cECEFFrameCB *cb = new cECEFFrameCB;
>
> for(unsigned int i = 0; i<
> Viewer->getKeySwitchMatrixManipulator()->getNumMatrixManipulators();
> i++)
>{
>osgGA::MatrixManipulator *mm =
> Viewer->getKeySwitchMatrixManipulator()->getMatrixManipulatorWithIndex
> Viewer->(i
> );
>if(mm)
>{
>mm->setCoordinateFrameCallback(cb);
>mm->setHomePosition(eyeECEF, centerECEF,
> upECEF, false);
>}
>}
>
> Where the ECEFFrameCB is derived from the
> osgGA:MatrixManipulator::CoordinateFrameCallback.
>
> I put a print in there, and it is never called.
> Has this functionality been disabled?
>
> What I am trying to do is set the up, side, and front vectors so that
> the manipulator behaves better.
>
> Thanks,
>
> Chris
> ___
> 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.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Matrix Manipulators and set coordinate frame callback. Different behavior in 2.4?
Hello all,
Under OSG 1.2, I controlled the orientation of an osgGA manipulator
through the use of a coordinate frame callback.
Under 2.4, I am using the same exact code, but the callback never
happens.
Here is the code snippet. Viewer is osgProducer (yes, still).
This loop runs 4 times.
Viewer->getKeySwitchMatrixManipulator()->setHomePosition(eyeECEF,
centerECEF, upECEF, false);
cECEFFrameCB *cb = new cECEFFrameCB;
for(unsigned int i = 0; i<
Viewer->getKeySwitchMatrixManipulator()->getNumMatrixManipulators();
i++)
{
osgGA::MatrixManipulator *mm =
Viewer->getKeySwitchMatrixManipulator()->getMatrixManipulatorWithIndex(i
);
if(mm)
{
mm->setCoordinateFrameCallback(cb);
mm->setHomePosition(eyeECEF, centerECEF, upECEF,
false);
}
}
Where the ECEFFrameCB is derived from the
osgGA:MatrixManipulator::CoordinateFrameCallback.
I put a print in there, and it is never called.
Has this functionality been disabled?
What I am trying to do is set the up, side, and front vectors so that
the manipulator behaves better.
Thanks,
Chris
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sun, moon, clouds. Any recommendations?
Thanks for the replies. I am investigating both. Has anyone run into osgephemeris drawing 2 moons? The sun and the moon look so similiar, I can't tell, but for either today's date, or one month ago, it renders the sun nicely, with a brightness glow, but I get twin moons, separated by 15 degrees or so. Odd. There were also fixes to bring it up to date with osg 2.4. & VS_2005 Should I submit those changes to this forum or somewhere else? Thanks, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Monday, July 21, 2008 10:06 AM To: OpenSceneGraph Users Subject: [osg-users] Sun, moon, clouds. Any recommendations? Hi all, I've gotta add the sun, moon and some 3D clouds to our simulation. Any recommendations on osg-friendly examples to follow? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sun, moon, clouds. Any recommendations?
Hi all, I've gotta add the sun, moon and some 3D clouds to our simulation. Any recommendations on osg-friendly examples to follow? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniform value getting overwritten in shader.
Mike,
Run with osgviewer, the glsl example works.
The problem with that example is that it creates new geometry and
doesn't reuse it.
My model has two parents (MatrixTransforms), A & B. These parents share
the same shader, but have different statesets.
"A" has a stateset setting a new uniform MYCOLOR to (1.0, 0.0, 0.0,
1.0);
"B" has a stateset setting a new uniform MYCOLOR to (0.0, 0.0, 1.0,
1.0);
The scene graph adds A first, then B. They are translated from each
other.
The shader simply sets the gl_FragColor to MYCOLOR.
If "A" and "B" are in the scene, both are RED.
If only "B" is in the scene, it is BLUE.
It appears that the uniform gets trampled. I was careful to make
explicitly new uniforms each time.
Running a different set of geometry under the shader, and setting a new
MYCOLOR to GREEN works.
The problem seems to be with reusing geometry, but applying different
statesets to the parents. The uniform value of the object during its
draw under the second parent retains its first parent value.
For what it's worth, this worked fine under whatever pre-1.2 version we
were using.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Weiblen
Sent: Thursday, May 15, 2008 2:13 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Uniform value getting overwritten in shader.
Does the glsl_simple.osg example datafile work for you? It demonstrates
one shader w/ different values for the "Color1" uniform.
-- mew
On Thu, May 15, 2008 at 2:01 PM, Dorosky, Christopher G
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am having problems with a uniform value getting trumped in a shader.
>
> Here is most of the shader fragment:
>
> ___
>
> os << "\nuniform bool PreMultipliedAlpha;\n"; os << "uniform vec4
> FogUniform;\n";
> os << " vec3 FogColor;\n";
>os << " vec3 FogUniformColor;\n";
>
>os << "void main()\n";
>os << "{\n";
>
>os << " if (PreMultipliedAlpha) {\n";
>os << " FogColor = gl_Fog.color.rgb * gl_FragColor.a;\n";
>if (aFogType == EXP2_FOG)
>os << " FogUniformColor = FogUniform.rgb *
> gl_FragColor.a;\n";
>os << " } else {\n";
>os << " FogColor = gl_Fog.color.rgb;\n";
>if (aFogType == EXP2_FOG)
>os << " FogUniformColor = FogUniform.rgb;\n";
>os << " }\n";
> __
>
> Now, to use it, I have this code...
>
> osg::Group *Topgroup = new osg::Group; // real code this has more
> stuff attached.
> osg::Group *group = new osg::Group;
>
> Topgroup->addChild(group);
>
> // modelA and modelB groups already exist.
>
> modelA->getOrCreateStateSet()->getOrCreateUniform("PreMultipliedAlpha"
> modelA->,
> osg::Uniform::BOOL)->set(true);
> modelB->getOrCreateStateSet()->getOrCreateUniform("PreMultipliedAlpha"
> modelB->,
> osg::Uniform::BOOL)->set(false);
>
>
> group->addChild(modelA);
> group->addChild(modelB);
>
> // Then the Fragment shader is added to the Topgroup node.
> // Didn't include code here because it is long, and it works as shown
> below.
>
> Here is what happens.
> When modelA and modelB are added to the group as shown above, the
> uniform is always false.
>
> If I comment out the line:
> //group->addChild(modelB);
>
> Then I have the uniform set correctly to true.
>
> Reinserting that line, and commenting out
> group->addChild(modelA);
> Has the uniform set correctly to false.
>
> It seems that I can't have both models added with different uniform
> values without one trumping the other.
>
> Am I doing something wrong or is this a bug?
>
> I've tried more obvious things conditional on the uniform value, like
> making the model red or blue with same results.
>
> OSG 1.2, Windows XP
>
> Thanks,
>
> Chris
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> org
>
--
Mike Weiblen -- Austin Texas USA -- http://mew.cx/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Uniform value getting overwritten in shader.
Hello,
I am having problems with a uniform value getting trumped in a shader.
Here is most of the shader fragment:
___
os << "\nuniform bool PreMultipliedAlpha;\n";
os << "uniform vec4 FogUniform;\n";
os << " vec3 FogColor;\n";
os << " vec3 FogUniformColor;\n";
os << "void main()\n";
os << "{\n";
os << " if (PreMultipliedAlpha) {\n";
os << " FogColor = gl_Fog.color.rgb * gl_FragColor.a;\n";
if (aFogType == EXP2_FOG)
os << " FogUniformColor = FogUniform.rgb *
gl_FragColor.a;\n";
os << " } else {\n";
os << " FogColor = gl_Fog.color.rgb;\n";
if (aFogType == EXP2_FOG)
os << " FogUniformColor = FogUniform.rgb;\n";
os << " }\n";
__
Now, to use it, I have this code...
osg::Group *Topgroup = new osg::Group; // real code this has more stuff
attached.
osg::Group *group = new osg::Group;
Topgroup->addChild(group);
// modelA and modelB groups already exist.
modelA->getOrCreateStateSet()->getOrCreateUniform("PreMultipliedAlpha",
osg::Uniform::BOOL)->set(true);
modelB->getOrCreateStateSet()->getOrCreateUniform("PreMultipliedAlpha",
osg::Uniform::BOOL)->set(false);
group->addChild(modelA);
group->addChild(modelB);
// Then the Fragment shader is added to the Topgroup node.
// Didn't include code here because it is long, and it works as shown
below.
Here is what happens.
When modelA and modelB are added to the group as shown above, the
uniform is always false.
If I comment out the line:
//group->addChild(modelB);
Then I have the uniform set correctly to true.
Reinserting that line, and commenting out
group->addChild(modelA);
Has the uniform set correctly to false.
It seems that I can't have both models added with different uniform
values without one trumping the other.
Am I doing something wrong or is this a bug?
I've tried more obvious things conditional on the uniform value, like
making the model red or blue with same results.
OSG 1.2, Windows XP
Thanks,
Chris
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cleaning up old textures.
Thanks Robert. That is really, really slick. I had to do this myself on Performer and it really stunk. For the contract I am working on, I may be stuck with OSG 1.2. Is there something different I have to do under the old regime? I imagine you don't remember back that far, but if you could point me to the appropriate files to check I'd appreciate it. Thanks, Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, April 11, 2008 2:26 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Cleaning up old textures. Hi Chris, When a scene graph is deleted all the OpenGL objects are placed in buffers awaiting deletion of reuse. They can't be deleted right away as you can only delete OpenGL objects from the graphics thread associated with a graphics context - not only might you be calling delete for a thread which doesn't have a context current, you might actually have several contexts to deal with... this is why the OSG has these buffers. The graphics threads call a flush on these buffers on each new frame, and when a graphis context is delete (in OSG-2.x) the GL objects buffers are automatically flushed. Robert. On Thu, Apr 10, 2008 at 10:12 PM, Dorosky, Christopher G <[EMAIL PROTECTED]> wrote: If I have an IVE model, with texture, and I delete the model, what happens to the texture memory the texture was using? Is it freed? What about if the model is on a switch, and I turn the switch off? I am assuming that I have to do something manually to deal with this, either way. I seem to remember an osg::deleteOldTextureObjects() or something like that. Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cleaning up old textures.
If I have an IVE model, with texture, and I delete the model, what happens to the texture memory the texture was using? Is it freed? What about if the model is on a switch, and I turn the switch off? I am assuming that I have to do something manually to deal with this, either way. I seem to remember an osg::deleteOldTextureObjects() or something like that. Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Replacing a stateset.
I've got a strange problem.
After loading in model from openflight, I am trying to replace the
stateset of some of the nodes.
So the code looks like:
loop
{
osg::StateSet *ss = new osg::StateSet;
// do some stuff to it
node->setStateSet(ss);
}
If the node already had a stateset, particularly a shared stateset, is
there anything wrong with this?
If I look at the nodes, some of them have the new statesets, and some of
them don't. (I can tell by the settings).
Do I need to do something to clean up the node if it already had a
shared stateset?
Thanks,
Chris
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniforms and state sorting
I think you had a typo in the second post. You meant:
osg::StateSet* NewSS = new osg::StateSet;
NewSS->setName("LightPoint state set");
NewSS->getOrCreateUniform("Texture2DEnabled",
osg::Uniform::BOOL)->set(true); // this line got screwy.
lpn->setStateSet(NewSS);
Now given that, I am confused.
Seems like some plain vanilla code.
Is there some chance that "Override" is being set on a higher node?
Can you override uniform values?
What about if Texture2D is overridden off not as a uniform?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Monteleone, Nathan
Sent: Friday, March 28, 2008 10:22 AM
To: OpenSceneGraph Users
Subject: [osg-users] Uniforms and state sorting
My first try didn't seem to go through so I'm sending it again. My
apologies if this turns out to be a double post.
I'm having a problem where I want to pass a particular Uniform to a
fragment shader for all the point lights in my model. Basically I read
the model using the .flt loader, find all the LightPointNodes using a
visitor, and then:
(for each light point node "lpn")
lpn->setPointSprite(); // Because GL_POINT_SMOOTH w/shaders freaks out
on ATI
// Do some stuff to set up the point sprite texture
osg::StateSet* NewSS = new osg::StateSet;
NewSS->setName("LightPoint state set");
NewSS->getOrCreateUniform("Texture2DEnabled",
NewSS->osg::Uniform::BOOL)->set(true);
lpn->setStateSet(NewSS);
I'm not running any optimizers after doing this. I know I eventually
should to get rid of all the redundant state sets but I'm trying to
debug it right now...
But the uniform value that shows up in my shader is inconsistent.
Sometimes it'll be applied as true, sometimes as false, and it's
dependent on what other things are in the scene. Looks like a lazy
state error basically.
Anything jump out that I might be doing wrong? Do uniforms have some
"override" feature similar to other state attributes that I'm not
accounting for?
I am using an old version -- OSG 1.2. We're planning to upgrade soon
but it's a big app so we have to be cautious about that sort of thing :(
Thanks,
Nathan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgProducer Visual Chooser. - visual ID's
Back to 1.2, apologies. I am using the osgProducer, and want to be able to tell the visual ID of the created visual. There is a Producer::CameraConfig class, that lets me set: cameraconfig->addVisualAttribute(Producer::VisualChooser::DepthSize, 32); Then pass cameraconfig in to the osgViewer constructor. How can I tell if it actually listened to me or not? I have a list of valid visual ID's, but don't know how to check to see if it worked or not. Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Heap and Out Of Memory error on XP
H... Where to start? 1. Windows will hog quite a bit of memory to begin with, so you don't really have 3G available. My 3G machine shows 2.5G available after windows loads. 2. Even if you did, the per process limit for 32 bit is 2G. 3. I think windows even restricts that a bit further. 4. MFC is a bloated beast that will take some of that 2G. Anyway, you would be better off posting some code that did the following. 1. allocate a huge amount of space (500MB) 2. Attach it as vertex data to some OSG nodes. 3. Point out where it blows up. (if that's all it takes). You could modify osgviewer to do this. Otherwise, there are lots of different things that could be wrong. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Northcott Sent: Wednesday, January 30, 2008 4:35 AM To: OpenSceneGraph Users Subject: [osg-users] Heap and Out Of Memory error on XP I am getting Out Of Memory errors from OSG. I know why, kind of, but am surprised this is not handled more elegantly. Can anyone shed some light for me.. I have a very large data-set which requires being in memory at all times. Unprocessed it is around 750MB++. It is typically 500MB after I have loaded it and formatted it for efficiency of storage. I load it in chunks (rather than load it as a 750MB++ raw data file) and then process it to the 'working' 500MB chunk. But at the end of all this I still need to have the resultant 500MB structure sitting in memory. On a PC with 3GB of RAM I am able to do this, however, when I then try to initialize a scene graph based on about 1 or 2% of this data I get an Out Of Memory error from OSG. This is running in MFC on XP. I could, I suppose, write a wrapper class to access this 500MB chunk of data, and put it into smaller 50MB chunks, for example. But I don't see why I should have to when I have a 3GB machine for this task! I am also drawing this in real time from the database so any extra misdirection really does slow things down, and I am already doing lots of indexing and so on to speed access. A wrapper would simply undo all of that hard work on optimization. I am attempting to make some kind of wrapper as a fallback, but am still a bit confused as to why OSG is throwing an out of memory problem when there is quite a lot of free RAM sitting around on a quite often recently re-booted PC! Is there any way to get more info on the Out Of Memory error, and any way to work around it.. Windows gurus? Thanks. Stephen. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg 1.2 and rgba files.
Hi all. We upgraded from 1.0 to 1.2 . One of the changes that we noticed was that the rgba reader now doesn't handle transparency correctly anymore. Anyone else notice this? I am going to start looking myself on the website, but don't know the method to research this problem. Is there a way I can look at file revision history, if I can't connect under SVN? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stable version without the osgProducer changes.
Hi all, I am running version 1.0 now, and would like to update, but for various reasons, can't go all the way up to the head this late in my project. I'd like to update to a known stable version before the osgProducer change, or any other major API change. Any suggestions? I was thinking 1.2 Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Correcting for horizon bend when using multiple displays.
Sorry for the confusing title. I have a flight simulation that uses multiple monitors to mimick different airplane windows. For instance, left-front, right-front, left-side, etc. There is an annoying phenomenon that occurs particularly when pitching. If you are in the air, and level, you can see the horizon, and everything is good. If you pitch towards the ground, the horizon rises towards the top of the monitor. The problem is, that it bends from monitor to monitor. >From left-front to right-front, the horizon (and of course the rest of the scene) will bend in the form of an upside-down "V" I think that this is due to having two flat projected images pitch on different pivot points, creating the bend at the top. A good approximation to this effect is to hold your hands in front of you, palms facing you, thumbs on top, with the middle fingers touching. Now bend your wrists to pitch-up. You get an inverted "V". That mirrors the effect. I need something similar to not pitching my wrists, but moving my arms up so that the entire image moves without bends. I don't have the simulation here, or I'd attach pictures. I think what I have described is a single pivot point, instead of multiple, but I am not sure. Any suggestions for how to implement this, or what is involved in doing so? Is this simply a projection matrix issue, or an eyepoint problem? Thanks for any help, and sorry again for the long explanation. If there is a name for this effect, I'd like to know it. Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixing GL
Never mind, just read stephen's post Haven't tried yet though. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Wednesday, November 21, 2007 10:33 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Mixing GL yup. I might be missing something though. Don;'t know intelligent way to do other than to push each mode,attr, then pop them. Is there an overall one? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, November 20, 2007 5:50 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Mixing GL Have you tried pushing and popping around the call to your OpenGL code? -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Tuesday, November 20, 2007 3:29 PM To: OpenSceneGraph Users Subject: [osg-users] Mixing GL Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixing GL
yup. I might be missing something though. Don;'t know intelligent way to do other than to push each mode,attr, then pop them. Is there an overall one? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, November 20, 2007 5:50 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Mixing GL Have you tried pushing and popping around the call to your OpenGL code? -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Tuesday, November 20, 2007 3:29 PM To: OpenSceneGraph Users Subject: [osg-users] Mixing GL Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mixing GL
Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] That why I think the osg math is really wrong
One possibility might be to do an optional build that issue a compile error when ever a Vec * Quat is found so users can spot where they occur, or perhaps move the implementation into the .cpp and the emit an optional warning when this method is invoked. That would be excellent. I am fairly certain we are using this to do some coordinate system conversions. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, November 13, 2007 10:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] That why I think the osg math is really wrong On Nov 13, 2007 4:07 PM, Dorosky, Christopher G <[EMAIL PROTECTED]> wrote: > Just to clarify here, are we changing the way things work, or simply > adding another operation? > If we change the way things are working, hopefully it will be > reflected strongly in the release notes. We are talking about changing the Vec * Quat methods to fix them. These methods aren't something that is widely used so I'd expect not much in the way of user relies upon these methods nor there currently broken implementation. There is of course a danger of breaking user code that relies on it working the wrong way round. One possibility might be to do an optional build that issue a compile error when ever a Vec * Quat is found so users can spot where they occur, or perhaps move the implementation into the .cpp and the emit an optional warning when this method is invoked. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] That why I think the osg math is really wrong
Just to clarify here, are we changing the way things work, or simply adding another operation? If we change the way things are working, hopefully it will be reflected strongly in the release notes. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmidt, Richard, SDGE1 Sent: Tuesday, November 13, 2007 9:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] That why I think the osg math is really wrong Yep, I gonna fix it and send it in asap. Richard On Nov 13, 2007 2:24 PM, Schmidt, Richard, SDGE1 <[EMAIL PROTECTED]> wrote: > This would require a huge a amount of change, however it's compilant to > glsl than... (is it?!) While it would be the nice to have the same convention as GLSL, the OSG's decision to use post multiplication long way pre-dates GLSL. The OSG follows how OpenGL actually stores matrices, rather than what is documented and adopted for GLSL. Changing to fit GLSL conventions would require refactoring a lot of OSG and critically user code, and in a way that would be awkward to catch automatically catch possible bugs that it'd introduce. If we were still in pre beta days it'd be easier, but right now we have a lot less flexibility, the 2.x has to stick with the current convention. Fixing the Vec Quat bug is important to do, I'll currently focused on other work right now so can't tackle this right away. Any chance you fix the offending methods and send them into osg-users? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] "how got here?"
We are getting this too, and it prints, exactly once.
Vertex program causes it, but we haven't narrowed anything down yet.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Weiblen
Sent: Monday, November 12, 2007 9:03 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] "how got here?"
no, it was because it wasn't clear to me when/if such a constructor
would be executed.
Did you actually execute that codepath during runtime, or did you find
it during a code review? ie How did you get there?
-- mew
On Nov 11, 2007 3:40 PM, Alan Purvis <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> From osg::Program:
>
> Program::Program(const Program& rhs, const osg::CopyOp& copyop):
> osg::StateAttribute(rhs, copyop)
> {
> osg::notify(osg::FATAL) << "how got here?" << std::endl; }
>
> Is this just a stub because somebody forgot to come back and finish it
> or for some technical reason?
>
> Thanks in advance,
> Alan
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> org
>
>
--
Mike Weiblen -- Austin Texas USA -- http://mew.cx/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVidia's GLExpert program.
I'm running version 1.2 which doesn't seem to have those. The nvidia driver required to make use of GLExpert keeps re-acquainting me with the Blue Screen of Death, so I'm gonna back off of this for awhile. Thanks, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, October 29, 2007 10:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] NVidia's GLExpert program. Hi Chris, The OSG does nothing special w.r.t OpenGL setup, perhaps its something related to the windowing setup that GLExport doesn't check for. Could you try examples like the osgviewerGLUT and osgviewerSDL to see if they work OK. Robert. On 10/29/07, Dorosky, Christopher G <[EMAIL PROTECTED]> wrote: > I downloaded the GLExpert program from NVidia's website. > It seems to give me output for "regular" applications that I know are > using GL. > > Anything with OSG (osgviewer cow.osg) doesn't produce output. > > Has anybody tried this and figured out a way around it? > I'm guessing it's due to something grabbing the output handler. > > > Chris > ___ > 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NVidia's GLExpert program.
I downloaded the GLExpert program from NVidia's website. It seems to give me output for "regular" applications that I know are using GL. Anything with OSG (osgviewer cow.osg) doesn't produce output. Has anybody tried this and figured out a way around it? I'm guessing it's due to something grabbing the output handler. Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FW: Matrix Manipulator with screwy coord-system.
Solved. An answer, for the record, is to use a coordinate frame callback attached to the matrix manipulator. The return value contains your calculated side, front, up. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Monday, August 13, 2007 1:10 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] FW: Matrix Manipulator with screwy coord-system. -- Note -- Sorry if this is duplicate, been having trouble with mailing list. Greetings, I have a screwy world coordinate system that the standard manipulators work OK with, but I'd like to fix it. In between the CoordinateSystem Nodes, and the coordsystem callbacks, it seems like there is a way to give the manipulator a better idea of the front,side,up vectors. Can anyone recommend a good way to do this, or a good example? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FW: Matrix Manipulator with screwy coord-system.
-- Note -- Sorry if this is duplicate, been having trouble with mailing list. Greetings, I have a screwy world coordinate system that the standard manipulators work OK with, but I'd like to fix it. In between the CoordinateSystem Nodes, and the coordsystem callbacks, it seems like there is a way to give the manipulator a better idea of the front,side,up vectors. Can anyone recommend a good way to do this, or a good example? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Matrix Manipulator with screwy coord-system.
Greetings, I have a screwy world coordinate system that the standard manipulators work OK with, but I'd like to fix it. In between the CoordinateSystem Nodes, and the coordsystem callbacks, it seems like there is a way to give the manipulator a better idea of the front,side,up vectors. Can anyone recommend a good way to do this, or a good example? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD's, addChild overload bad?
1.2 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, July 30, 2007 5:17 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] LOD's, addChild overload bad? HI Chris, Both routes should work, so what you are seeing looks to be a bug. Which version of the OSG are you using? Robert. On 7/29/07, Dorosky, Christopher G <[EMAIL PROTECTED]> wrote: > > Hello. > > I'm having unexpected trouble using LOD's. > > osg::LOD *LOD = new osg::LOD; > LOD->addChild(modelA); > LOD->addChild(modelB); > LOD->setRange(0, 0.0, 100.0); > LOD->setRange(100.0, 1.0); > scene->setSceneData(LOD); > > This works nicely. I modified osgviewer to do it. > > Now, change that to using the all-in-one, and I get a blank screen. > > osg::LOD *LOD = new osg::LOD; > LOD->addChild(modelA, 0.0, 100.0); > LOD->addChild(modelB, 100.0, 1000.0); > > scene->setSceneData(LOD); > > This shows a nice blank screen. > > Is it broke, or did I misuse the overload, or screwup in another way > entirely? > > Chris > ___ > 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LOD's, addChild overload bad?
Hello. I'm having unexpected trouble using LOD's. osg::LOD *LOD = new osg::LOD; LOD->addChild(modelA); LOD->addChild(modelB); LOD->setRange(0, 0.0, 100.0); LOD->setRange(100.0, 1.0); scene->setSceneData(LOD); This works nicely. I modified osgviewer to do it. Now, change that to using the all-in-one, and I get a blank screen. osg::LOD *LOD = new osg::LOD; LOD->addChild(modelA, 0.0, 100.0); LOD->addChild(modelB, 100.0, 1000.0); scene->setSceneData(LOD); This shows a nice blank screen. Is it broke, or did I misuse the overload, or screwup in another way entirely? Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Making a matrix from 2 texgens.
It was this and a transpose issue. Thanks for the help Paul! BTW, is everybody else getting longer than normal delay times when posting? It used to be a few minutes. 2 posts ago, it took 12+ hours to make the round trip. Chris -Original Message- From: Dorosky, Christopher G Sent: Thursday, July 26, 2007 10:11 AM To: 'osg-users@lists.openscenegraph.org' Subject: RE: [osg-users] Making a matrix from 2 texgens. I think first mistake is the R row. > osg::Matrix mat(a,b,c,d, > e,f,g,h, > 0.0,0.0,0.0,0.0, // changed 3rd column from 1 to 0 > 0.0,0.0,0.0,1.0); However, this is now ordered as: S T R Q Which is funky. I'm playing with different orders now. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, July 26, 2007 7:46 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Making a matrix from 2 texgens. Could be a column- versus row-major issue, or a pre- versus post-multiply issue. But, conceptually, what you're attempting should work. -Paul > I'm trying to created an osg::Matrix that has the equivalent > representation of what a texgen would make. > > For instance, the texgen has: > texgen->setPlane(osg::TexGen::S, osg::plane(a,b,c,d)); > texgen->setPlane(osg::TexGen::T, osg::plane(e,f,g,h)); > > (R&Q) are defaults. > > > When this is used with a vertex, I get generated texcoords. > > I would create a matrix that I could use to calculate these results. > > osg::Matrix mat(a,b,c,d, > e,f,g,h, > 0.0,0.0,1.0,0.0, > 0.0,0.0,0.0,1.0); > > > Multiplying this with the vertex coord doesn't seem to give me the > right answers. > > Is this the right way to set up the equivalent matrix? > > Thanks, > > Chris > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Making a matrix from 2 texgens.
I think first mistake is the R row. > osg::Matrix mat(a,b,c,d, > e,f,g,h, > 0.0,0.0,0.0,0.0, // changed 3rd column from 1 to 0 > 0.0,0.0,0.0,1.0); However, this is now ordered as: S T R Q Which is funky. I'm playing with different orders now. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, July 26, 2007 7:46 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Making a matrix from 2 texgens. Could be a column- versus row-major issue, or a pre- versus post-multiply issue. But, conceptually, what you're attempting should work. -Paul > I'm trying to created an osg::Matrix that has the equivalent > representation of what a texgen would make. > > For instance, the texgen has: > texgen->setPlane(osg::TexGen::S, osg::plane(a,b,c,d)); > texgen->setPlane(osg::TexGen::T, osg::plane(e,f,g,h)); > > (R&Q) are defaults. > > > When this is used with a vertex, I get generated texcoords. > > I would create a matrix that I could use to calculate these results. > > osg::Matrix mat(a,b,c,d, > e,f,g,h, > 0.0,0.0,1.0,0.0, > 0.0,0.0,0.0,1.0); > > > Multiplying this with the vertex coord doesn't seem to give me the > right answers. > > Is this the right way to set up the equivalent matrix? > > Thanks, > > Chris > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Making a matrix from 2 texgens.
Hi, I'm trying to created an osg::Matrix that has the equivalent representation of what a texgen would make. For instance, the texgen has: texgen->setPlane(osg::TexGen::S, osg::plane(a,b,c,d)); texgen->setPlane(osg::TexGen::T, osg::plane(e,f,g,h)); (R&Q) are defaults. When this is used with a vertex, I get generated texcoords. I would create a matrix that I could use to calculate these results. osg::Matrix mat(a,b,c,d, e,f,g,h, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0); Multiplying this with the vertex coord doesn't seem to give me the right answers. Is this the right way to set up the equivalent matrix? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
