Re: [osg-users] Newbie question regarding deprecated methods
Paul Martz wrote: Sounds really flexible I does not only sound that way. It really is. Typically indexing into multiple arrays maps well to how file formats store their data. Unfortunately this does not map efficiently to OpenGL. As a workaround you can keep using the set**Indices methods and use an internal geometry that has expanded the arrays and uses a single set of indices for the vertices. I added an option to the Optimizer a couple of weeks ago, that does this for you. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10489#10489 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] OSGDEM LOD Elevation Corruption
Hi Mark, I believe the GDAL drivers are broken in Ubuntu 8.10, uninstall it and then pull down the GDAL as source and compile/install it. Robert. On Tue, Apr 21, 2009 at 1:11 AM, Mark myan...@rscusa.com wrote: Hi, OSGDEM databases always finish with the highest detailed LODs corrupted. What can I do to fix this problem? View from above in between two LODs- [Image: http://img25.imageshack.us/img25/1566/osgdemlodcorruption1.jpg ] (http://img25.imageshack.us/my.php?image=osgdemlodcorruption1.jpg) View from an angle- [Image: http://img25.imageshack.us/img25/9618/osgdemlodcorruption2.jpg ] (http://img25.imageshack.us/my.php?image=osgdemlodcorruption2.jpg) The system used- OSG 2.8.0 (2.2 - 2.8 have the same results) VPB 0.9.10 GDAL 1.60 Quad Core Intel 4 GB RAM nVidia 8800 GTX Ubuntu 8.10 64-bit Thank you. -Mark -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10484#10484 ___ 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] Using vec3d for CullStack eye point
On Tue, Apr 21, 2009 at 2:40 AM, Ravi Mathur ravid...@mail.utexas.edu wrote: I would think that anyone who intentionally requests double precision matrices is doing so out of need, and would probably be willing to accept the inevitable performance hit. You've got things the wrong way round, the OSG builds double matrices by default, so there has to be an intentional request for float precision. Changing the eye point to double probably won't cause performance problems, but one has to be wary of this. As for double precision of the eye point, you're the first person to request this, and there are plenty of others handling geocentric databases, so needing double matrices isn't necessarily mean that ones requires a double eye precision. Having doubles is no bad thing though, as long as there isn't a performance hit nor awkwardness in integration with other parts of the OSG. Is there anything I should do to get this change started? I'm sure you are busy with other issues so I can try it out on my computer tomorrow to see if there are any unexpected hangups. Dive in a code up a solution and see if there are any problems. If things pan out OK submit your changes to osg-submisssions. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to recreate GraphicsContext?
HI Ran? Jiao? Could you sign with your first name so we know how to address you correctly. What you are doing looks correct so I would have expected it to work. Does the osgviewerMFC work for you? As for using MFC, if you're doing a new app I really wouldn't recommend using MFC, there are far better free alternatives out there such as Qt and it isn't tied to Windows. Robert. On Tue, Apr 21, 2009 at 4:09 AM, Ran Jiao ranj...@gmail.com wrote: Hi, I am working to make a osg scene editor with MFC. I just followed the example of osgViewerMFC and create a GraphicsContext for every MFC document. For the 1st document everything runs smoothly, but when I tried to create another GraphicsContext, the program throws a exception. So, how can I create a GraphicsContext again correctly? This is how I create a GraphicsContext in MFC, just the same as the sample in the OSG SDK. Code: osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd); // Setup the traits parameters traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; //== stuck here mGC = osg::GraphicsContext::createGraphicsContext(traits.get()); Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10488#10488 ___ 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] Newbie question regarding deprecated methods
Hi Anton, Please ignore color indices etc as they are deprecated as they force the OSG to use OpenGL slow paths that make rendering disproportionately expensive. Indices just exist for backwards compatibility with previous scene graphs that aren't even available any more... We need to update tutorials such as these to remove all the deprecated elements from them. The tutorials were developed by members of the community of a number of years so it's a little awkward to keep track of them. Robert. On Mon, Apr 20, 2009 at 11:36 PM, Anton Lauridsen an...@lauridsen.info wrote: Hi, I'm trying to learn to use OSG using the tutorials on the wiki, starting with this: http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/BasicGeometry, during the coding, I learned that setColorIndices has been deprecated, unfortunately I'm having difficulties figuring out what the preferred replacements are. I tried doing some searches, using the usual keywords, deprecated, setColorIndices etc, (hey I'm a newbie, I probably haven't got the terminology right) I haven't had much luck with finding replacements. Is there somewhere I can go and get some idea about what to use instead? or is there a more up to date tutorial? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10482#10482 ___ 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] Top 10 OSG Debugging Tips
Paul, I moderated the original mailing list post on the OSG forum to show your reformatted version of the tips. And I added a few links. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10495#10495 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Point to ScreenSpace Coordinates
Thank you for those two answers. I forgot to say the point is in world coordinates so the first transformation should be obsolete for me. Then I did the following very simple where POSITION is the vector of the point and ssc is the result. Code: osg::Camera* cam = this-viewer-getCamera(); osg::Matrix viewMatrix = cam-getViewMatrix(); osg::Matrix projectionMatrix = cam-getProjectionMatrix(); osg::Matrix windowMatrix = cam-getViewport()-computeWindowMatrix(); osg::Matrix cameraMatrix = viewMatrix * projectionMatrix * windowMatrix; osg::Vec3 ssc = POSITION*cameraMatrix; pos-setPosition(osg::Vec3(ssc.x(),ssc.y(),0)); As you can see I give the the result to PositionAttitudeTransform. This PAT is attached to a slave cam with ABSOLUTE_RF This way I can have HUD (2D) elements following nodes in 3d. Problem: The accuracy is not very well. Moving th camera my HUD element is never exactly where it i supposed to be but just somwhere around the supposed area. Could that be float and double problems? If so: How can I make OSG do eighter everything or just the above calculation in double) Or do you have another idea why this problem appears? Greetings Hagen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10496#10496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Jerky display?
Hi Akilan,
Please carify now there's an expression I could through right back at your.
What hardware/OS are you using?
What type of viewer set up do you have?
What OSG version?
How did you build the databases?
Do you have sync enabled?
What exactly do you mean by Jerky, are we talking dropped frames?
Basically nobody has a chance to guess at what might be wrong until
you provide some more info about your particular setup.
Robert.
On Tue, Apr 21, 2009 at 9:35 AM, Akilan akilan.thangam...@gmail.com wrote:
Hi,
I created a simple scene graph as shown below,
osg::ref_ptrosg::Group grp=new osg::Group;
for(i=1;i=n_models;i++)
{
osg::ref_ptr osg:::PagedLOD plod=new osg::PagedLOD;
plod-setFile(argv[i]);
plod-setRangeMode(...DISTANCE FROM EYE...);
plod-setRange(0,50.f,100.f);
grp-addChild(plod.get());
}
In this same fashion I am adding more number of terrain models(on virtual
earth) lying close to each other. The problem here is that If I zoom down to
the range , I am getting jerky display even though I have used pagedLOD.
Please clarify me.
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10494#10494
___
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] osgForest
I just tried osgForest and I don't appear to be seeing any trees on the shader implementation. I'm using an 8800 GTS 512 on vista with the 178.13 driver set. Anybody else have problems with it? Not a big issue just thought I'd point it out. Cheers. Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgForest
Hi Kim, As a point of reference all the osgforest modes work fine for me under Kubuntu with either ATI or NVidia graphics. Do you see any OpenGL errors reported? My guess is that it's simply an OpenGL driver error. Robert. On Tue, Apr 21, 2009 at 11:03 AM, Kim C Bale k.b...@hull.ac.uk wrote: I just tried osgForest and I don’t appear to be seeing any trees on the shader implementation. I’m using an 8800 GTS 512 on vista with the 178.13 driver set. Anybody else have problems with it? Not a big issue just thought I’d point it out. Cheers. Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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 with VS2008
Hi, I'm very new to OSG. I need the easy steps to install OSG in my windows system. And i want to build it with Visual Studio 2008 I've downloaded the OpenSceneGraph-2.8.1-rc2.zip from the following link http://www.openscenegraph.org/projects/osg/wiki/Downloads. ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10506#10506 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
Using melted chocolate as cake decoration? I'm making a cake this weekend and what I'm planning on doing is melting white chocolate, using food coloring (I'm thinking red) and then using a pastry bag to decorate and/or write on the cake. I've never done this before so I'm wondering...will the heat of the melted chocolate cause the frosting to get melty as well? Has anyone done this before? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10499#10499 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG with VS2008
http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio On Tue, Apr 21, 2009 at 11:53 AM, Rani ranimu...@gmail.com wrote: Hi, I'm very new to OSG. I need the easy steps to install OSG in my windows system. And i want to build it with Visual Studio 2008 I've downloaded the OpenSceneGraph-2.8.1-rc2.zip from the following link http://www.openscenegraph.org/projects/osg/wiki/Downloads. ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10506#10506 ___ 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] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Hi, I think I have understood the osgviewerQT sample. This creates a QGLWidget overloads its paintGL() function and calls into osgviewer::frame() to let OSG do the rendering and all is good - i.e. we see the OSG scene displayed inside a window managed by QT. I am now trying to do something more advanced and let QT render semi-transparent widgets on top of the openGL scene. In the relevant QT examples this is done by assigning a QGraphicsScene to the QGLWidget instead of overloading the QGLWidget's paintGL() function. The relevant QT examples are called boxes (in the demos folder of QT) as well as openglcanvas sample ( see the article http://doc.trolltech.com/qq/qq26-openglcanvas.html ) The QGraphicsScene has a drawBackground() function where we are inside an openGL context created and maintained by QT. Trolltech (Nokia) say that you can do your own OpenGL 3D rendering here, but you're supposed to revert all changes you make to the OpenGL state when you're done rendering, so that QT can draw its widgets on top successfully (also using OpenGL, mind you). Apparently simply calling osgviewer::frame() here is doomed to failure as the openGL states of OSG and those maintained of QT will clash seriously. Unfortunately my experience with OSG's state management is poor. How would I achieve to save all OpenGL state, then make OSG set up its needed OpenGL state from scratch, render its frame, and then restore QT's previous OpenGL state? Would it be easier to let OSG render everything to texture using a separate OpenGL context and just render this texture inside drawBackground()? Any help with this will be greatly appreciated. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Creating Stairs, better way?
Hi guys, we had an assignment in school, where we should create cubes with the vertexArray-push_back // faceArray-push_back(0) methods. As i have now a more complex object, i would like to ask, if you know any other method to create stairs like the one in my screenshot in a more easy and effective way. If not i would write a bunch of lines of codes ^^ thank you! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10510#10510 attachment: modelling_stairs.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Artefacts in first version of SSAO ...
Hi all
May some one can suppport me in working out the artefacts in this
implementation (GLSL)
/regards
adrian
--
Adrian Egli
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osg/Uniform
#include osgText/Text
#include osg/ShapeDrawable
#include osg/Geometry
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/BlendFunc
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include iostream
#include osgFX/Effect
#include osgFX/Technique
#include osgFX/Registry
#include osg/TexGen
#include osg/Texture2D
#include osg/PolygonOffset
#include osgDB/WriteFile
bool global_debug_on = false;
struct WriteCameraPostDrawCallback : public osg::Camera::DrawCallback
{
WriteCameraPostDrawCallback(osg::Image* image,std::string filename,
bool write):
_image(image),
_filename(filename)
{
char* write_file = getenv(DEBUG);
global_debug_on = (write_file!=NULL) || write;
}
virtual void operator () (const osg::Camera /*camera*/) const
{
_image-dirty();
if ( global_debug_on ) {
std::cout write _filename std::endl;
osgDB::writeImageFile(*(_image.get()),_filename);
}
}
osg::ref_ptrosg::Image _image;
std::string _filename;
};
namespace osgFX {
class SSAO : public Effect {
public:
SSAO() {};
SSAO(osg::Group*);
SSAO(const SSAO copy, const osg::CopyOp copyop =
osg::CopyOp::SHALLOW_COPY);
META_Effect(osgFX, SSAO,
Screen Space Ambient Occlusion,
SSAO : test implementation,
Adrian Egli);
protected:
virtual ~SSAO() {}
SSAO operator=(const SSAO) { return *this; }
bool define_techniques();
osg::ref_ptrosg::Group _root;
};
}
using namespace osgFX;
namespace
{
osg::Node* createBase(osg::Texture2D* texture ,osg::Texture2D*
texture2=NULL )
{
osg::ref_ptrosg::Geode geode = new osg::Geode;
// set up the texture of the base.
osg::ref_ptrosg::StateSet stateset = new osg::StateSet();
stateset-setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON);
if
(texture2)stateset-setTextureAttributeAndModes(1,texture2,osg::StateAttribute::ON);
geode-setStateSet( stateset.get() );
osg::ref_ptrosg::HeightField grid = new osg::HeightField;
grid-allocate(2,2);
grid-setOrigin(osg::Vec3(0.0,0.0,0.0));
grid-setXInterval(1.0);
grid-setYInterval(1.0);
grid-setHeight(0,0,-1.0);
grid-setHeight(0,1,-1.0);
grid-setHeight(1,1,-1.0);
grid-setHeight(1,0,-1.0);
geode-addDrawable(new osg::ShapeDrawable(grid.get()));
osg::Group* group = new osg::Group;
group-addChild(geode.get());
return group;
}
Registry::Proxy proxy(new SSAO);
class DefaultTechnique: public Technique {
public:
DefaultTechnique(osg::Group* scene,osg::Group* ssaoFX) :
Technique(),
_scene(scene)
{
// depth
// texture resolution
_RTTInfoTangentDepth._resolution_x = 512;
_RTTInfoTangentDepth._resolution_y = 512;
// texture
_RTTInfoTangentDepth._texture = new osg::Texture2D;
_RTTInfoTangentDepth._texture-setTextureSize(_RTTInfoTangentDepth._resolution_x,
_RTTInfoTangentDepth._resolution_y);
_RTTInfoTangentDepth._texture-setInternalFormat(GL_RGBA);
_RTTInfoTangentDepth._texture-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::NEAREST);
Re: [osg-users] OSG with VS2008
Hi, http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio Regards, Vincent. 2009/4/21 Rani ranimu...@gmail.com Hi, I'm very new to OSG. I need the easy steps to install OSG in my windows system. And i want to build it with Visual Studio 2008 I've downloaded the OpenSceneGraph-2.8.1-rc2.zip from the following link http://www.openscenegraph.org/projects/osg/wiki/Downloads. ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10506#10506 ___ 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] osgForest
No errors reported. As you say it's probably another driver bug. Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 21 April 2009 11:19 To: OpenSceneGraph Users Subject: Re: [osg-users] osgForest Hi Kim, As a point of reference all the osgforest modes work fine for me under Kubuntu with either ATI or NVidia graphics. Do you see any OpenGL errors reported? My guess is that it's simply an OpenGL driver error. Robert. On Tue, Apr 21, 2009 at 11:03 AM, Kim C Bale k.b...@hull.ac.uk wrote: I just tried osgForest and I don't appear to be seeing any trees on the shader implementation. I'm using an 8800 GTS 512 on vista with the 178.13 driver set. Anybody else have problems with it? Not a big issue just thought I'd point it out. Cheers. Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating Stairs, better way?
HI Yafes, Do it in the similar way to what you did with the cubes, simply create the vertex data and use a DrawElements quad strip. See osggeometry example. It'd take you longer to type your email and wait for replies than it would to write this... Robert. On Tue, Apr 21, 2009 at 12:22 PM, Yafes ysahin.mmt-b2...@fh-salzburg.ac.at wrote: Hi guys, we had an assignment in school, where we should create cubes with the vertexArray-push_back // faceArray-push_back(0) methods. As i have now a more complex object, i would like to ask, if you know any other method to create stairs like the one in my screenshot in a more easy and effective way. If not i would write a bunch of lines of codes ^^ thank you! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10510#10510 ___ 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] Quat * Vec3 proposals - request for comments/help
Hi all,
it's been known for a while [1] that there are inconsistencies with the
way OSG handles Quat * Vec3. In short: Quat * Vec3 is written in code as
a post-multiply, but the result of the operation is as if a pre-multiply
was performed. The attached test app also shows the problem (more on it
later).
[1]
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/21003
and
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/33099
What doesn't work?
There are many examples that can be constructed of where a mathematical
expression usings quats and vectors would not provide the expected
results. See also [1]. The easiest one I could come up with is this:
((q1 * q2) * v) != (q1 * (q2 * v))
Why are there not more complaints?
I suppose most people do all the quat multiplications before they
multiply with the vector. Since OSG does not have a pre-multiply for
quat, the only option is then to post-multiply the resulting quat with
the vector.
What can be done?
As a first step I think we can add the pre-multiply to OSG. The attached
header does this. (To fix the post-multiply can be done later.)
What will break?
I think and hope nothing, since there was no pre-multiply that people
could have used. (Fixing the post-multiply would break current code.)
Why now?
The itch finally got annoying enough.
What about the post-multiply?
I think we should in some way let developers know that the post-multiply
they currently use will change in future and that they should switch
their multiply to the pre-version (which will behave the same as current
code). I think a compiler warning or error would help more than only
documentation. Something like a deprecated warning. I need help with
this though, I do not know how to generate a warning in a cross-platform
manner. Later we can then fix the post-multiply quat code.
Test app details:
The test app considers two rotations and a vector. It shows that for
Matrix and Vec3 interactions everything is consistent, e.g.
((m1 * m2) * v) == (m1 * (m2 * v))
and
(v * (m1 * m2)) == ((v * m1) * m2)
It then shows that Quat post-multiply does not behave as Matrix
post-multiply does and actually behaves more like Matrix pre-multiply
does. It also shows the inconsistency of various expressions.
We also know (from the osgunittest example) that
m1(q1) * m2(q2) == q1 * q2
so the internal quat * quat is consistent with the matrix multiply
order. It is only the quat * vec that is not.
Finally it shows that with the added pre-multiply (enable by making the
#if 0 a 1), the quat pre-mult behaves the same as the matrix pre-mult.
Comments welcome.
regards
jp
--
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.
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#ifndef OSG_QUAT
#define OSG_QUAT 1
#include osg/Export
#include osg/Vec3f
#include osg/Vec4f
#include osg/Vec3d
#include osg/Vec4d
namespace osg {
class Matrixf;
class Matrixd;
/** A quaternion class. It can be used to represent an orientation in 3D
space.*/
class OSG_EXPORT Quat
{
public:
typedef double value_type;
value_type _v[4];// a four-vector
inline Quat() { _v[0]=0.0; _v[1]=0.0; _v[2]=0.0; _v[3]=1.0; }
inline Quat( value_type x, value_type y, value_type z, value_type w )
{
_v[0]=x;
_v[1]=y;
_v[2]=z;
_v[3]=w;
}
inline Quat( const Vec4f v )
{
_v[0]=v.x();
_v[1]=v.y();
_v[2]=v.z();
_v[3]=v.w();
}
inline Quat( const Vec4d v )
{
_v[0]=v.x();
_v[1]=v.y();
_v[2]=v.z();
_v[3]=v.w();
}
inline Quat( value_type angle, const Vec3f axis)
{
makeRotate(angle,axis);
}
inline Quat( value_type angle, const Vec3d axis)
{
makeRotate(angle,axis);
}
inline Quat( value_type angle1, const Vec3f axis1,
value_type angle2,
[osg-users] Projective texture mapping with occluders/ visibility computation
Hi, I'd like to develop a piece of code realizing projective texture mapping only on visible primitives from cameras in the scene. For now, I'm trying to understand how to realize a correct classical one, thus I'm not really working on it, but soon. Have you any idea on how I could do that PTM restricted to visible primitives? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10516#10516 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Success - I found a solution to this. The solution was to store and restore the matrix stack as well as the openGL state, and to call getState()-reset() on the osgViewer::GraphicsWindowEmbedded object. I now have an OSG Viewer running on QT 4.5 with overlaid semi-transparent Qt controls and widgets. I am planning to put together an osgViewerQTAdvanced sample with a few interactive features (buttons to click on, etc). This code will be submitted to osg-submissions when done. I am also planning to use this method in an engineering product in my day job. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Is polygon on screen
Hi, Sorry for the question, I searched the forum and wasn't able to find a solution. I need to know if certain polygon in my node are currently on screen or not. I'm using http://groups.google.com/group/osg-users/browse_thread/thread/456350371e15798c/6b682511095a9162?hl=enlnk=gstq=NodeVisito to have access to the polygons. mangu liok. Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10518#10518 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is polygon on screen
Hi Mangu, have a look at the osgUtil::PolytopeIntersector. See osgkeyboardmouse example has a code path that uses the PolytopeIntersector. The key is to use the view frustum to define the polytope. On Tue, Apr 21, 2009 at 2:46 PM, Mangu Liok mangul...@yahoo.com wrote: Hi, Sorry for the question, I searched the forum and wasn't able to find a solution. I need to know if certain polygon in my node are currently on screen or not. I'm using http://groups.google.com/group/osg-users/browse_thread/thread/456350371e15798c/6b682511095a9162?hl=enlnk=gstq=NodeVisito to have access to the polygons. mangu liok. Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10518#10518 ___ 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] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Hello Christian, The solution was to store and restore the matrix stack as well as the openGL state, and to call getState()-reset() on the osgViewer::GraphicsWindowEmbedded object. I now have an OSG Viewer running on QT 4.5 with overlaid semi-transparent Qt controls and widgets. I am planning to put together an osgViewerQTAdvanced sample with a few interactive features (buttons to click on, etc). This code will be submitted to osg-submissions when done. I would suggest using a different name than osgViewerQTAdvanced, because the fact that you're using GraphicsWindowEmbedded tells me that it's not really that advanced, just eye candy... You're missing out on OSG's multithreading capabilities by using GraphicsWindowEmbedded. Then again, doing what you want using something *other* than GraphicsWindowEmbedded would be difficult if not impossible, because OSG has its own graphics threads that decide when they render, so your overlaid semi-transparent Qt widgets would probably just get rendered over at any time. But if you can find a way to do it, I would be very interested in seeing it! In any case, it's an interesting development, thanks for sharing! 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
Re: [osg-users] Is polygon on screen
been waiting for that. I'm on it. Thanks for the tip. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10520#10520 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamic Modification..
kool robert, thx for the correction. I just pulled that code from an example I found. It works but I never understood the details - I'm a newbie too. So all the help I can get, I'll take it! :) Thx again. Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10523#10523 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
As in your case, we also have high resolution insets which exhibit this problem, but our applications are centered around a continuous render update. Robert can correct me if I am wrong, but the new mechanism for controlling how nodes are paged in and out of memory is defaulted to ( I think ) 300 for the target maximum number of page lods. Because this value is set, removing of expired subgraphs will go down the path of removing capped paged lods instead of the expiry. To use the expiry system of old, make sure to call setTargetMaximumNumberOfPageLOD(0) on the database pager, and the expiry values you have set should kick in. We have tried increasing the target maximum, but we run a greater risk of consuming too much memory for a 32 bit application on Windows. Because of time restraints, I have not been able to follow-up on this problem. Sorry. Ryan H. Kawicki The Boeing Company Training Systems Services Software Engineer From: Evan Andersen [mailto:andersen.e...@gmail.com] Sent: Monday, April 13, 2009 10:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] DBPager continuously reloading tiles I tried the settings you suggested Jason, but I still get the same behavior. -Evan On Fri, Apr 10, 2009 at 5:57 PM, Jason Beverage jasonbever...@gmail.com wrote: Hi Evan, What happens if you set the expiry frame to something like 10 and the expiry time to DBL_MAX? I haven't tried running the DatabasePager without non-continuous rendering, so I'm not sure how well it works. Jason On Fri, Apr 10, 2009 at 5:20 PM, Evan Andersen andersen.e...@gmail.com wrote: Thanks for your response Robert. I just tried setting the expiry delay of the database pager to 10, 100, and 1000, but still have the same problem. I also tried increasing the expiry frames count to 60, but that didn't help either. -Evan On Fri, Apr 10, 2009 at 2:33 PM, Robert Osfield robert.osfi...@gmail.com wrote: On Fri, Apr 10, 2009 at 6:43 PM, Evan Andersen andersen.e...@gmail.com wrote: Sorry, I forgot to mention that. I'm using version 2.9.2 from the trunk. Thanks for the clarification. Changes in DatabasePager in 2.8 onwards should make it easier to do what you are doing. The DatabasePager and PagedLOD were still designed around continuous rendering though so you are running a bit off usual usage model so might need to tweak a few things. My guess is that the PageLOD are expiring their children as they haven't been traversed for a given amount of time. You can adjust the expiry delay via the DatabaePager API so have a browse. 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamic Modification..
Thanks a lot Allen and Robert. I'll try to modify my source code with our directions.. I explane you my true problem.I must change the solid color dinamically, during the execution. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10529#10529 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Skylark wrote: You're missing out on OSG's multithreading capabilities by using GraphicsWindowEmbedded. The QOSGWidget doesn't work with QT4.5 - it recursively redraws. You can make it work by using the (experimental) OpenGL rendering backend for QT - but that is very slow and causes a redraw of all QT widgets (even those not in the scene) everytime OSG does a redraw. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10530#10530 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamic Modification..
welcome. And I believe the only way to change anything in osg dynamically is
to do so with function calls that make those changes within the viewer frame
loop like so:
while(!viewer.done())
{
// YOUR CODE GOES HERE TO CHANGE A
// NODE IN THE OSG SCENE TREE
// BEFORE osg Updates the scene
//
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();
viewer.renderingTraversals();
}
I hope you get something to work. :)
Allen
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10531#10531
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamic Modification..
Hi Allen, welcome. And I believe the only way to change anything in osg dynamically is to do so with function calls that make those changes within the viewer frame loop like so: As Robert said earlier today, that's one way, the other is to create an update callback that you will attach to a node. Check the examples for (cough) examples of update callbacks. 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
Re: [osg-users] Dynamic Modification..
Thanks Allen..Now I try to do what you suggested me. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10533#10533 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry considered in near+far plane auto computation
Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. 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
Re: [osg-users] Dynamic Modification..
Thanks, I change the methods like you..So a last question..I change color for example for 3 seconds,after this time I must set the default solid color.. And during this time others sphere must brighten..Thanks a lot.. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10543#10543 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chuck, Although not an optimal solution, and probably more of a work-around to your question ... I use a skydome as well. In my case, I just create a sphere whose radius is that (or a little less than that) of the camera's far-field value, which I've set to be quite large (60,000-meters). This works for my use case. But again, it's not an optimal solution. I'd also be interested in a more optimal and scalable solution. I prefer letting OSG manage my near+far planes according to the geometry in my scene, that way I can have optimal depth precision in pretty much all situations. The problem here is that this particular node should not be part of those calculations (I've set it to always win the depth test and render first, so that transparency with it works and it will be drawn even if the far plane is closer than its surface). Thanks for your suggestion though. Anybody else have an idea? I just had a thought, perhaps I could make a ComputeBoundCallback that would return a very small bounding sphere, and disable culling on the skydome... I'll try that and report how it goes. J-S chuck -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 12:13 PM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. 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 -- __ 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
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
I would suggest using a different name than osgViewerQTAdvanced, because the fact that you're using GraphicsWindowEmbedded tells me that it's not really that advanced, just eye candy... You're missing out on OSG's multithreading capabilities by using GraphicsWindowEmbedded. Maybe I can even merge this into the existing osgviewerQT sample, using a command line option to trigger the new eyecandy. For my purpose I actually need everything to be single threaded, as the other CPU core is supposed to run some kind of time critical simulation (undisturbed). I have run into another problem. With my current approach the scene loses all lighting after the first frame has been drawn. All polygons appear in flat shading. I have currently no idea what is causing this. At first I was not noticing this because I rendered cow.osg which uses a metallic effect (environment maps?). But on other scenes the loss of lighting is apparent. I am currently investigating. If I can't find the cause, I will have to come back to this list. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada and ambient occlusion maps - only with diffuse texture?
Martin Scheffler wrote: Hi, I use 3ds Max render-to-texture to generate ambient occlusion maps. I then export the model to collada (with the nextgen plugin) and try to load them into osg. For some meshes I get this message: "Ambient occlusion map only supported when diffuse texture also specified", and the occlusion map is not loaded. Is that a collada thing or a shortcoming of the osg collada importer? Can I circumvent it by adding small one-color textures to the no-texture materials? Or is there a better way? Thank you. - Martin, It is the way the Collada importer is written. I admit that I thought I had good reason for making it work that way when I wrote that bit, however, now, I cannot remember what that reason was! It was something to do with mapping the Collada Common profile, which is supposed to represent a fixed a function pipeline, on to the OpenGL fixed function pipeline. This is what the code does when both the diffuse and ambient texture maps are present. // Set the ambient and diffuse colour white so that the incoming fragment colour ends up as a // lit white colour. I modulate both textures onto this to approximate the lighting equation. // Using a zero diffuse and then an ADD of the diffuse texture seems overlit to me. mat-setAmbient( osg::Material::FRONT_AND_BACK, osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f ) ); mat-setDiffuse( osg::Material::FRONT_AND_BACK, osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f ) ); // Use the ambient texture map as an occlusion map. ss-setTextureMode( AMBIENT_OCCLUSION_UNIT, GL_TEXTURE_2D, GL_TRUE ); ss-setTextureAttribute(AMBIENT_OCCLUSION_UNIT, new osg::TexEnv(osg::TexEnv::MODULATE) ); ss-setTextureAttribute( AMBIENT_OCCLUSION_UNIT, AmbientStateAttribute ); // Modulate in the diffuse texture ss-setTextureMode( MAIN_TEXTURE_UNIT, GL_TEXTURE_2D, GL_TRUE ); ss-setTextureAttribute(MAIN_TEXTURE_UNIT, new osg::TexEnv(osg::TexEnv::MODULATE) ); ss-setTextureAttribute( MAIN_TEXTURE_UNIT, DiffuseStateAttribute ); So setting up a texture for your diffuse colour should probably work. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamic Modification..
Hello Ignazio, So a last question..I change color for example for 3 seconds,after this time I must set the default solid color.. And during this time others sphere must brighten..Thanks a lot.. It's up to you to define your application's behavior any way you like... We can't really go around programming your application for you. For questions of OSG usage, sure, but this question is an implementation question. 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
Re: [osg-users] Dynamic Modification..
Thanks a lot.I try to do what you suggested..Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10548#10548 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Hello Christian, I have run into another problem. With my current approach the scene loses all lighting after the first frame has been drawn. All polygons appear in flat shading. I have currently no idea what is causing this. At first I was not noticing this because I rendered cow.osg which uses a metallic effect (environment maps?). But on other scenes the loss of lighting is apparent. This suggests that when pushing and popping state in order for Qt to draw its widgets, something is not pushed/popped correctly, probably GL_LIGHTING, GL_LIGHT0-GL_LIGHT7 or something like that? Perhaps glShadeModel? ... Just a possible avenue for investigation. I know it sounds obvious, but the error is obviously caused by something you overlooked, so listing things that should not be overlooked seems like the only way I can help... :-) 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
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi JS, Hows about using a cull callback that caches the compute near/far values before traversing the subgaph then restores the value afterwards, it'd only take a couple of lines of code. Robert. On Tue, Apr 21, 2009 at 6:55 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Chuck, Although not an optimal solution, and probably more of a work-around to your question ... I use a skydome as well. In my case, I just create a sphere whose radius is that (or a little less than that) of the camera's far-field value, which I've set to be quite large (60,000-meters). This works for my use case. But again, it's not an optimal solution. I'd also be interested in a more optimal and scalable solution. I prefer letting OSG manage my near+far planes according to the geometry in my scene, that way I can have optimal depth precision in pretty much all situations. The problem here is that this particular node should not be part of those calculations (I've set it to always win the depth test and render first, so that transparency with it works and it will be drawn even if the far plane is closer than its surface). Thanks for your suggestion though. Anybody else have an idea? I just had a thought, perhaps I could make a ComputeBoundCallback that would return a very small bounding sphere, and disable culling on the skydome... I'll try that and report how it goes. J-S chuck -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 12:13 PM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. J-S -- __ Jean-Sebastien Guay jean-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 -- __ Jean-Sebastien Guay jean-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
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Robert, Hows about using a cull callback that caches the compute near/far values before traversing the subgaph then restores the value afterwards, it'd only take a couple of lines of code. Hmm, another interesting approach. I'll try it. Thanks, 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] [forum] Modifying the scene graph while traversing it with a visitor crashes.
Hi, After I loaded an flt file, I invoke a visitor which traverses the whole scene graph and finds all the nodes that have textures attached to them. For each node that have a texture attached, it loads a new texture and tries to insert 2 extra nodes above the current node. This will crash the application when traverse(node) is called. Is it possible to modify the scene graph while traversing it? Regards, Chris Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10552#10552 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] Modifying the scene graph while traversing itwith a visitor crashes.
Cristina wrote on Tuesday, April 21, 2009 1:47 PM: After I loaded an flt file, I invoke a visitor which traverses the whole scene graph and finds all the nodes that have textures attached to them. For each node that have a texture attached, it loads a new texture and tries to insert 2 extra nodes above the current node. This will crash the application when traverse(node) is called. Is it possible to modify the scene graph while traversing it? It is not possible to insert nodes above the current node because you invalidate the iterators that are processing the lists of node children. To do what you are attempting, you could push the nodes onto a list and then modify the scenegraph after the traversal is finished. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] Modifying the scene graph while traversing it with a visitor crashes.
Thanks, I thought so. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10554#10554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Robert,
Hows about using a cull callback that caches the compute near/far
values before traversing the subgaph then restores the value
afterwards, it'd only take a couple of lines of code.
Unless I'm reading the headers wrong, there is no setter for the
computed near and far values? Only getters?
inline value_type getCalculatedNearPlane() const {
return _computed_znear; }
inline value_type getCalculatedFarPlane() const {
return _computed_zfar; }
I don't see anything that sets _computed_znear and _computed_zfar except
for methods that do actual calculations, like updateCalculatedNearFar(...) .
Is there some other way of doing what you're suggesting that I'm missing?
Otherwise, I guess I could cache and reset the ComputeNearFarMode like this:
class DoNotIncludeInNearFarComputationCallback
: public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor *cv =
dynamic_cast osgUtil::CullVisitor*( nv );
// Default value
osg::CullSettings::ComputeNearFarMode oldMode =
osg::CullSettings::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES;
if( cv )
{
oldMode = cv-getComputeNearFarMode();
cv-setComputeNearFarMode(
osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
}
traverse(node, nv);
if( cv )
{
cv-setComputeNearFarMode(oldMode);
}
}
};
Does that look like something that could work? (it doesn't seem to at
first glance, but maybe I'm doing something wrong)
Thanks,
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
Re: [osg-users] Dynamic Modification..
Please take a look at the osgcallback example, it will be much more
informative if you look there, maybe copy some code to start from, rather
than post questions to the email list. The fastest route to success for you
would be to look at the example and try some things out, then post here if
you have questions.
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 Ignazio
Sent: Tuesday, April 21, 2009 10:41 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Dynamic Modification..
Thanks..Accoding you I must extend the UpdatCallBack,in this way
class lux : public osg::Drawable::UpdateCallback {
virtual void operator()( osg::ShapeDrawable* drawable)
{
drawable -setColor(osg::Vec4(1,1,1,1));
}
};
Is what I speak right?
Thank advance..
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10539#10539
___
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] Geometry considered in near+far plane auto computation
Hi J-S -- I have a similar issue in one of my apps. I have a large scene (VPB database) with some geometry right in front of the eye (which I draw in eye coordinate space). So the near plane must be very close to the eye and the far plane extremely distant. I currently disable autocompute and set a large far plane value and a small near plane value, but this results in z fighting. To solve this in OpenGL, I'd use two projection matrices, one for the planet and one for the very close eye space geometry. The equivalent to this in OpenGL would be to use two Camera nodes. I haven't had time to code this up yet, but I'm certain it will address the issue. The first camera will auto compute near and far based on the planet, then the second camera will clear the depth buffer, will auto compute based on the eye space geometry, and will render that geometry. Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. (By the way, to set the near and far plane values, you set the projection matrix. OSG abstracts this away to make them look like two separate concepts, which is why we have a FAQ on why does OSG seem to ignore my near and far values? The answer is that OSG, by default, autocomputes the near and far planes and overrides those values as set by an application that explicitly sets the projection matrix.) 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: Tuesday, April 21, 2009 10:13 AM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be in the world - if I use the same trick as for a skybox (moving the cube with the camera) it will look like the horizon moves up relative to the terrain if I move the camera higher in altitude... Not a desirable effect. 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
Re: [osg-users] 3D Point to ScreenSpace Coordinates
Another option would be to look at the AutoTransform node. 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 Paul Martz Sent: Tuesday, April 21, 2009 8:54 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] 3D Point to ScreenSpace Coordinates It sounds like you are trying to draw a 2D element at the same window position as a 3D object. Is this correct? If you are going to project all the way to window coordinates, then you'll need to configure your projection matrix to render in window coordinates. You'd need two Camera nodes for this, one with your 3D projection and one for 2D. Another approach would be to just project down to eye coordinates (instead of all the way to window coordinates) and continue to use the same projection matrix. The disadvantage of this approach is that your 2D rendering would not be in Window coordinates. To code tasks like these proficiently, you would be well-advised to familiarize yourself with the OpenGL transformation pipeline. From your posts, it seems apparent that you don't have a good mastery of this topic. Get the OpenGL red book. 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 Hagen Sent: Tuesday, April 21, 2009 2:56 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] 3D Point to ScreenSpace Coordinates Thank you for those two answers. I forgot to say the point is in world coordinates so the first transformation should be obsolete for me. Then I did the following very simple where POSITION is the vector of the point and ssc is the result. Code: osg::Camera* cam = this-viewer-getCamera(); osg::Matrix viewMatrix = cam-getViewMatrix(); osg::Matrix projectionMatrix = cam-getProjectionMatrix(); osg::Matrix windowMatrix = cam-getViewport()-computeWindowMatrix(); osg::Matrix cameraMatrix = viewMatrix * projectionMatrix * windowMatrix; osg::Vec3 ssc = POSITION*cameraMatrix; pos-setPosition(osg::Vec3(ssc.x(),ssc.y(),0)); As you can see I give the the result to PositionAttitudeTransform. This PAT is attached to a slave cam with ABSOLUTE_RF This way I can have HUD (2D) elements following nodes in 3d. Problem: The accuracy is not very well. Moving th camera my HUD element is never exactly where it i supposed to be but just somwhere around the supposed area. Could that be float and double problems? If so: How can I make OSG do eighter everything or just the above calculation in double) Or do you have another idea why this problem appears? Greetings Hagen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10496#10496 ___ 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] Dynamic Modification..
Sorry if my post sounded rude. I am just trying to find a more efficient way
for you to get assistance than asking on the list and waiting for a helpful
response. People aren't always available to help, and may not always have
the right answer for you. Most of us who know OSG learned it by looking at
the example code, and there are plenty of examples that show how to add
callbacks, so I thought looking at the code might be a more efficient way
for you to solve your issue.
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 Paul Martz
Sent: Tuesday, April 21, 2009 1:16 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Dynamic Modification..
Please take a look at the osgcallback example, it will be much more
informative if you look there, maybe copy some code to start from, rather
than post questions to the email list. The fastest route to success for you
would be to look at the example and try some things out, then post here if
you have questions.
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 Ignazio
Sent: Tuesday, April 21, 2009 10:41 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Dynamic Modification..
Thanks..Accoding you I must extend the UpdatCallBack,in this way
class lux : public osg::Drawable::UpdateCallback {
virtual void operator()( osg::ShapeDrawable* drawable)
{
drawable -setColor(osg::Vec4(1,1,1,1));
}
};
Is what I speak right?
Thank advance..
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10539#10539
___
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] Geometry considered in near+far plane auto computation
Paul Martz wrote: Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficient for when you're inside a tessellated sphere, so you can just clear the z-buffer, turn off Z writes/compares, render the skydome, turn on z-write/compare and render the actual scene. Am I overlooking something? This has always worked for me. Concerning the huge-world-with-near-objects z-fighting problem, yeah, I've always fought with that issue. I've thought about looking at some way to mess with the z-write in a fragment shader so that it scales the z-distance according to some rule other than the (exponential?) one it uses now. That way you could have very near clip planes without wasting all of your z precision up front. But I've never tried implementing it, and I don't know if the programmable pipeline would let me get away with it. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Paul, I currently disable autocompute and set a large far plane value and a small near plane value, but this results in z fighting. That's exactly what I'm hoping to avoid. The equivalent to this in OpenGL would be to use two Camera nodes. [...] Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. Yes, that seems like it could work. I'll look into it. (By the way, to set the near and far plane values, you set the projection matrix. OSG abstracts this away to make them look like two separate concepts, which is why we have a FAQ on why does OSG seem to ignore my near and far values? The answer is that OSG, by default, autocomputes the near and far planes and overrides those values as set by an application that explicitly sets the projection matrix.) I'm familiar with the projection matrix and the auto compute modes... I don't want to set the actual near and far plane values, I want to set the values that the CullVisitor computes... It seems to me that the computed values will be computed completely before any actual drawing occurs, so setting the near/far myself won't change anything since the auto compute will then overwrite my values. I'm basically looking for a way for my skydome not to affect the calculated near/far values. Thanks, 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
Re: [osg-users] Geometry considered in near+far planeauto computation
Chris -- Yes, you're right on the skydome and clearing. At my previous employer, we used to just draw a single fullscreen quad. and we used the texture matrix to stretch the cloud texture map according to distance and also to orient and move the texture in response to changes in the camera orientation. But the geometry was all eye coordinates. (OK, that was a tangent...) Like you said, we didn't bother to do a clear before rendering the skydome, we just drew the quad at the far plane with depth test set to ALWAYS, and the net effect was that the rendering cleared both the depth and color buffers and prepared it for our app to render the rest of the scene with a nice tight far/near ratio. 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 Chris 'Xenon' Hanson Sent: Tuesday, April 21, 2009 1:43 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Geometry considered in near+far planeauto computation Paul Martz wrote: Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficient for when you're inside a tessellated sphere, so you can just clear the z-buffer, turn off Z writes/compares, render the skydome, turn on z-write/compare and render the actual scene. Am I overlooking something? This has always worked for me. Concerning the huge-world-with-near-objects z-fighting problem, yeah, I've always fought with that issue. I've thought about looking at some way to mess with the z-write in a fragment shader so that it scales the z-distance according to some rule other than the (exponential?) one it uses now. That way you could have very near clip planes without wasting all of your z precision up front. But I've never tried implementing it, and I don't know if the programmable pipeline would let me get away with it. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ 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] Geometry considered in near+far plane auto computation
Hi Chris, Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficient for when you're inside a tessellated sphere, so you can just clear the z-buffer, turn off Z writes/compares, render the skydome, turn on z-write/compare and render the actual scene. Am I overlooking something? This has always worked for me. Nope, that's exactly what I'm doing, the problem is that OSG still uses the skydome when auto-computing the near+far planes for the other objects in the scene. And I need the dome to be really big, otherwise I get the problem I mentioned earlier (when moving away from the ground in altitude, the dome will seem like it's not touching the horizon anymore). 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
Re: [osg-users] Geometry considered in near+far planeauto computation
I'm familiar with the projection matrix and the auto compute modes... I don't want to set the actual near and far plane values, I want to set the values that the CullVisitor computes... It seems to me that the computed values will be computed completely before Ah! Je comprend! Seems like it'd be nice to have a callback to compute the far and near planes. Would you like to code that up? OSG does allow you to set the ratio of near and far. OSG computes the smallest far plane value, then uses this specified ratio to compute the furthest near plane value such that the equation (far/near = ratio) evaluates to true.. But this is the only option I know of without changing the code. 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: Tuesday, April 21, 2009 1:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Geometry considered in near+far planeauto computation Hi Paul, I currently disable autocompute and set a large far plane value and a small near plane value, but this results in z fighting. That's exactly what I'm hoping to avoid. The equivalent to this in OpenGL would be to use two Camera nodes. [...] Seems like you could do something similar with your skydome. Use a camera to render the skydome, then a second camera to render everything else in your scene. Yes, that seems like it could work. I'll look into it. (By the way, to set the near and far plane values, you set the projection matrix. OSG abstracts this away to make them look like two separate concepts, which is why we have a FAQ on why does OSG seem to ignore my near and far values? The answer is that OSG, by default, autocomputes the near and far planes and overrides those values as set by an application that explicitly sets the projection matrix.) I'm familiar with the projection matrix and the auto compute modes... I don't want to set the actual near and far plane values, I want to set the values that the CullVisitor computes... It seems to me that the computed values will be computed completely before any actual drawing occurs, so setting the near/far myself won't change anything since the auto compute will then overwrite my values. I'm basically looking for a way for my skydome not to affect the calculated near/far values. Thanks, 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
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote: Nope, that's exactly what I'm doing, the problem is that OSG still uses the skydome when auto-computing the near+far planes for the other objects in the scene. And I need the dome to be really big, otherwise I get the problem I mentioned earlier (when moving away from the ground in altitude, the dome will seem like it's not touching the horizon anymore). Yeah, but I had a way to avoid this. Let me look at my code again... J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Hi J-S,
Try this:
void QOsgScene::drawBackground ( QPainter * painter, const QRectF rect )
{
if (m_redrawEnabled == false){
return;
}
emit aboutToDraw();
// Only works with OpenGL
if( painter-paintEngine()-type() == QPaintEngine::OpenGL )
{
GLenum errorNo;
// Qt OpenGL State Initialization takes
// place before we get here, on every frame.
// We can assume that OpenGL state is reset to
// default on every frame.
// Push initialized state onto the stack so that we can
// Recover it later for further Qt Drawing.
glPushAttrib(GL_ALL_ATTRIB_BITS);
glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS);
// Fixup stuff that Qt Modifies from default state that
// OSG expects.
glShadeModel(GL_SMOOTH);
// Push matricies
glMatrixMode(GL_TEXTURE);
glPushMatrix();
glLoadIdentity();
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadIdentity();
// Make sure that OSG's state is prepared based on the last
state
// recorded (if available). The first frame is different.
osg::State *state =
getCamera()-getGraphicsContext()-getState();
state-reset();
state-apply(m_lastStateSet.get());
// Run a frame: this is where the action happens.
frame();
// Store the OSG state for restoration in the next frame.
getCamera()-getGraphicsContext()-getState()-captureCurrentState(*m_lastStateSet);
// Pop matricies.
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glMatrixMode(GL_TEXTURE);
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
// Pop Attribs, now we're ready to continue
// Drawing with OpenGL.
glPopAttrib();
glPopClientAttrib();
errorNo = glGetError();
if (errorNo!=GL_NO_ERROR)
{
LOG_MSG(logERROR) Post-Frame: Detected OpenGL error
(frame
m_frameNo ) ' gluErrorString(errorNo) ';
}
++m_frameNo;
}
else
{
qWarning(QOsgScene: drawBackground needs a QGLWidget to be set
as
viewport on the graphics view.);
}
}
_
Sean Spicer
Executive Vice President Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.281.466.4848
Mobile...+1.713.447.2706
Fax...+1.281.466.4849
On Tue, Apr 21, 2009 at 1:28 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hello Christian,
I have run into another problem. With my current approach the scene
loses all lighting after
the first frame has been drawn. All polygons appear in flat shading. I
have currently no idea what is causing this. At first I was not
noticing this because I rendered cow.osg which uses a metallic effect
(environment maps?). But on other scenes the loss of lighting is
apparent.
This suggests that when pushing and popping state in order for Qt to draw
its widgets, something is not pushed/popped correctly, probably GL_LIGHTING,
GL_LIGHT0-GL_LIGHT7 or something like that? Perhaps glShadeModel? ...
Just a possible avenue for investigation. I know it sounds obvious, but the
error is obviously caused by something you overlooked, so listing things
that should not be overlooked seems like the only way I can help... :-)
J-S
--
__
Jean-Sebastien Guay jean-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
Re: [osg-users] Geometry considered in near+far plane auto computation
Chris 'Xenon' Hanson wrote: Yeah, but I had a way to avoid this. Let me look at my code again... From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computation, traverse the node/subgraph, and then turn it back on? J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computation, traverse the node/subgraph, and then turn it back on? That's what I've done (see a previous post in this thread) but it didn't work for some reason - the subgraph was never rendered. I've done what Paul suggested: the skydome is under a PRE_RENDER camera and so has its own projection matrix and thus, doesn't affect the computed near/far values for the main camera. It works, but it has more implications on the rest of my scene graph/viewer setup than I'd like. All other cameras need to be set to only clear the depth buffer otherwise they'll clear my skydome (of course) and since in my app, views may be added at any time, this introduces an extra required step when creating a view... I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Thanks, 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
Re: [osg-users] Geometry considered in near+far plane auto computation
J-S (and others),
You could look at doing this is the same way the depth partition node does
it, which is what I do:
I use a class based on an OSG camera with an overriden traverse method, that
forces the projection matrix to a particular z near and z far. Oh, and the
camera has setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR)
in its constructor. The skydome is then a child of this camera.
You then set the z near and z far to be whatever you want (i.e. enveloping
your skydome radius). I typically have a skydome with a radius of 1
void CExtentsCamera::traverse(osg::NodeVisitor nv)
{
// If the scene hasn't been defined (i.e. we have no children at all)
then don't do anything
if(_children.size() == 0) return;
// If the visitor is not a cull visitor, then we are not interested in
intercepting it, so pass it directly onto the scene.
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*(nv);
if(!cv)
{
Camera::traverse(nv);
return;
}
// Get a reference to the Cull Visitor's projection matrix
osg::Matrix* projection = cv-getProjectionMatrix();
// NB : This might be possible to simplify and hence optimise (haven't
yet checked)
double a = (*projection)(2,2);
double b = (*projection)(3,2);
double c = (*projection)(2,3);
double d = (*projection)(3,3);
double trans_near = (-_zNear*a + b) / (-_zNear*c + d);
double trans_far = ( -_zFar*a + b) / ( -_zFar*c + d);
double ratio = fabs(2.0/(trans_near - trans_far));
double center = -0.5*(trans_near + trans_far);
// Set the projection matrix
projection-postMult(osg::Matrixd(1.0, 0.0, 0.0,0.0,
0.0, 1.0, 0.0,0.0,
0.0, 0.0, ratio,0.0,
0.0, 0.0, center*ratio, 1.0));
Camera::traverse(nv);
}
Probably a better way of doing it, but it works fine for me.
I also do this on the camera's stateset
{
osg::Depth* depth = new osg::Depth;
depth-setFunction(osg::Depth::LEQUAL);
depth-setRange(1.0,1.0);
stateSet-setAttributeAndModes(depth,osg::StateAttribute::ON );
}
so that you can render the sky last, and any expensive pixel shaders don't
get unnecessarily run.
Hope that helps,
David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG COLLADA loader
It appears that the COLLADA loader only supports 1.4 of the COLLADA spec right now, which I understand. I just wanted to see if anyone was working on 1.5 support already? I'm mostly interested in being able to validate and view objects produced for use in Google Earth, which is capable of using 1.5 now. Failing that, anyone know of a 1.5-supporting COLLADA viewer that can be trusted, and doesn't cost and arm and a leg? I tried compiling one from the COLLADA-DOM project, but so far haven't satisfied all of it's dependencies to get a binary compiled yet. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote: That's what I've done (see a previous post in this thread) but it didn't work for some reason - the subgraph was never rendered. Ok. I stepped into the conversation late. I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Yeah, that should be the way to do it. Did you copy a working recipe or wing it from scratch? Thanks, J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Yeah, that should be the way to do it. Did you copy a working recipe or wing it from scratch? From scratch, I couldn't find another cull callback that did things before and after the traverse() in the examples... Any suggestions? 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
Re: [osg-users] Geometry considered in near+far plane autocomputation
If your geometry (such as a skydome) is not changing and always has the same
near and far extents, then it would be inefficient to derive an entire new
Camera node just to compute near and far values redundantly in every cull
traversal. Unless I'm missing something here, why not just disable auto
compute for the skydome camera and set the near and far planes explicitly?
Then use a separate camera to render the rest of the scene, with auto
compute enabled?
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com http://www.skew-matrix.com/
+1 303 859 9466
_
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David
Spilling
Sent: Tuesday, April 21, 2009 2:30 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Geometry considered in near+far plane
autocomputation
J-S (and others),
You could look at doing this is the same way the depth partition node does
it, which is what I do:
I use a class based on an OSG camera with an overriden traverse method, that
forces the projection matrix to a particular z near and z far. Oh, and the
camera has setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR)
in its constructor. The skydome is then a child of this camera.
You then set the z near and z far to be whatever you want (i.e. enveloping
your skydome radius). I typically have a skydome with a radius of 1
void CExtentsCamera::traverse(osg::NodeVisitor nv)
{
// If the scene hasn't been defined (i.e. we have no children at all)
then don't do anything
if(_children.size() == 0) return;
// If the visitor is not a cull visitor, then we are not interested in
intercepting it, so pass it directly onto the scene.
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*(nv);
if(!cv)
{
Camera::traverse(nv);
return;
}
// Get a reference to the Cull Visitor's projection matrix
osg::Matrix* projection = cv-getProjectionMatrix();
// NB : This might be possible to simplify and hence optimise (haven't
yet checked)
double a = (*projection)(2,2);
double b = (*projection)(3,2);
double c = (*projection)(2,3);
double d = (*projection)(3,3);
double trans_near = (-_zNear*a + b) / (-_zNear*c + d);
double trans_far = ( -_zFar*a + b) / ( -_zFar*c + d);
double ratio = fabs(2.0/(trans_near - trans_far));
double center = -0.5*(trans_near + trans_far);
// Set the projection matrix
projection-postMult(osg::Matrixd(1.0, 0.0, 0.0,0.0,
0.0, 1.0, 0.0,0.0,
0.0, 0.0, ratio,0.0,
0.0, 0.0, center*ratio, 1.0));
Camera::traverse(nv);
}
Probably a better way of doing it, but it works fine for me.
I also do this on the camera's stateset
{
osg::Depth* depth = new osg::Depth;
depth-setFunction(osg::Depth::LEQUAL);
depth-setRange(1.0,1.0);
stateSet-setAttributeAndModes(depth,osg::StateAttribute::ON );
}
so that you can render the sky last, and any expensive pixel shaders don't
get unnecessarily run.
Hope that helps,
David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote: Otherwise, I guess I could cache and reset the ComputeNearFarMode like this: Does that look like something that could work? (it doesn't seem to at first glance, but maybe I'm doing something wrong) It looks exactly like I'd expect it to be. I think you can omit setting the oldMode default value even. Have you debugged it to keep an eye on what happens to the near/far values when it runs through? I wonder if the Cull is somehow not adding the skydome to the render graph? Have you been successful in just loading a new near/far value manually? If so, what if you cache the far value from here externally, then manually load it prior to rendering, and see if it renders your skydome. Thanks, J-S -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
I can see that this might have long fingers in your app. Bummer. Anyhow, you might be able to also avoid clearing depth in your other cameras. Here's something to try: In the camera that renders the skydome, use Depth in the StateSet to set the depth range to something like 0.999-1.0. This puts your skydome all the way in the back of the depth buffer, and then it should be far enough back that subsequent scene cameras shouldn't need to clear either the color or depth buffers. It might be kind of a pain in your app, but hopefully avoiding those clears buys you some small performance gain that makes the change as a whole beneficial. 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: Tuesday, April 21, 2009 2:29 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Geometryconsidered in near+far plane auto computation Hi Chris, From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computation, traverse the node/subgraph, and then turn it back on? That's what I've done (see a previous post in this thread) but it didn't work for some reason - the subgraph was never rendered. I've done what Paul suggested: the skydome is under a PRE_RENDER camera and so has its own projection matrix and thus, doesn't affect the computed near/far values for the main camera. It works, but it has more implications on the rest of my scene graph/viewer setup than I'd like. All other cameras need to be set to only clear the depth buffer otherwise they'll clear my skydome (of course) and since in my app, views may be added at any time, this introduces an extra required step when creating a view... I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Thanks, 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
Re: [osg-users] Geometry considered in near+far plane auto computation
Jean-Sébastien Guay wrote:
From scratch, I couldn't find another cull callback that did things
before and after the traverse() in the examples... Any suggestions?
I dug back into my e-mail archives and found a message from Robert on
10/7/2003 that I
used as my inspiration:
There isn't at present a away to disable the computation of the near far for a
subgraph via settings on Node's. However, what you might be able to try
would be to disable the near far computation via a NodeCallback attached to
the skydome subgraph. Something like
struct MyCullCallback : public osg::NodeCallback
{
virtual void operator()(Node* node, NodeVisitor* nv)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
osgUtil::CullVisitor::ComputeNearFarMode saveComputeNearFar;
if (cv)
{
saveComputeNearFar = cv-getComputeNearFarMode()
cv-setComputeNearFarMode(
osgUtil::CullVisitor::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES);
}
traverse(node,nv);
if (cv)
{
saveComputeNearFar = cv-getComputeNearFarMode()
cv-setComputeNearFarMode(saveComputeNearFar);
}
}
}
Now, there's some missing semicolons there, but those are easy to fix. Oddly
though, it
looks like he's recommending switching to
COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES and I
think it should be DO_NOT_COMPUTE_NEAR_FAR. Also, the lower saveComputeNearFar =
cv-getComputeNearFarMode() should not be there. But, I think this demonstrates
you're on
the right track, and maybe just need to debug what's really happening at
runtime.
J-S
--
Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DoomLike manipulator
Hi, In fact I've struggled quite a while to handle collision in a way that apparently doesn't work, and finally I had to postpone coding on it for work reason. I'll try to post a version of this manipulator with simple collision tests soon , let's say by the week end. On Tue, Apr 21, 2009 at 3:51 AM, Richard Baron Penman richardbp+...@gmail.com richardbp%2b...@gmail.com wrote: hi, I'm interested in using this manipulator. Have any updates been posted or should I use the originally posted one? Richard 2009/3/24 Simon Loic simon1l...@gmail.com In fact I didn't have enough time to finish this week-end. So It will be postponed to next week. On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic simon1l...@gmail.com wrote: All right, I'll certainly finish during the week-end and post it on osg-users for testing. 2009/3/20 Robert Osfield robert.osfi...@gmail.com Hi Loic, Great little discussion :-) 2009/3/19 Simon Loic simon1l...@gmail.com Maybe when I will have finished to implement the GROUNDED/HORIZONTAL mode you can give it a try and decide which name best fits. In my concern I clearly incline towars grounded as the implementation I was about to propose allows step over small obstacles like stairs. If you have remarks on the implementation so far, go ahead... to sukender : I didn't exacly get your remarks while I'm sure they are founded. Anyway I think that when I wil have finished to code both mode, things will become clearer for me and for you. Get you informed as soon as the manipulator is ready. When you ready just post the changes to either osg-submissions if it's ready to merge, or to osg-users if you feel it still needs more discussion. Cheers, Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon -- Loïc Simon ___ 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 -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi Paul, Anyhow, you might be able to also avoid clearing depth in your other cameras. Actually, the problem is not disabling clear of the depth buffer, it's disabling clear of the color buffer. Only the first camera needs to clear the color buffer, and since my skydome is rendered in PRE_RENDER, it's the first camera. I therefore need to disable clear of the color buffer for all other cameras. Anyways, I'll try to go forward with the other route (disabling auto computation of near/far) since I think this will have less implications. Thanks, 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
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi Chris, I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: Thanks for digging that up. Indeed, after the corrections you mention, it looks almost exactly like what I have. But, I think this demonstrates you're on the right track, and maybe just need to debug what's really happening at runtime. Well, I've confirmed at least that the cull callback operator() is called at run time and that the dynamic_cast succeeds, so I just need to know what to check for to make sure my geometry would be rendered... I've never had to debug a cull callback before, what would you suggest I check for? Which of the CullVisitor's variables should I keep an eye on? I assume the call to traverse() is what actually adds the skydome to the render graph, so I'd need to trace down into that right? Thanks, 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] Compiling old FLT loader
For some regression comparison, I'd like to compile and run the old FLT loader. I've checked it our of the deprecated SVN, and then copied its directory into the src/osgPlugins directory. I re-ran CMake on the assumption that it would pick it up, but it doesn't seem to have. I don't see any of the CMake files in the flt folder. Is it too old to participate in CMake, and therefore not practical to compile anymore? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
This suggests that when pushing and popping state in order for Qt to draw its widgets, something is not pushed/popped correctly, probably GL_LIGHTING, GL_LIGHT0-GL_LIGHT7 or something like that? Perhaps glShadeModel? ... Hi yes indeed, something was killing off the GL_LIGHTING and GL_LIGHT0 flag. And it was something rather unusual. Turns out the embeddedGraphicsView somehow calls into SceneView for rendering. SceneView is marked as deprecated in the DoxyGen documentation - maybe because it's the old single threaded rendering path? Near the end of SceneView::draw() we find the following peculiarity. // re apply the defalt OGL state. state-popAllStateSets(); state-apply(); This resets the state to the OpenGL default - and turns off my lighting ! This is the only place in all of OpenSceneGraph() that popAllStateSets is being used - I did a full search. So I wonder what I should do about that. And why does this not also screw up all other code samples that make use of the embeddedGraphicsView - like e.g. the regular osgviewerQT ? Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.
Boy, that code looks surprisingly similar to mine, except for this center part: // Make sure that OSG's state is prepared based on the last state // recorded (if available). The first frame is different. osg::State *state = getCamera()-getGraphicsContext()-getState(); state-reset(); state-apply(m_lastStateSet.get()); // Run a frame: this is where the action happens. frame(); // Store the OSG state for restoration in the next frame. getCamera()-getGraphicsContext()-getState()-captureCurrentState(*m_lastStateSet); Maybe the additional getState() + reset() / apply() and captureCurrentState() will solve my lights problem. I will try. Thanks a bunch! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Yes, I understand this. And because you _have_ to disable color buffer clears in the other cameras, it'd be nice if you could also disable depth buffer clears. That way, the other cameras wouldn't have to invoke glClear at all. (That was the point I was trying to make, sorry it got convoluted. :-) 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: Tuesday, April 21, 2009 4:02 PM To: OpenSceneGraph Users Subject: Re: [osg-users]Geometryconsidered in near+far plane auto computation Hi Paul, Anyhow, you might be able to also avoid clearing depth in your other cameras. Actually, the problem is not disabling clear of the depth buffer, it's disabling clear of the color buffer. Only the first camera needs to clear the color buffer, and since my skydome is rendered in PRE_RENDER, it's the first camera. I therefore need to disable clear of the color buffer for all other cameras. Anyways, I'll try to go forward with the other route (disabling auto computation of near/far) since I think this will have less implications. Thanks, 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
Re: [osg-users] Compiling old FLT loader
If it predates CMake, I bet you could start with a CMakeLists.txt from an existing plugin like BMP, and hack it to build the old FLT plugin. 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 Chris 'Xenon' Hanson Sent: Tuesday, April 21, 2009 4:57 PM To: OpenSceneGraph Users Subject: [osg-users] Compiling old FLT loader For some regression comparison, I'd like to compile and run the old FLT loader. I've checked it our of the deprecated SVN, and then copied its directory into the src/osgPlugins directory. I re-ran CMake on the assumption that it would pick it up, but it doesn't seem to have. I don't see any of the CMake files in the flt folder. Is it too old to participate in CMake, and therefore not practical to compile anymore? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ 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] Geometry considered in near+far plane auto computation
Hi again, I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: Thanks for digging that up. Indeed, after the corrections you mention, it looks almost exactly like what I have. I just had a thought, could the object on which this callback is set have any influence on the results? Should I set the cull callback on the Geode, or will any parent node do? I was setting it on the parent node of my skydome, which is a MatrixTransform. Perhaps that had some influence... 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
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi again Paul,
Anyways, that's a design concern, not implementation. Thanks for your
suggestions.
And I do want to emphasize that your solution (using a separate
osg::Camera) does work. I've implemented it for both the skydome and
cloud plane (which can get really big too) and I can now get really
close to small models without them being clipped by the near plane.
Barring any breakthrough on the other front, this will still be a very
good solution.
If anyone's curious, the code looks like:
// Callback that checks other cameras
namespace {
int s_skyDomePreRenderCameraNum = -100;
class CheckCamerasCallback : public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor *cv =
dynamic_cast osgUtil::CullVisitor *( nv );
if (cv)
{
// Do not use cv-getCurrentCamera() because it did not
// exist in 2.2 which we still support
osg::Camera* camera =
cv-getCurrentRenderBin()-getStage()-getCamera();
// If the camera is either a pre-render camera with num
// our pre-render order, or not a pre-render camera
if (camera-getRenderOrder() != osg::Camera::PRE_RENDER ||
camera-getRenderOrderNum()
s_skyDomePreRenderCameraNum)
{
// I should also check if the camera is set to render to
// the framebuffer and is not an RTT camera, just to be
// sure I'm only affecting the cameras I want to affect.
// Set the camera to not clear the color buffer.
if (camera-getClearMask() GL_COLOR_BUFFER_BIT)
camera-setClearMask(
camera-getClearMask() ~GL_COLOR_BUFFER_BIT);
}
}
traverse(node,nv);
}
};
}
SkyDome::SkyDome(...)
{
// Skydome initialization (the code is a modified version of the
// osgEphemeris skydome)
// ...
// ...
// Render the skydome through another camera so that the cloud plane
// won't influence the main camera's near/far plane computations.
// I'd prefer to find some other way to have the sky dome not
// influence the main camera near/far values, because this has
// repercussions on the viewer setup (see how CheckCamerasCallback
// affects all other cameras). But it works well.
#define USE_EXTRA_CAMERA
#ifdef USE_EXTRA_CAMERA
osg::Camera* camera = new osg::Camera;
camera-setRenderOrder(osg::Camera::PRE_RENDER,
s_skyDomePreRenderCameraNum); // set to -100 by default
// Hopefully this will be the first pre-render camera, so it should
// clear the color and depth buffers (this skydome is not guaranteed
// to fill the whole view at all times).
camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
// The dome hangs under m_skyTransform.
camera-addChild(m_skyTransform.get());
// m_node is the node that's exposed to be added to the graph by
// client code.
m_node-addChild(camera);
// Make sure the main viewer camera only clears the depth buffer
// otherwise it will clear our skydome...
m_node-setCullCallback(new CheckCamerasCallback);
#else
// The dome hangs under m_skyTransform.
// m_node is the node that's exposed to be added to the graph by
// client code.
m_node-addChild(m_skyTransform.get()); // The dome hangs under this
#endif
}
Thanks a lot.
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
Re: [osg-users] Jerky display?
Hi
The following is the environment which i am working on,
Hardware configuration:
HP xw4400 Workstation
Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz, 2GB RAM
NVIDIA Quadro FX 3500
OS:
MS Windows XP Professional Version 2002
Service Pack 3, v.3244
OSG:
OSG2.2
The following set of code shows about how I am building scene graph for terrian
visualization,
//the fileTerrainModels.txt Contains list of terrain models(.osga files) with
absolute path
//all are geographic models with datum 'WGS-84' and 'UTM' projection
ifstream fin(TerrainModels.txt);
while(!fin.eof()){
finstr;
if(strstr(str,.osga)!=NULL){
osg::ref_ptrosg::Fog fog=new osg::Fog;
fog-setColor(osg::Vec4(.45,.45,.45,1.));
fog-setStart(0.f);
fog-setEnd(50.f);
fog-setDensity(1.f);
fog-setMode(osg::Fog::LINEAR);
fog-setFogCoordinateSource(osg::Fog::FRAGMENT_DEPTH);
osg::StateSet *statSet=new osg::StateSet();
statSet-setMode(GL_BLEND,osg::StateAttribute::ON);
statSet-setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF);
statSet-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
statSet-setAttributeAndModes(fog.get(),osg::StateAttribute::ON);
osg::PagedLOD *plod = new osg::PagedLOD();
plod-setName(str);
plod-setRangeMode(osg::PagedLOD::DISTANCE_FROM_EYE_POINT);
plod-setFileName(0, str);
plod-setPriorityOffset(0, 1.f);
plod-setPriorityScale(0, 1.f);
plod-setRange(0, 50.f, 100.f);
plod-setStateSet(statSet);
group-addChild(plod);
}else if(strstr(str,bluemarble.ive)==0) //for specifically adding
virtual earth
group-addChild(osgDB::readNodeFile(str));
}
fin.close();
osgViewer::Viewer viewer;
osgUtil::Optimizer optimzer;
optimzer.optimize(group.get());
viewer.setSceneData(group.get());
viewer.addEventHandler( new
osgGA::StateSetManipulator(viewer.getCamera()-getOrCreateStateSet()) );
viewer.addEventHandler(new osgViewer::ThreadingHandler);
viewer.setCameraManipulator(new osgGA::TerrainManipulator());
viewer.realize();
while(!viewer.done()){
viewer.frame();
}
Let me explain the problem,
I am trying to load around 8000-9000 osg terrain models which are covering part
of india.
As I have set the PagedLOD range 50-100, when I enter the range(zooming-down
thru virtual earth), all the terrain models start loading and from that range
onwards I am not able to zoom-down freely. It becomes very slow and the view
also jerks.
Please correct me.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10589#10589
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
