[osg-users] Line curve
Which is the easiest way to draw line curves i osgviewer. Im developing a function that draw a function from startPos to endPos (vec3) both. With a math function. Any hints? .. about functions available? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Line curve
Hi Johan
On Mon, Jun 2, 2008 at 7:59 AM, Johan Johnsson [EMAIL PROTECTED] wrote:
Which is the easiest way to draw line curves i osgviewer.
Im developing a function that draw a function from startPos to endPos (vec3)
both. With a math function.
Any hints? .. about functions available?
Drawing mathematical curves in OpenGL is generally done using line
strips, i.e. you sample your function at regular intervals, this
produces a list of vertex and you connect them with lines. If you
choose an appropriate sample rate, your curve will look smooth.
sample code for the OSG:
float your_math_func(float x) { .. }
int numSteps = 100; // More vertices-smoother curve, slower display
float xstart = startPos.x();
float xstep = (endPos.x() - startPos().x) / (float)(numSteps-1);
osg::Vec3Array* vertices = new osg::Vec3Array;
float x = xstart;
for (int i=0;inumSamples;++i) {
vertices-push_back(osg::Vec3(x,your_math_func(x),0.0f));
x += xstep; }
osg::Geometry* geom = new osg::Geometry;
geom-setVertexArray(vertices);
geom-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_STRIP, 0, vertices-size()));
Thibault
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
On Sat, May 31, 2008 at 9:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 10:55 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Steve, If you don't want to be bored by the details, it basically says that VC8 VC9 have a bug when Iterator Debugging is turned off with regards to iterator copying, and that Microsoft doesn't intend to address it until VC10. In my specific case, that bug causes an assertion at the return statement of getFileExtension(). Strange, we are using OSG 2.2 and 2.4 with iterator debugging turned off in our apps, and I have never seen this. I'll investigate a bit more on Monday, this is intriguing... I wonder if this might be the reason why the new DatabasePager was crashing in debug build under Windows... Hi Robert, My debug build has iterator debugging turned on, so I don't think it's related. But I'll try to look if there is any VC bug that can cause this problem. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Hi, Viggo Løvli wrote: Ok, that make sense. It happens every time I render with a floating point texture. The fall in framerate does not happen when I run the OSG multi render target example using HDR. My code does however use additive blending toward the floating point texture so I bet that is what cause it to fall into a software rendering mode. We have also experienced this slowdown when blending was enabled with float textures. Testing on newer cards is pending as we cannot figure out from docs on the internet if this is actually supported in current hardware at all. Seems like DX10.1 mandates float blending, but we will test to make sure. Please let me know if you know if it is supported in hardware. Do you know about any texture surface bit format that is more than 8 bits (unsigned integer) ? I don't know of any. I've only seen a paper once where people were using three channels to simulate one large channel. The RGB channels were partially overlapped to create a higher dynamic range channel. jp Viggo Date: Fri, 30 May 2008 16:29:05 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, When performance drops like this it's because you've dropped onto a software fallback path in the OpenGL driver. Exactly what formats are software vs hardware depends upon the hardware and OpenGL drivers. You'll need to check with your hardware vendors specs to see what will be hardware accelerated. Robert. On Fri, May 30, 2008 at 2:16 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, I modified my code as you suggested. The warning is gone :-) The framerate is now 10 seconds per frame instead of 30 frames per second. It does something. The texture I render to remains black (cleared to black). If I change the setInternalFormat to GL_RGBA then the framerate is up again, and the texture gets colors. This works, but then I only have 8 bit in the red channel. What I need is as many bits as possible in the red channel, preferably 32. And I do not need GBA channels. Do you have a suggestion for me on this one? Viggo Date: Fri, 30 May 2008 13:25:24 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, The warning is exactly right, pbuffers don't suport multiple render targets, only FrameBufferObjects do. Perhaps what you intend it not to use multiple render targets, in which case you should set the Camera attachment to COLOR_BUFFER rather than COLOR_BUFFER0, that later tells the OSG that you want MRT and will be using glFragColor[] in your shaders. Also the Camera::setDrawBuffer(GL_COLOR_ATTACHMENT0_EXT) is inappropriate for pbuffers. Robert. On Fri, May 30, 2008 at 1:18 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I want to render to a floating point buffer, and I set things up like this: tex-setInternalFormat( GL_LUMINANCE16F_ARB ); tex-setSourceFormat( GL_RED ); tex-setSourceType( GL_FLOAT ); camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-attach( osg::Camera::BufferComponent( osg::Camera::COLOR_BUFFER0 ), tex ); camera-setDrawBuffer( GL_COLOR_ATTACHMENT0_EXT ); My fragment-shader that write to the surface output the value this way: gl_FragData[0].r = 1.0; Another fragment-shader reads the surface this way: value = texture2DRect( id, gl_FragCoord.xy ).r; I get the following output when I try to run my app: Warning: RenderStage::runCameraSetUp(state) Pbuffer does not support multiple color outputs. My app runs, but nothing is written to the texture. Is it possible to set up a surface that holds one channel (GL_RED) which is an unsigned int of 32 bit resolution? I'd rather use that than a float :-) Viggo Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis lagringsplass. ___ 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 SkyDrive er her. Glem minnepinnen! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Hi J-S, On Sun, Jun 1, 2008 at 9:37 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: So I think in addition to all you said in the previous message (and with which I agree), making a few point releases between stable releases would help people keep up to date more easily. This easy part is deciding that 2.stable.patch releases are valuable. The harder part is having the manpower to build and maintain them - I am way overstretched as is, taking on more work is not viable for me personally. If we can find volunteers to take on 2.stable.patch release maintenance then it'll make this possible, and should make the project run more smoothly once we are all settled in the new roles. If we are to make these new 2.stable.patch releases with the assistance of volunteers then we'll need to make this role as easy as possible. For instance Documentation of the steps that we take to make a release, sharing scripts that make releases (build them in to CMake even?). Other items like build farms that test the build of the various branches would be useful would make it easier - something that a maintainer can leverage (rather than maintain). We needn't go the whole hog right away, but take baby steps in this direction. My thought that the maintainer should each stable series should be something that could alternate, so one engineer takes on 2.4.x, another takes on 2.6.x when it comes out etc, but I guess if could be tackled by one person that takes on several stable releases if the load is low. In general I'd expect the load to be relatively light compared to the work required maintaining trunk and converging to the initial stable release. The existence of stable.patch releases does also involve the community in testing, and maintainers of the binaries for different platforms, so perhaps one should just be a team, with a different member taking the lead as the overall maintainer of a stable releases, or perhaps the stable release maintainer is an outside who provides the base for the platform maintainers. I'd like feedback from the community on how we can make this all happen. The initial stab at doing this will require coordination from me and the first volunteer/group of volunteers, so please ask your questions about what the role would involve - we can put up a page on the wiki for this. To this end I've created two new pages on the wiki, under the Community/Tasks section : http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/StableReleases and http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/DeveloperReleases I've filled in a little of the StableReleases. Robert. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] correct manual shutdown of osg libraries
Hi Timo, Could you explain what you've done in more fine grained steps so that others will be able to understand what approach you've taken so that when they try the same thing they don't need to go through the same learning curve. Thanks, Robert. On Mon, Jun 2, 2008 at 6:44 AM, Timo Penndorf [EMAIL PROTECTED] wrote: Hi Paul, Hi Robert, thank you for your answers. I solved my problem. dlopen provides the RTLD_NODELETE flag and for windows I found a related article (http://msmvps.com/blogs/vandooren/archive/2006/10/09/Preventing-a-DLL-from-being-unloaded-by-the-app-that-uses-it.aspx) which finally results in incrementing the reference counter of the plugin-dll twice. As it is implemented in the plugin its author could decide whether it is necessary or not. So my application works fine on both intended platforms now. Timo Am Sonntag, den 01.06.2008, 16:00 +0100 schrieb Robert Osfield: Hi Paul, Destructing the Viewer should be enough to get the rendering backend (RenderStage/StageGraph etc) to clear, there shouldn't be any need to let the viewer keep rendering for a couple of frames. Unless of course you still needed the viewer after the, if so perhaps a clear method would be appropriate... In Timo's case I would guess that destructing the Viewer would be part of the work of uloading all the OSG libs. Robert. On Sun, Jun 1, 2008 at 3:36 PM, Paul Martz [EMAIL PROTECTED] wrote: I posted to this list about a similar issue not too long ago. I have a MS Windows application that creates a subgraph in a DLL. After rendering the subgraph for a while, due to some user interaction the subgraph is removed. The application was then immediately unloading the DLL that created the subgraph, thinking it should certainly be safe to do so. However, we encountered the following behavior: OSG's rendering backend (RenderLeafs, etc) still had some ref_ptrs into the removed subgraph, and didn't relinquish those ref_ptrs until a couple of frames later. Unfortunately, unloading the DLL also deleted the heap that was used to allocate the subgraph, so when those ref_ptrs finally decremented the reference count, the memory was already deleted -- crash. (This was on Windows; shared lib and heap behavior might be different on other OSes.) The final workaround was to allow the app the render a few frames (with the subgraph removed) and wait until the app was quiescent before unloading the DLL. So, I wonder if it might help you to unload your entire scene graph, then render a few empty frames before unloading your shared library. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Sunday, June 01, 2008 4:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] correct manual shutdown of osg libraries Hi Timo, I have never tried this first hand so can't comment with great wisdom, best I can do is guess. Destructing the osgDB::Registry in the way you have should close all the OSG plugins that have been loaded. In your instance a destrucutor of a core OSG node is crashing, which suggest to me that something like the core osg library has been unloaded before osgDB::Registry::instance() has been destroyed. Might this be the case? The best I can suggest is that you shut down all OSG released threads, then unload the plugins, then the viewer then NodeKits then core osg libries such osgDB then osgUtil then osg. Robert. On Sat, May 31, 2008 at 1:41 PM, Timo Penndorf [EMAIL PROTECTED] wrote: Hello, for my application I have written an osg plugin which is loaded dynamically via dl_open. This plugin is linked against the osg libraries and adds visualisation capabilities to my application. At application shutdown I remove all loaded plugins by dl_close. As the osg plugin is the only one linked against the osg libraries they are removed from address space ass well after removing the plugin. So my application runs into trouble at __cxa_finalize(). There are still some osg::ref_ptr objects in adress space but the code for the destructors is removed already. I suppose the osg::ref_ptr objects which are alive at __cxa_finalize are static objects (for instance) from singletons. I tried to clean up then osgDB::Registry manually by invoking osgDB::Registry::instance(true) but there are still some cases where the application runs into core dumps. Is there a chance to remove static objects to prevent my application from producing segmentation faults? Timo The gdb output: #0 0x in ?? () (gdb) up #1 0x003ba6d3 in osg::Referenced::unref (this=0x8bb3c28) at /usr/include/osg/Referenced:142 142 OpenThreads::ScopedLockOpenThreads::Mutex lock(*_refMutex);
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Hi again :-) I abandoned the idea of using a floating point buffer. I went into the thinking box and came to the same conclusion as you wrote about in the end of your comment. I needed a quite high resolution so I decided to use all 4 channels (RGBA). The numbers I want to accumulate is seldom large, so I needed most resolution in the lower scale. I thus decided to use RGBA where R is most significant and A is least significant. Bit usage is: R = 6 bits G = 5 bits B = 4 bits A = 3 bits All non used bits will overlap with next channel. I am using this to generate a pixel weight when rendering many volumetric clouds on top of each other on screen. Naturally most overlapping clouds will be further away from camera, so I needed as high a number of overlap bits on the lest significant buffers that I could get. My usage accepts in worst case 32 overlapping pixels with maximum weight (in the distance). I think that is something I can live with :-) Anyhow, I got a range (18 bit) that was good enough for my usage and it gives a decent cloud sorting for clouds seen up to 40 kilometers away. I must stress one point: - If you ever try using the alpha channel for this then remember to turn off alpha-clipping (set alpha-func to always). Viggo Date: Mon, 2 Jun 2008 10:05:24 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi, Viggo Løvli wrote: Ok, that make sense. It happens every time I render with a floating point texture.The fall in framerate does not happen when I run the OSG multi render target example using HDR. My code does however use additive blending toward the floating point texture so I bet that is what cause it to fall into a software rendering mode. We have also experienced this slowdown when blending was enabled with float textures. Testing on newer cards is pending as we cannot figure out from docs on the internet if this is actually supported in current hardware at all. Seems like DX10.1 mandates float blending, but we will test to make sure. Please let me know if you know if it is supported in hardware. Do you know about any texture surface bit format that is more than 8 bits (unsigned integer) ? I don't know of any. I've only seen a paper once where people were using three channels to simulate one large channel. The RGB channels were partially overlapped to create a higher dynamic range channel. jp Viggo Date: Fri, 30 May 2008 16:29:05 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, When performance drops like this it's because you've dropped onto a software fallback path in the OpenGL driver. Exactly what formats are software vs hardware depends upon the hardware and OpenGL drivers. You'll need to check with your hardware vendors specs to see what will be hardware accelerated. Robert. On Fri, May 30, 2008 at 2:16 PM, Viggo Løvli [EMAIL PROTECTED] wrote:Hi Robert, I modified my code as you suggested.The warning is gone :-) The framerate is now 10 seconds per frame instead of 30 frames per second.It does something.The texture I render to remains black (cleared to black). If I change the setInternalFormat to GL_RGBA then the framerate is up again,and the texture gets colors. This works, but then I only have 8 bit in thered channel. What I need is as many bits as possible in the red channel, preferably 32. And I do not need GBA channels.Do you have a suggestion for me on this one? Viggo Date: Fri, 30 May 2008 13:25:24 +0100From: [EMAIL PROTECTED]To: osg-users@lists.openscenegraph.orgSubject: Re: [osg-users] I get errors when trying to render to a luminancebuffer... Hi Viggo, The warning is exactly right, pbuffers don't suport multiple rendertargets, only FrameBufferObjects do. Perhaps what you intend it not to use multiple render targets, in which case you should set the Camera attachment to COLOR_BUFFER rather than COLOR_BUFFER0, that later tells the OSG that you want MRT and will be using glFragColor[] in your shaders. Also the Camera::setDrawBuffer(GL_COLOR_ATTACHMENT0_EXT) isinappropriate for pbuffers. Robert. On Fri, May 30, 2008 at 1:18 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I want to render to a floating point buffer, and I set things up like this: tex-setInternalFormat( GL_LUMINANCE16F_ARB ); tex-setSourceFormat( GL_RED ); tex-setSourceType( GL_FLOAT ); camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-attach( osg::Camera::BufferComponent(
Re: [osg-users] object shaking
Hi Peter,
One step that might be useful to you would be to break the main loop
out into its constuent parts i.e.
viewer.run();
becomes:
viewer.setCameraManipulator(new osgGA::TrackballManipulator);
viewer.realize();
while(!viewer.done())
{
viewer.advance();
viewer.eventTraversals();
viewer.updateTraversals(); /// update will set the camera's view
matrix from the CameraManipulator
// do your update stuff here
viewer.renderingTraversals();
}
This way you'll know that the camera is the same position that it'll
be rendered with, as this might well be the source of your jitter.
Robert.
On Mon, Jun 2, 2008 at 10:05 AM, Peter Wraae Marino [EMAIL PROTECTED] wrote:
Hi,
Ok.. I tried to make the example simple.. but perhaps I made it more
confusing. I'll try to explain what my end
result shoud have been.
I'm trying to create a grid that is always visible from the viewer. The grid
needs to scale at certain points when the
user zooms in/out.
The basic idea was to use an updatecallback on the PositionAttitudeTransform
so I can position and scale it accordinaly. The grid is currently being
tested on a plane XY and Z=0
To calculate the correct scaling of the grid to the current view, I need the
camera.
To calculate where the grid should be located I used the
osgManipulator::PlaneProjector to project a point from the center of the
view to our plane. This gives a position in the world where I can place the
grid (of course I will need to align the grid to an interval).
This is what I want to end up with.
So the first step was to position the grid and already something went wrong
there.. to me it looks like the camera
update and my updatecall back are out of sync.
Does this help?
Peter
On Mon, Jun 2, 2008 at 10:53 AM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Peter,
You callback is pretty odd, while I don't exactly know what you are
trying to do and why, whatever it is the callback you've written is
almost certainly not the way to do.
Could you take half a dozen steps back and then explain from a high
level what you are trying to do in your app then perhaps others can
spot the right way for you to do this.
Robert.
On Mon, Jun 2, 2008 at 9:47 AM, Peter Wraae Marino [EMAIL PROTECTED]
wrote:
Hi users,
I have a problem with my scene shaking. I have simplied the problem to
the
code below. A short description- the code find the position in the scene
where the center of screen is projected onto a plane. This position is
given
to a PositionAttitudeTransform so the box is transformed to that
position.
You will notice when the application starts it shakes. (why?)
You will also notice when panning the camera the scene shakes (why?)
anyone?,
Peter Wraae Marino
#include osgViewer/Viewer
#include osg/ShapeDrawable
#include osgManipulator/Projector
class CMyCallback : public osg::NodeCallback
{
public:
void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Camera* pCam = 0;
osg::Node* p = node;
while ( p )
{
pCam = dynamic_castosg::Camera*(p);
if ( pCam )
{
osg::PositionAttitudeTransform* pPat =
dynamic_castosg::PositionAttitudeTransform*(node);
osg::Plane plane( osg::Vec3(0,0,1), osg::Vec3(0,0,0) );
osg::ref_ptrosgManipulator::PlaneProjector rPlaneProj = new
osgManipulator::PlaneProjector;
rPlaneProj-setPlane( plane );
osg::Vec3 v;
osgManipulator::PointerInfo pi;
pi.reset();
pi.setCamera( pCam );
pi.setMousePosition( 256, 256 ); // center of 512x512 window
rPlaneProj-project( pi, v );
pPat-setPosition( v );
break;
}
p = p-getParent( 0 );
}
NodeCallback::traverse(node,nv);
}
};
osg::Node* CreateScene()
{
osg::PositionAttitudeTransform* pPat = new
osg::PositionAttitudeTransform;
osg::Geode* pGeode = new osg::Geode();
pGeode-addDrawable( new osg::ShapeDrawable( new
osg::Box(osg::Vec3(0.0f,0.0f,0.0f),2.0f) ) );
pPat-addChild( pGeode );
pPat-setUpdateCallback( new CMyCallback );
return pPat;
}
int _tmain(int argc, _TCHAR* argv[])
{
// construct the viewer
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
// make the viewer create a 512x512 window and position it at 32, 32
viewer-setUpViewInWindow( 32, 32, 512, 512 );
// set the scene-graph data the viewer will render
viewer-setSceneData( CreateScene() );
// execute main loop
return viewer-run();
}
___
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] Operation progress report from OSG Interactive operations
On Mon, Jun 2, 2008 at 11:46 AM, John Vidar Larring [EMAIL PROTECTED] wrote: Hi Robert, Could it be that I have compiled the OSG uses a release build and you've compiled debug, or not enabled the release build. Due to debugging etc. I went blind to the fact that I was doing the timing of the test application in debug mode. In release build the updated after vertical scaling took approx 4-6 secs. which is significantly less than 16 secs., however, a 1 second delay as you report would definitely be preferable. Differences in the models and hardware could make up the delta between what we've seen. Ideally we see real-time rates of update, i.e. change the vertical scale and see the result in the next frame without any frame drops - this is possible when using shaders, but this obvious requires lots of code changes. Making the existing code update the vertices and normals in response to vertical scale changes would be the next most efficient way to do it. However, I don't have either of these more advanced approaches in my schedule, so for the time being we'll just have to put with less than stellar performance when interactively updating the scale. Most apps won't ever touch the vertical scale so it's rather a niche requirement. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] object shaking
Hi,
Ok.. I tried to make the example simple.. but perhaps I made it more
confusing. I'll try to explain what my end
result shoud have been.
I'm trying to create a grid that is always visible from the viewer. The grid
needs to scale at certain points when the
user zooms in/out.
The basic idea was to use an updatecallback on the PositionAttitudeTransform
so I can position and scale it accordinaly. The grid is currently being
tested on a plane XY and Z=0
To calculate the correct scaling of the grid to the current view, I need the
camera.
To calculate where the grid should be located I used the
osgManipulator::PlaneProjector to project a point from the center of the
view to our plane. This gives a position in the world where I can place the
grid (of course I will need to align the grid to an interval).
This is what I want to end up with.
So the first step was to position the grid and already something went wrong
there.. to me it looks like the camera
update and my updatecall back are out of sync.
Does this help?
Peter
On Mon, Jun 2, 2008 at 10:53 AM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Peter,
You callback is pretty odd, while I don't exactly know what you are
trying to do and why, whatever it is the callback you've written is
almost certainly not the way to do.
Could you take half a dozen steps back and then explain from a high
level what you are trying to do in your app then perhaps others can
spot the right way for you to do this.
Robert.
On Mon, Jun 2, 2008 at 9:47 AM, Peter Wraae Marino [EMAIL PROTECTED]
wrote:
Hi users,
I have a problem with my scene shaking. I have simplied the problem to
the
code below. A short description- the code find the position in the scene
where the center of screen is projected onto a plane. This position is
given
to a PositionAttitudeTransform so the box is transformed to that
position.
You will notice when the application starts it shakes. (why?)
You will also notice when panning the camera the scene shakes (why?)
anyone?,
Peter Wraae Marino
#include osgViewer/Viewer
#include osg/ShapeDrawable
#include osgManipulator/Projector
class CMyCallback : public osg::NodeCallback
{
public:
void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Camera* pCam = 0;
osg::Node* p = node;
while ( p )
{
pCam = dynamic_castosg::Camera*(p);
if ( pCam )
{
osg::PositionAttitudeTransform* pPat =
dynamic_castosg::PositionAttitudeTransform*(node);
osg::Plane plane( osg::Vec3(0,0,1), osg::Vec3(0,0,0) );
osg::ref_ptrosgManipulator::PlaneProjector rPlaneProj = new
osgManipulator::PlaneProjector;
rPlaneProj-setPlane( plane );
osg::Vec3 v;
osgManipulator::PointerInfo pi;
pi.reset();
pi.setCamera( pCam );
pi.setMousePosition( 256, 256 ); // center of 512x512 window
rPlaneProj-project( pi, v );
pPat-setPosition( v );
break;
}
p = p-getParent( 0 );
}
NodeCallback::traverse(node,nv);
}
};
osg::Node* CreateScene()
{
osg::PositionAttitudeTransform* pPat = new
osg::PositionAttitudeTransform;
osg::Geode* pGeode = new osg::Geode();
pGeode-addDrawable( new osg::ShapeDrawable( new
osg::Box(osg::Vec3(0.0f,0.0f,0.0f),2.0f) ) );
pPat-addChild( pGeode );
pPat-setUpdateCallback( new CMyCallback );
return pPat;
}
int _tmain(int argc, _TCHAR* argv[])
{
// construct the viewer
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
// make the viewer create a 512x512 window and position it at 32, 32
viewer-setUpViewInWindow( 32, 32, 512, 512 );
// set the scene-graph data the viewer will render
viewer-setSceneData( CreateScene() );
// execute main loop
return viewer-run();
}
___
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] object shaking
Hi Robert, Thanks for all your advice, really do appreciate it. As you mentioned the camera needs to finish it's update traversal, so I decided to try the cull-callback which should be called after all updates have been done but the scene still shakes when using the cull-callback and this kinda baffles me. any suggestions why? regards, Peter On Mon, Jun 2, 2008 at 12:40 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Peter, On Mon, Jun 2, 2008 at 10:52 AM, Peter Wraae Marino [EMAIL PROTECTED] wrote: Also I understand why this works, but don't really approve of it because it makes my code more hardcoded because I need to implement a direct update call after viewer-updateTraversal() which is kinda breaking the whole framework that osg is built for. For example if at a later point you decide to add another traversal then I will have to manually add it here myself. Also anyone using my code will have to break their main loop to handle the grid example. Adding your own custom update code into the frame loop is perfectly normal OSG usage, it's not breaking anything w.r.t the OSG framework - the frame loop is constructed this way deliberately so that unusual usage requirements can be met easily. Isn't there a method to make sure my updatecallback is called after the camera has done it's stuff? There is no option for configuring when the camera update is done, it's implemented to work the way most users will require it, but... osgViewer::ViewBase has virtual functions for updateTraversals() etc so you can customize it to do what you required, or just roll your own frame loop. Which route you take is up to you - either is perfectly reasonable and intended usage of the OSG. Robert. ___ 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] object shaking
Hi Peter,
You callback is pretty odd, while I don't exactly know what you are
trying to do and why, whatever it is the callback you've written is
almost certainly not the way to do.
Could you take half a dozen steps back and then explain from a high
level what you are trying to do in your app then perhaps others can
spot the right way for you to do this.
Robert.
On Mon, Jun 2, 2008 at 9:47 AM, Peter Wraae Marino [EMAIL PROTECTED] wrote:
Hi users,
I have a problem with my scene shaking. I have simplied the problem to the
code below. A short description- the code find the position in the scene
where the center of screen is projected onto a plane. This position is given
to a PositionAttitudeTransform so the box is transformed to that position.
You will notice when the application starts it shakes. (why?)
You will also notice when panning the camera the scene shakes (why?)
anyone?,
Peter Wraae Marino
#include osgViewer/Viewer
#include osg/ShapeDrawable
#include osgManipulator/Projector
class CMyCallback : public osg::NodeCallback
{
public:
void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Camera* pCam = 0;
osg::Node* p = node;
while ( p )
{
pCam = dynamic_castosg::Camera*(p);
if ( pCam )
{
osg::PositionAttitudeTransform* pPat =
dynamic_castosg::PositionAttitudeTransform*(node);
osg::Plane plane( osg::Vec3(0,0,1), osg::Vec3(0,0,0) );
osg::ref_ptrosgManipulator::PlaneProjector rPlaneProj = new
osgManipulator::PlaneProjector;
rPlaneProj-setPlane( plane );
osg::Vec3 v;
osgManipulator::PointerInfo pi;
pi.reset();
pi.setCamera( pCam );
pi.setMousePosition( 256, 256 ); // center of 512x512 window
rPlaneProj-project( pi, v );
pPat-setPosition( v );
break;
}
p = p-getParent( 0 );
}
NodeCallback::traverse(node,nv);
}
};
osg::Node* CreateScene()
{
osg::PositionAttitudeTransform* pPat = new osg::PositionAttitudeTransform;
osg::Geode* pGeode = new osg::Geode();
pGeode-addDrawable( new osg::ShapeDrawable( new
osg::Box(osg::Vec3(0.0f,0.0f,0.0f),2.0f) ) );
pPat-addChild( pGeode );
pPat-setUpdateCallback( new CMyCallback );
return pPat;
}
int _tmain(int argc, _TCHAR* argv[])
{
// construct the viewer
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
// make the viewer create a 512x512 window and position it at 32, 32
viewer-setUpViewInWindow( 32, 32, 512, 512 );
// set the scene-graph data the viewer will render
viewer-setSceneData( CreateScene() );
// execute main loop
return viewer-run();
}
___
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] object shaking
Hi Peter, On Mon, Jun 2, 2008 at 10:52 AM, Peter Wraae Marino [EMAIL PROTECTED] wrote: Also I understand why this works, but don't really approve of it because it makes my code more hardcoded because I need to implement a direct update call after viewer-updateTraversal() which is kinda breaking the whole framework that osg is built for. For example if at a later point you decide to add another traversal then I will have to manually add it here myself. Also anyone using my code will have to break their main loop to handle the grid example. Adding your own custom update code into the frame loop is perfectly normal OSG usage, it's not breaking anything w.r.t the OSG framework - the frame loop is constructed this way deliberately so that unusual usage requirements can be met easily. Isn't there a method to make sure my updatecallback is called after the camera has done it's stuff? There is no option for configuring when the camera update is done, it's implemented to work the way most users will require it, but... osgViewer::ViewBase has virtual functions for updateTraversals() etc so you can customize it to do what you required, or just roll your own frame loop. Which route you take is up to you - either is perfectly reasonable and intended usage of the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] object shaking
On Mon, Jun 2, 2008 at 12:42 PM, Peter Wraae Marino [EMAIL PROTECTED] wrote: Hi Robert, Thanks for all your advice, really do appreciate it. As you mentioned the camera needs to finish it's update traversal, so I decided to try the cull-callback which should be called after all updates have been done but the scene still shakes when using the cull-callback and this kinda baffles me. The cull traversal is not a good place to modify the scene graph as the OSG's threading model is set up to allow multi-thread cull and draw, so modifying the scene graph during is only permitted when your run single threaded. You have a solution, why not just stick with it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Operation progress report from OSG Interactive operations
Hi Robert, Could it be that I have compiled the OSG uses a release build and you've compiled debug, or not enabled the release build. Due to debugging etc. I went blind to the fact that I was doing the timing of the test application in debug mode. In release build the updated after vertical scaling took approx 4-6 secs. which is significantly less than 16 secs., however, a 1 second delay as you report would definitely be preferable. Best regards, John Robert Osfield wrote: Hi John, On Fri, May 30, 2008 at 10:24 AM, John Vidar Larring [EMAIL PROTECTED] wrote: Please excuse my ignorance, but osgdem produces pagedLOD databases per default, doesn't it? At least, the top node of my terrain database start out like this: Yes by default VPB creates paged databases. You're ascii except confirms that you have a paged database too, so... we need next to look at why 1 sec. vs. 16 sec. makes a big difference! OK, I am running my tests on a laptop, but it has the following specs: Intel Duo T7300, GeForce 8600m GT 512MB, 2GB Memory, running CentOS 4.6 (a.k.a RHEL 4). So unless you've spent a fortune on hardware, I don't think hardware differences alone can explain the difference. What could potentially contribute to this difference in update time. Any ideas? I have a Intel quad core 2.4GHz machine with 4GB of memory and a 7800GT. The update is done single threaded in this case so the extra cores should make no difference. Could it be that I have compiled the OSG uses a release build and you've compiled debug, or not enabled the release build. If you run ccmake . or cmake . for the first time instead of ./configure it'll not enable the release build, so perhaps this has caught you out. Unfortunately I haven't spotted a way of forcing cmake to default to release build, so I wrote the ./configure script to enable the release build. Have a look at the script it's just a one liner. FYI, the thing that will be taking all the time in the generation will be the display lists/texture object update. Making osgTerrain a bit more intelligent about it's updates it would be possible to just update the existing vertices and normals when changing the scale, something that would be much cheaper. The dirty/update mechinism would have to be alot more sophisticated though. Long term this is where osgTerrain is heading, right now its very much in its infancy. Thanks, this is very useful information. I'll see what I might figure out when, and if, I get the time. But I'll certainly keep a watchful eye on any VPB svn updates;) The suggested changes to osgTerrain are unrelated to changes to VPB, so it's osgTerrain itself you'll want to keep a watchful eye on in addition to VPB which itself will have its own development path. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Best regards, John WeatherOne -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] object shaking
Hi users,
I have a problem with my scene shaking. I have simplied the problem to the
code below. A short description- the code find the position in the scene
where the center of screen is projected onto a plane. This position is given
to a PositionAttitudeTransform so the box is transformed to that position.
You will notice when the application starts it shakes. (why?)
You will also notice when panning the camera the scene shakes (why?)
anyone?,
Peter Wraae Marino
#include osgViewer/Viewer
#include osg/ShapeDrawable
#include osgManipulator/Projector
class CMyCallback : public osg::NodeCallback
{
public:
void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Camera* pCam = 0;
osg::Node* p = node;
while ( p )
{
pCam = dynamic_castosg::Camera*(p);
if ( pCam )
{
osg::PositionAttitudeTransform* pPat =
dynamic_castosg::PositionAttitudeTransform*(node);
osg::Plane plane( osg::Vec3(0,0,1), osg::Vec3(0,0,0) );
osg::ref_ptrosgManipulator::PlaneProjector rPlaneProj = new
osgManipulator::PlaneProjector;
rPlaneProj-setPlane( plane );
osg::Vec3 v;
osgManipulator::PointerInfo pi;
pi.reset();
pi.setCamera( pCam );
pi.setMousePosition( 256, 256 ); // center of 512x512 window
rPlaneProj-project( pi, v );
pPat-setPosition( v );
break;
}
p = p-getParent( 0 );
}
NodeCallback::traverse(node,nv);
}
};
osg::Node* CreateScene()
{
osg::PositionAttitudeTransform* pPat = new osg::PositionAttitudeTransform;
osg::Geode* pGeode = new osg::Geode();
pGeode-addDrawable( new osg::ShapeDrawable( new
osg::Box(osg::Vec3(0.0f,0.0f,0.0f),2.0f) ) );
pPat-addChild( pGeode );
pPat-setUpdateCallback( new CMyCallback );
return pPat;
}
int _tmain(int argc, _TCHAR* argv[])
{
// construct the viewer
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
// make the viewer create a 512x512 window and position it at 32, 32
viewer-setUpViewInWindow( 32, 32, 512, 512 );
// set the scene-graph data the viewer will render
viewer-setSceneData( CreateScene() );
// execute main loop
return viewer-run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] object shaking
Hi Robert,
I tried your suggestion and yes it does work, the panning of the camera
doesn't shake the scene anymore. .. but the startup position of the camera
is shaking?
Also I understand why this works, but don't really approve of it because it
makes my code more hardcoded because I need to implement a direct update
call after viewer-updateTraversal() which is kinda breaking the whole
framework that osg is built for. For example if at a later point you decide
to add another traversal then I will have to manually add it here myself.
Also anyone using my code will have to break their main loop to handle the
grid example.
Isn't there a method to make sure my updatecallback is called after the
camera has done it's stuff?
regards,
Peter
On Mon, Jun 2, 2008 at 11:22 AM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Peter,
One step that might be useful to you would be to break the main loop
out into its constuent parts i.e.
viewer.run();
becomes:
viewer.setCameraManipulator(new osgGA::TrackballManipulator);
viewer.realize();
while(!viewer.done())
{
viewer.advance();
viewer.eventTraversals();
viewer.updateTraversals(); /// update will set the camera's view
matrix from the CameraManipulator
// do your update stuff here
viewer.renderingTraversals();
}
This way you'll know that the camera is the same position that it'll
be rendered with, as this might well be the source of your jitter.
Robert.
On Mon, Jun 2, 2008 at 10:05 AM, Peter Wraae Marino [EMAIL PROTECTED]
wrote:
Hi,
Ok.. I tried to make the example simple.. but perhaps I made it more
confusing. I'll try to explain what my end
result shoud have been.
I'm trying to create a grid that is always visible from the viewer. The
grid
needs to scale at certain points when the
user zooms in/out.
The basic idea was to use an updatecallback on the
PositionAttitudeTransform
so I can position and scale it accordinaly. The grid is currently being
tested on a plane XY and Z=0
To calculate the correct scaling of the grid to the current view, I need
the
camera.
To calculate where the grid should be located I used the
osgManipulator::PlaneProjector to project a point from the center of the
view to our plane. This gives a position in the world where I can place
the
grid (of course I will need to align the grid to an interval).
This is what I want to end up with.
So the first step was to position the grid and already something went
wrong
there.. to me it looks like the camera
update and my updatecall back are out of sync.
Does this help?
Peter
On Mon, Jun 2, 2008 at 10:53 AM, Robert Osfield
[EMAIL PROTECTED]
wrote:
Hi Peter,
You callback is pretty odd, while I don't exactly know what you are
trying to do and why, whatever it is the callback you've written is
almost certainly not the way to do.
Could you take half a dozen steps back and then explain from a high
level what you are trying to do in your app then perhaps others can
spot the right way for you to do this.
Robert.
On Mon, Jun 2, 2008 at 9:47 AM, Peter Wraae Marino [EMAIL PROTECTED]
wrote:
Hi users,
I have a problem with my scene shaking. I have simplied the problem to
the
code below. A short description- the code find the position in the
scene
where the center of screen is projected onto a plane. This position is
given
to a PositionAttitudeTransform so the box is transformed to that
position.
You will notice when the application starts it shakes. (why?)
You will also notice when panning the camera the scene shakes (why?)
anyone?,
Peter Wraae Marino
#include osgViewer/Viewer
#include osg/ShapeDrawable
#include osgManipulator/Projector
class CMyCallback : public osg::NodeCallback
{
public:
void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Camera* pCam = 0;
osg::Node* p = node;
while ( p )
{
pCam = dynamic_castosg::Camera*(p);
if ( pCam )
{
osg::PositionAttitudeTransform* pPat =
dynamic_castosg::PositionAttitudeTransform*(node);
osg::Plane plane( osg::Vec3(0,0,1), osg::Vec3(0,0,0) );
osg::ref_ptrosgManipulator::PlaneProjector rPlaneProj = new
osgManipulator::PlaneProjector;
rPlaneProj-setPlane( plane );
osg::Vec3 v;
osgManipulator::PointerInfo pi;
pi.reset();
pi.setCamera( pCam );
pi.setMousePosition( 256, 256 ); // center of 512x512 window
rPlaneProj-project( pi, v );
pPat-setPosition( v );
break;
}
p = p-getParent( 0 );
}
NodeCallback::traverse(node,nv);
}
};
osg::Node* CreateScene()
{
osg::PositionAttitudeTransform* pPat = new
osg::PositionAttitudeTransform;
osg::Geode* pGeode = new osg::Geode();
pGeode-addDrawable( new osg::ShapeDrawable( new
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Hello, Category: FBO, blending, H/W I don't understand exactly what do you mean but H/W blending with float is not supported. I know for sure that we render particle effect with transparency to float (16bit) FBO, and get the correct results. We also get that with a decent frame rate (100-200Hz depending on the number of particles). So I've the feeling that I didn't understand what you mean be blend. Our H/W is nVIDIA 8800 driver 6.14.11.6921 osg2.0 I think :-) I'd appreciate if you clarify your problem. Thanks, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viggo L?vli Sent: Monday, June 02, 2008 11:29 AM To: OpenSceneGraph Users Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi again :-) I abandoned the idea of using a floating point buffer. I went into the thinking box and came to the same conclusion as you wrote about in the end of your comment. I needed a quite high resolution so I decided to use all 4 channels (RGBA). The numbers I want to accumulate is seldom large, so I needed most resolution in the lower scale. I thus decided to use RGBA where R is most significant and A is least significant. Bit usage is: R = 6 bits G = 5 bits B = 4 bits A = 3 bits All non used bits will overlap with next channel. I am using this to generate a pixel weight when rendering many volumetric clouds on top of each other on screen. Naturally most overlapping clouds will be further away from camera, so I needed as high a number of overlap bits on the lest significant buffers that I could get. My usage accepts in worst case 32 overlapping pixels with maximum weight (in the distance). I think that is something I can live with :-) Anyhow, I got a range (18 bit) that was good enough for my usage and it gives a decent cloud sorting for clouds seen up to 40 kilometers away. I must stress one point: - If you ever try using the alpha channel for this then remember to turn off alpha-clipping (set alpha-func to always). Viggo Date: Mon, 2 Jun 2008 10:05:24 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi, Viggo Løvli wrote: Ok, that make sense. It happens every time I render with a floating point texture. The fall in framerate does not happen when I run the OSG multi render target example using HDR. My code does however use additive blending toward the floating point texture so I bet that is what cause it to fall into a software rendering mode. We have also experienced this slowdown when blending was enabled with float textures. Testing on newer cards is pending as we cannot figure out from docs on the internet if this is actually supported in current hardware at all. Seems like DX10.1 mandates float blending, but we will test to make sure. Please let me know if you know if it is supported in hardware. Do you know about any texture surface bit format that is more than 8 bits (unsigned integer) ? I don't know of any. I've only seen a paper once where people were using three channels to simulate one large channel. The RGB channels were partially overlapped to create a higher dynamic range channel. jp Viggo Date: Fri, 30 May 2008 16:29:05 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, When performance drops like this it's because you've dropped onto a software fallback path in the OpenGL driver. Exactly what formats are software vs hardware depends upon the hardware and OpenGL drivers. You'll need to check with your hardware vendors specs to see what will be hardware accelerated. Robert. On Fri, May 30, 2008 at 2:16 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, I modified my code as you suggested. The warning is gone :-) The framerate is now 10 seconds per frame instead of 30 frames per second. It does something. The texture I render to remains black (cleared to black). If I change the setInternalFormat to GL_RGBA then the framerate is up again, and the texture gets colors. This works, but then I only have 8 bit in the red channel. What I need is as many bits as possible in the red channel, preferably 32. And I do not need GBA channels. Do you have a suggestion for me on this one? Viggo Date: Fri, 30 May 2008 13:25:24 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, The warning is exactly right, pbuffers don't suport multiple render targets, only FrameBufferObjects do. Perhaps
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Hi, (I'm not the guy with the original problem, just interested...) Guy wrote: Hello, Category: FBO, blending, H/W I don't understand exactly what do you mean but H/W blending with float is not supported. I know for sure that we render particle effect with transparency to float (16bit) FBO, and get the correct results. We also get that with a decent frame rate (100-200Hz depending on the number of particles). I'm interested in transparency with 32bit floats (alpha blending). Have you tested that? I would like to know if it is supported in hardware. So I've the feeling that I didn't understand what you mean be blend. Our H/W is nVIDIA 8800 driver 6.14.11.6921 osg2.0 I think J I'd appreciate if you clarify your problem. Thanks, Guy. jp *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Viggo L?vli *Sent:* Monday, June 02, 2008 11:29 AM *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi again :-) I abandoned the idea of using a floating point buffer. I went into the thinking box and came to the same conclusion as you wrote about in the end of your comment. I needed a quite high resolution so I decided to use all 4 channels (RGBA). The numbers I want to accumulate is seldom large, so I needed most resolution in the lower scale. I thus decided to use RGBA where R is most significant and A is least significant. Bit usage is: R = 6 bits G = 5 bits B = 4 bits A = 3 bits All non used bits will overlap with next channel. I am using this to generate a pixel weight when rendering many volumetric clouds on top of each other on screen. Naturally most overlapping clouds will be further away from camera, so I needed as high a number of overlap bits on the lest significant buffers that I could get. My usage accepts in worst case 32 overlapping pixels with maximum weight (in the distance). I think that is something I can live with :-) Anyhow, I got a range (18 bit) that was good enough for my usage and it gives a decent cloud sorting for clouds seen up to 40 kilometers away. I must stress one point: - If you ever try using the alpha channel for this then remember to turn off alpha-clipping (set alpha-func to always). Viggo Date: Mon, 2 Jun 2008 10:05:24 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi, Viggo Løvli wrote: Ok, that make sense. It happens every time I render with a floating point texture. The fall in framerate does not happen when I run the OSG multi render target example using HDR. My code does however use additive blending toward the floating point texture so I bet that is what cause it to fall into a software rendering mode. We have also experienced this slowdown when blending was enabled with float textures. Testing on newer cards is pending as we cannot figure out from docs on the internet if this is actually supported in current hardware at all. Seems like DX10.1 mandates float blending, but we will test to make sure. Please let me know if you know if it is supported in hardware. Do you know about any texture surface bit format that is more than 8 bits (unsigned integer) ? I don't know of any. I've only seen a paper once where people were using three channels to simulate one large channel. The RGB channels were partially overlapped to create a higher dynamic range channel. jp Viggo Date: Fri, 30 May 2008 16:29:05 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, When performance drops like this it's because you've dropped onto a software fallback path in the OpenGL driver. Exactly what formats are software vs hardware depends upon the hardware and OpenGL drivers. You'll need to check with your hardware vendors specs to see what will be hardware accelerated. Robert. On Fri, May 30, 2008 at 2:16 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, I modified my code as you suggested. The warning is gone :-) The framerate is now 10 seconds per frame instead of 30 frames per second. It does something. The texture I render to remains black (cleared to black). If I change the setInternalFormat to GL_RGBA then the framerate is up again, and the texture gets colors. This works, but then I only have 8 bit in the red channel. What I need is as many bits as possible in the red channel, preferably 32. And I do not need GBA channels. Do you have a suggestion for me on this one? Viggo Date: Fri, 30 May 2008 13:25:24 +0100 From: [EMAIL PROTECTED] To:
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Jean-Sébastien Guay wrote: Hi Robert, Another aspect to the OpenSceneGraph development cycle is that while quite a few users do track SVN and developer releases not everyone does - many users wait till stable releases come out. Yes, and that coupled with the fact that 2.0 and 2.2 have not had any point releases (x.y.1,2,3...) means that people are generally a bit further behind the SVN curve than they could be. In 2.x that hasn't mattered that much because the API hasn't changed much apart from new features being added (compared to the 1.2 - 2.0 switch), but it means that people will often have local fixes to the OSG code base that they've been using on top of whichever stable release they were using, while waiting for the next stable release. This makes it a bit harder to make the switch when the stable release eventually comes out... So I think in addition to all you said in the previous message (and with which I agree), making a few point releases between stable releases would help people keep up to date more easily. Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: * osg::Camera::setIntialDrawCallback - setInitialDrawCallback * osg::NodeVisitor::requestNodeFile gained an argument databaseRequest * osg::Texture2DArray::applyTexImage2DArray_subload, some arguments are no longer passed by reference * osgDB::DatabasePager no longer derives from OpenThreads::Thread and some methods have changes to parameters. This class seems to have the largest amount of changes. * osgShadow::ParallelSplitShadowMap, forceFrontCullFace() removed * Small changes to osgTerrain::TerrainTile and friends * osgUtil::LineSegmentIntersector::setEnd() - getEnd() So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis [EMAIL PROTECTED] wrote: Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: ... So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting a list of all textures (including the ones used by particle systems) in a scenegraph
Hi all,
I have a requirement to build a list of all textures used in a scene graph.
For this purpose, I have used a NodeVisitor derived class with the apply
function given below.
Problem: I am not able to get the details of textures used by the attached
Particle systems. I would be very grateful if someone can help with some hints
/ pointers.
Regards
Harash
Apply Function:
void
{
osg::Node* Ptr = searchNode;
osg::StateSet* state = Ptr-getStateSet();
FindTextureVisitor::apply(osg::Node searchNode) // get the state set for the
node osg::StateSet::TextureAttributeList Attr; // Attr =
state-getTextureAttributeList(); if(state != NULL) { intSz =
Attr.size(); // for all the attributes, find the ones related to
texture osg::ref_ptrosg::Texture texture =
(j,osg::StateAttribute::TEXTURE)); // if a texture is found
{ if(texture.valid()) // This is a valuable node
containing texture foundNodeList.push_back(searchNode);
// also store the Texture object related to this node so we
// don't have to repeat the call to get Texture attribute List
foundTextureList.push_back(texture); // Now search if the
texture has already been used by an earlier node // get the
image related to the texture osg::ref_ptrosg::Image texImage =
texture-getImage(0); // check if it is already in the list
std::string filename = texImage-getFileName();
intTexSz = foundImageList.size(); // TextureList.size();
flag =
}
} boolflag = true; for(intk = 0;
k TexSz; k++) { if(foundImageList[k]-getFileName() ==
filename) {false; break; if(flag) {
// No it is not on the List
foundImageList.push_back(texImage);
}
}
}
}
traverse(searchNode);
} // add it to the node list for(intj = 0; j Sz; j++)
{dynamic_castosg::Texture*(state-getTextureAttribute
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Well, I can't seem to reproduce it for simple cases today (though I thought I had last week), so that tells me that I probably have a separate dependency that was compiled with iterator debugging opposite of how I have my code. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Saturday, May 31, 2008 2:20 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL,Slow Performance, and getFileExtension bug On Fri, May 30, 2008 at 10:55 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Steve, If you don't want to be bored by the details, it basically says that VC8 VC9 have a bug when Iterator Debugging is turned off with regards to iterator copying, and that Microsoft doesn't intend to address it until VC10. In my specific case, that bug causes an assertion at the return statement of getFileExtension(). Strange, we are using OSG 2.2 and 2.4 with iterator debugging turned off in our apps, and I have never seen this. I'll investigate a bit more on Monday, this is intriguing... I wonder if this might be the reason why the new DatabasePager was crashing in debug build under Windows... Robert. ___ 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] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Robert Osfield wrote: Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis [EMAIL PROTECTED] wrote: Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: ... So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. Would there be a single stable branch and one development one? I.e. when 2.6 would come out it would supersede 2.4? What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) Hmmm, that kind of defeats the purpose of making a 2.4.1 release, if it's actually just 2.5.1 with a different number, as that _would_ include (minor) API changes. If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. But that doesn't really solve this on the long term, does it. To be able to have easily manageable stable branches would mean branching the trunk just before a new minor stable release and then backporting fixes and small additions from the trunk to work up to each new point release on the stable branch. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Category: FBO, blending, H/W Well, I run a different setting from the previous one I mentioned. I use osg 1.2 (yeah yeah, I promise to upgrade soon). I haven't integrated particle system to my application but I use 1 big billboard with transparency. Until now my FBO cameras used GL_RGBA16F_ARB textures, and also the texture for the billboard was GL_RGBA16F_ARB. I just changed all of them to GL_RGBA32F_ARB and the scene renders correctly. (with transparency). I haven't tried to save the frames to files and check the precision so I've no way to know if the driver didn't fall back to half-float, but I don't believe it would do that anyhow. I'd excpect that if there were troubles they would be the same as yours. But I get solid frame rate of 80+ Hz. (just as before I added the billboard with the blending mode to the scene). Again, I work with nVIDIA 8800 GT, driver 6.14.11.6921, on windows XP. Do you want to send me .osg scenes, or code that I'll test on my machine? Maybe you ment GL_LUMINANCE_ALPHA32F_ARB format? If so tell me how to set it up instead of the RGBA format and I'll try it. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Monday, June 02, 2008 2:22 PM To: OpenSceneGraph Users Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi, (I'm not the guy with the original problem, just interested...) Guy wrote: Hello, Category: FBO, blending, H/W I don't understand exactly what do you mean but H/W blending with float is not supported. I know for sure that we render particle effect with transparency to float (16bit) FBO, and get the correct results. We also get that with a decent frame rate (100-200Hz depending on the number of particles). I'm interested in transparency with 32bit floats (alpha blending). Have you tested that? I would like to know if it is supported in hardware. So I've the feeling that I didn't understand what you mean be blend. Our H/W is nVIDIA 8800 driver 6.14.11.6921 osg2.0 I think J I'd appreciate if you clarify your problem. Thanks, Guy. jp *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Viggo L?vli *Sent:* Monday, June 02, 2008 11:29 AM *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi again :-) I abandoned the idea of using a floating point buffer. I went into the thinking box and came to the same conclusion as you wrote about in the end of your comment. I needed a quite high resolution so I decided to use all 4 channels (RGBA). The numbers I want to accumulate is seldom large, so I needed most resolution in the lower scale. I thus decided to use RGBA where R is most significant and A is least significant. Bit usage is: R = 6 bits G = 5 bits B = 4 bits A = 3 bits All non used bits will overlap with next channel. I am using this to generate a pixel weight when rendering many volumetric clouds on top of each other on screen. Naturally most overlapping clouds will be further away from camera, so I needed as high a number of overlap bits on the lest significant buffers that I could get. My usage accepts in worst case 32 overlapping pixels with maximum weight (in the distance). I think that is something I can live with :-) Anyhow, I got a range (18 bit) that was good enough for my usage and it gives a decent cloud sorting for clouds seen up to 40 kilometers away. I must stress one point: - If you ever try using the alpha channel for this then remember to turn off alpha-clipping (set alpha-func to always). Viggo Date: Mon, 2 Jun 2008 10:05:24 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi, Viggo Løvli wrote: Ok, that make sense. It happens every time I render with a floating point texture. The fall in framerate does not happen when I run the OSG multi render target example using HDR. My code does however use additive blending toward the floating point texture so I bet that is what cause it to fall into a software rendering mode. We have also experienced this slowdown when blending was enabled with float textures. Testing on newer cards is pending as we cannot figure out from docs on the internet if this is actually supported in current hardware at all. Seems like DX10.1 mandates float blending, but we will test to make sure. Please let me know if you know if it is supported in hardware. Do you know about any texture surface bit format that is more than 8 bits (unsigned integer) ? I don't know of any. I've only seen a paper once where people were using three channels to simulate one
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
On Mon, Jun 2, 2008 at 2:34 PM, Paul Melis [EMAIL PROTECTED] wrote: Would there be a single stable branch and one development one? I.e. when 2.6 would come out it would supersede 2.4? Each stable series would be independent. A new stable release such as 2.6.0 would become the main stable branch and it's own series but it wouldn't replace 2.4.0 and it's own series. I'd imagine that users might still want to fixes applied to a previous stable release if that's the version that their app is shipping against, so a 2.4.1 could come out, then 2.6.0, then another patch to 2.4 would bring it to 2.4.2, then later patch to 2.6.0 would bring its own series to 2.6.1. If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. But that doesn't really solve this on the long term, does it. This discussion is looking to what we might need to do to solve the long term maintenance of stable releases, as well as the immediate case of what to do about 2.4.1. Right now we have no formal system for maintaining stable releases, as long as we start moving towards some system then I'm happy, but we have to start moving in this direction even if we just take baby steps. To be able to have easily manageable stable branches would mean branching the trunk just before a new minor stable release and then backporting fixes and small additions from the trunk to work up to each new point release on the stable branch. I'd suggest that a 2.6.x series starts with 2.6.0 and branches this to make the base for 2.6.1, then this branch gets patches applied to it from trunk or perhaps separate patches that trunk won't have. It might be that trunk then takes fixes from these branches. For the 2.4.x series we either use the 2.4.0 branch as a base, or 2.5.1 or trunk. The horse has bolted a bit already on the 2.4 series as we are already into the 2.5.x developer series so it's a bit of unusual situation - the proposed system of stable developer series maintenance is rather late coming. I don't mind if the 2.4.x gets off to a bit of ad-hoc start, its better that it gets off to start than to just die a death as just another nice idea that no-one had time to make happen. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] avoid Esc key on keyboard
Hi Eric, As the compiler said, the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool) method is not static, so just call it from your osgProducer viewer object (viewer-setEscapeSetDone(false)) and it should work. Cheers, On Mon, Jun 2, 2008 at 4:57 PM, Eric Pouliquen [EMAIL PROTECTED] wrote: Hi, i'm using OSG 1.2 on an old project, and i want to switch off the default Esc key behavior (exiting my application). This project uses a osgProducer::viewer, and i created a class herited of GUIeventHandler to manage mouse and keyboard events. I can manage all keys except the 'Esc' key... Someone said to look at the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool), i see in it in the corresponding code, but how can i use it (a simple call causes an error due to non static style of the function) in my app ? I tried to manage the Esc key in the handle function, returning true, and pushing front the handler in the eventHandlerList, but it doesn't work. Help :) Robert Osfield a écrit : Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis [EMAIL PROTECTED] wrote: Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: ... So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- Eric Pouliquen === Silicon Worlds S.A. 224 rue St Denis 75002 Paris France Tel: +33 (0) 1 53.90.11.13 Fax: +33 (0) 1 53.90.11.12 www.silicon-worlds.fr === ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Hi Robert, Robert Osfield wrote: On Mon, Jun 2, 2008 at 2:34 PM, Paul Melis [EMAIL PROTECTED] wrote: Would there be a single stable branch and one development one? I.e. when 2.6 would come out it would supersede 2.4? Each stable series would be independent. A new stable release such as 2.6.0 would become the main stable branch and it's own series but it wouldn't replace 2.4.0 and it's own series. I'd imagine that users might still want to fixes applied to a previous stable release if that's the version that their app is shipping against, so a 2.4.1 could come out, then 2.6.0, then another patch to 2.4 would bring it to 2.4.2, then later patch to 2.6.0 would bring its own series to 2.6.1. Ok If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. But that doesn't really solve this on the long term, does it. This discussion is looking to what we might need to do to solve the long term maintenance of stable releases, as well as the immediate case of what to do about 2.4.1. Right now we have no formal system for maintaining stable releases, as long as we start moving towards some system then I'm happy, but we have to start moving in this direction even if we just take baby steps. To be able to have easily manageable stable branches would mean branching the trunk just before a new minor stable release and then backporting fixes and small additions from the trunk to work up to each new point release on the stable branch. I'd suggest that a 2.6.x series starts with 2.6.0 and branches this to make the base for 2.6.1, then this branch gets patches applied to it from trunk or perhaps separate patches that trunk won't have. Why not branch to _create_ the 2.6.x series, instead of branching _after_ 2.6.0? The former is far more commonplace. It might be that trunk then takes fixes from these branches. Possibly, but the other way around (merge from trunk - branch) is the usual way of doing it. The assumption is that the majority of development happens on the trunk, and therefore the majority of interesting stuff to backport is there also. Although it's perfectly possible to merge back and forth, of course. For the 2.4.x series we either use the 2.4.0 branch as a base, or 2.5.1 or trunk. The horse has bolted a bit already on the 2.4 series as we are already into the 2.5.x developer series so it's a bit of unusual situation - the proposed system of stable developer series maintenance is rather late coming. As the differences between 2.4 and SVN are still small now is the time to start the process... I'm willing to help to backport fixes and other things from trunk to the 2.4 branch. I can't tell you at this moment if this would be a long-term commitment, though. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] avoid Esc key on keyboard
Hi, i'm using OSG 1.2 on an old project, and i want to switch off the default Esc key behavior (exiting my application). This project uses a osgProducer::viewer, and i created a class herited of GUIeventHandler to manage mouse and keyboard events. I can manage all keys except the 'Esc' key... Someone said to look at the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool), i see in it in the corresponding code, but how can i use it (a simple call causes an error due to non static style of the function) in my app ? I tried to manage the Esc key in the handle function, returning true, and pushing front the handler in the eventHandlerList, but it doesn't work. Help :) Robert Osfield a écrit : Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis [EMAIL PROTECTED] wrote: Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: ... So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- Eric Pouliquen === Silicon Worlds S.A. 224 rue St Denis 75002 Paris France Tel: +33 (0) 1 53.90.11.13 Fax: +33 (0) 1 53.90.11.12 www.silicon-worlds.fr === ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
Hi Paul, On Mon, Jun 2, 2008 at 4:03 PM, Paul Melis [EMAIL PROTECTED] wrote: Why not branch to _create_ the 2.6.x series, instead of branching _after_ 2.6.0? The former is far more commonplace. The system since the 1.9.x dev series has been that we tag when ready to officially make a release, with the 1.9.x series converging towards a point when 2.0.0, using the last few dev releases as release candidates, and finally the trunk was in good enough state to have 2.0.0 tagged from SVN trunk. The other approach, which you suggest, is rather than use the dev releases as release candidates, branch a stable release when we get to a feature freeze period and then make release candidates based on this branch. The final official release would then bee a branch + a revision number than holds the particular release in a point in time. When moving to having maintainence releases of a stable series using dev series as pre releases doesn't work, as the dev series already heads off in towards then next major stable point release. So... now we a proposing the stable maintaince releases then we need to move to a new system - branch first then stabilising this code base in readiness for a 2.4.1, 2.4.2 seems like the way to go from here on out. For 2.6.0, it'd suggest we use SVN trunk/later 2.5.x dev series as pre releases of 2.6.0 get things tested enough to know we are roughly in the right ball park functionality/quality wise, then copy trunk across to a 2.6.0 branch and then use this as the base of release candidate series before the final 2.6.0. Once the 2.6.0 branch happens the stable release maintainer would then become actively involved in shepherding the code base to its eventual official release. As the differences between 2.4 and SVN are still small now is the time to start the process... I'm willing to help to backport fixes and other things from trunk to the 2.4 branch. I can't tell you at this moment if this would be a long-term commitment, though. I think it'd be hard for anyone to sign up long term to something, taking short term responsibility won't be a problem as long as we all follow a set of systems that are published and adhered too/use the same scripts/tools - so others can easily drop in to help out when others move on/are away on holiday. Right now we don't have all the systems published/scripts etc, so it'd be a case of documenting as we go along. First step is to find a set of volunteers who are willing to going along this journey, get them write access to making branches of the OSG. It might even be worth having a scratch pad set of branches that we can new maintainers can experiment with. I'm open to suggestions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] correct manual shutdown of osg libraries
Could you explain what you've done in more fine grained steps so that others will be able to understand what approach you've taken so that when they try the same thing they don't need to go through the same learning curve. Ok, I think the problem is not osg specific. I think it is related to all designs dealing with reference pointers, singletons and plugins. Singletons are often implemented with some kind of static variables as the getInstance methods should only create the instance at the first call. The problem is, that static instances are destructed after the main section of a c program. (In my concrete example at __cxa_finalize()). So lets construct an example. There a singleton data manager which holds reference pointers to external instances. The implementation of these external instances is divided into an plugin system. The base type of all plugins is defined and implemented in a library. The data manager only knows the base type an holds the instances maybe as std::vectorref_pointerBaseClass . If you now write a plugin where the class DerivedClass:public BaseClass is implemented your plugin loader will do the following steps. 1) Load the plugin with (dlopen, LoadLibrary, ...) 2) Find an extern C method which creates an instance of DerivedClass (dlsym, GetProcAddress, ...) 3) Call this method and register the instance of DerivedClass at the data manager This works, so lets go to application shutdown (ore a reconfiguration process). There one might want to close all loaded plugins (dlclose, FreeLibrary). If these methods are called (often enough, depending, how often the plugins where loaded) the plugin code is removed from the address space. If the destructor of the data manager is called after removing the plugins then it will fail. Let's assume that then reference pointers to our instances are the last ones. So after decrementing the reference counters the destructors of the derived classes are called but they are no longer in the address space as we unloaded the plugins. So one solution could be tho handle the plugin unloading procedure in the destructor of the data manager. Then the described problem is solved. But if there are other singletons (whose code is in a plugin) there is now assumption in which order their static variables will be destructed. If the data manager is destructed before some other singleton then the issue occures when whose instance is destructed. And the problems can be more complex. If one uses several frameworks whith different singleton and reference pointer implementations (as in my case) then one has to deal with more than one base class, data manager and so on. So my solution is to use the RTLD_NODELETE flag when loading my plugins. So dlclose just removes some memory allocated by dlopen and does not unload the code of my derived classes. In windows there is no comparabled flag, so I implemented the workaround described at the link I gave in the email before. I hope this was a useful explanation and one remembers If similar issues occure. I am also interested in a more general solution. Is it possible to put a code sequence after the destruction of static variables? Timo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote: On Sat, May 31, 2008 at 7:20 AM, Philip Lowman [EMAIL PROTECTED] wrote: The posted workaround of checking the version number will work fine, alternatively one could replace FIND_PACKAGE(PkgConfig) with INCLUDE(FindPkgConfig OPTIONAL) Which eliminates the error message (and I have verified this on CMake 2.4.6 =) ) Ahh this is much cleaner than my version hack. Now checked into SVN. Works for me. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDEM usage...
Robert, The files were originally PNG files that I converted per the instructions on the wiki to the .tif format. Whether or not that makes them GeoTiffs I don't know. How can I convert the files to GeoTiffs? -Shayne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, May 30, 2008 2:14 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDEM usage... Hi Shayne, The wiki instructions was written in the very early days of the development of osgdem, and is awaiting a rewrite. Today I wouldn't recommend using --xx definition of the coordinate system, you are better off using geospatial imagery/dems. Are you files GeoTiff's? If so then dispense with the --xx command lines and just use: osgdem -t n39_texture.tif -d n39_height_.tif -l 4 -o myterrain/myterrain.ive The coordinates will sourced entirely from the .tif files, there will also be no need to tangle with the -v vertical scaling command line parameter. The VPB version of osgdem also will created nested directories for you hence the myterrain/ directory above. Also temporarily archive support has been removed. Robert. On Thu, May 29, 2008 at 11:46 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC [EMAIL PROTECTED] wrote: All, I've made an attempt in generating a database using my own height field and texture per the instructions located at http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem. So far, I have not had any luck in getting the height field to display correctly. The texture is present just fine but the terrain is either completely flat or is uncorrelated with the texture. This is the command I'm issuing to generate the terrain. osgdem --xx 90 --yy 90 -t n39_texture.tif --xx 90 --yy 90 -d n39_height_.tif -l 4 -v 0.1 -o myterrain.ive -a myterrain.osga The height field tif file comes from a 1 degree by 1 degree of DTED that is 3 arc second level 1, hence the reason for my spacing of 90 meters. If I increase the -v option scaling factor from 0.1 to 50, the terrain height shows up but it is totally uncorrelated with the texture. If anyone has any input on what I'm doing wrong or missing, it would be most appreciated if you could point it out. -Shayne ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::View::getCameraContainingPosition() returns weird results when using slave cameras
Hi Glenn and Robert, I added a call setting up the projection matrix to the FAQ for embedding a viewer in a .NET control. I was having an issue that the perspective on my camera was squished when I started with a tall and skilly control. Setting the initial projection matrix with the following line of code caused everything to work correctly. viewer-getCamera()-setProjectionMatrixAsPerspective(30.0f, static_castdouble(traits-width)/static_castdouble(traits-height), 1.0f, 1.0f); Thanks! Jason On Wed, May 28, 2008 at 4:00 PM, Jason Beverage [EMAIL PROTECTED] wrote: Hi Glenn and Robert, Glenn, your code worked great, thanks alot, I really appreciate it. The posts from you and Hesicong over the last few months about using OSG via C++/CLI have made using OSG in a .NET environment much nicer than what we were previously doing. Robert, I'm in no major hurry to get that issues fixed since I'm just using osgViewer::Viewer and things seem to be working as expected correctly now. Thanks for all your help! Jason On Wed, May 28, 2008 at 3:12 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Jason, On Wed, May 28, 2008 at 5:48 PM, Jason Beverage [EMAIL PROTECTED] wrote: Did you ever find a fix for this issue? I believe I might be running into the same problem. There is still a problem with the set up of events within CompositeViewer with certainly window/camera combinations, it almost works, but not quite precisely as it should. One can see an artefact in when running: osgcompositeviewer cow.osg Try using the trackball manipulator in the lower right cow view. The mouse interactive doesn't quite behave as it should suggesting that the x,y projected into the local view aren't correct. I haven't looked at this issue recently, but the last time I looked I couldn't spot the cause. I really need to just spend a day going through the code with a fine tooth comb to spot what is happening to the mouse events as they are processed. Events needs to be processed by the CompositeViewer as it has to decide event focus to the correct view, then handle slave cameras etc, to projected the mouse coords into a consistent coordinate frame for a single view - it's a lot more complex that one would at first expect, the internal complexity comes from hiding the actual complexity of the setup. I can't tackle this bug hunt right away as I've already spent most of this week on submissions/bug fixing and need to get on with other work... I'll try to make time to resolve this next week. Ping me next week if I haven't started work on it. Robert. ___ 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] osgDEM usage...
Hi Shayne, On Mon, Jun 2, 2008 at 5:20 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC [EMAIL PROTECTED] wrote: The files were originally PNG files that I converted per the instructions on the wiki to the .tif format. Whether or not that makes them GeoTiffs I don't know. How can I convert the files to GeoTiffs? If you want to do any geospatial work then you really need to familiarise yourself with tools like gdal, they have plenty of docs an links on their project website. VirtualPlanetBuilder uses GDAL internally, so what you learn about gdal also will help you understand about what VPB can handle. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgdb-png plugin crash (release only)
Hello all, I am getting a crash while reading a PNG file (on the osgDB::readImageFile() line) in release mode only. This is on Windows Vista, VC++2005, OSG from SVN (recompiled this morning). In debug mode, I get no crash, and the image is read correctly. Also, both the debug and release versions of osgviewer (compiled against the same OSG libs, and using the same libpng13.dll as far as I can tell) both load up the image and don't crash. So I'm baffled... I tried recompiling my app cleanly, no change. I also tried renaming the PNG DLLs (libpng13.dll and libpng13d.dll) adding .bk to see if those were really the libs it was picking up, and it seems so. The stack trace I get (although a bit limited, since it's in release) is: libpng13.dll!675af092() [Frames below may be incorrect and/or missing, no symbols loaded for libpng13.dll] osgdb_png.dll!013f1b99() msvcp80.dll!std::basic_filebufchar,std::char_traitschar ::open(const char * _Filename=0x, int _Mode=1243480, int _Prot=20914645) Line 185 + 0x5 bytes C++ osgdb_png.dll!013f2f4b() osg37-osgDB.dll!00294227() osg37-osgDB.dll!0028d0b4() osg37-osgDB.dll!0029b33b() ntdll.dll!77c92447() ntdll.dll!77c9214c() msvcp80.dll!std::_Allocatechar(unsigned int _Count=35, char * __formal=0x) Line 44 + 0x6 bytes C++ msvcp80.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar ::_Copy(unsigned int _Newsize=30, unsigned int _Oldlen=31) Line 2036 C++ msvcr80.dll!malloc(unsigned int size=1243388) Line 163 + 0x63 bytes C osg37-osgDB.dll!0029bcb3() osg37-osg.dll!1008ef44() msvcr80.dll!memcpy_s(void * dst=0x03a95808, unsigned int sizeInBytes=47, const void * src=0x0023, unsigned int count=47) Line 67 + 0xc bytes C msvcp80.dll!std::char_traitschar::_Copy_s(char * _First1=0x61702f73, unsigned int _Size_in_bytes=1667855474, const char * _First2=0x6554656c, unsigned int _Count=1920300152) Line 576 C++ 65637275() Not very useful... I know... Can anyone suggest some avenues for investigation I might have overlooked? Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Hi, When one float mode did not work then I tried all modes I could see in the gl.h file. The result on my end was the same every time: 10SPF (seconds per frame) instead of 30 FPS which I had when testing with GL_RGBA. The first I tried was GL_LUMINANCE16F_ARB. I figured that I'd start with a simple one (not 32 bit). My blend function settings are source = ONE, destination = ONE. The solution I have now where I use 18 bit with 14 overlapping bits in an unsigned byte RGBA (GL_RGBA mode with additive blend), works, but it would work much better if I had 32 bits to play with. So, I will have to research this further in the future. I have to move on now though, the research code done so far has proven that the technology I am researching works. Viggo Date: Mon, 2 Jun 2008 16:53:24 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Category: FBO, blending, H/W Well, I run a different setting from the previous one I mentioned. I use osg 1.2 (yeah yeah, I promise to upgrade soon). I haven't integrated particle system to my application but I use 1 big billboard with transparency. Until now my FBO cameras used GL_RGBA16F_ARB textures, and also the texture for the billboard was GL_RGBA16F_ARB. I just changed all of them to GL_RGBA32F_ARB and the scene renders correctly. (with transparency). I haven't tried to save the frames to files and check the precision so I've no way to know if the driver didn't fall back to half-float, but I don't believe it would do that anyhow. I'd excpect that if there were troubles they would be the same as yours. But I get solid frame rate of 80+ Hz. (just as before I added the billboard with the blending mode to the scene). Again, I work with nVIDIA 8800 GT, driver 6.14.11.6921, on windows XP. Do you want to send me .osg scenes, or code that I'll test on my machine? Maybe you ment GL_LUMINANCE_ALPHA32F_ARB format? If so tell me how to set it up instead of the RGBA format and I'll try it. Guy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Monday, June 02, 2008 2:22 PM To: OpenSceneGraph Users Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi, (I'm not the guy with the original problem, just interested...) Guy wrote: Hello, Category: FBO, blending, H/W I don't understand exactly what do you mean but H/W blending with float is not supported. I know for sure that we render particle effect with transparency to float (16bit) FBO, and get the correct results. We also get that with a decent frame rate (100-200Hz depending on the number of particles). I'm interested in transparency with 32bit floats (alpha blending). Have you tested that? I would like to know if it is supported in hardware. So I've the feeling that I didn't understand what you mean be blend. Our H/W is nVIDIA 8800 driver 6.14.11.6921 osg2.0 I think J I'd appreciate if you clarify your problem. Thanks, Guy. jp *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Viggo L?vli *Sent:* Monday, June 02, 2008 11:29 AM *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi again :-) I abandoned the idea of using a floating point buffer. I went into the thinking box and came to the same conclusion as you wrote about in the end of your comment. I needed a quite high resolution so I decided to use all 4 channels (RGBA). The numbers I want to accumulate is seldom large, so I needed most resolution in the lower scale. I thus decided to use RGBA where R is most significant and A is least significant. Bit usage is: R = 6 bits G = 5 bits B = 4 bits A = 3 bits All non used bits will overlap with next channel. I am using this to generate a pixel weight when rendering many volumetric clouds on top of each other on screen. Naturally most overlapping clouds will be further away from camera, so I needed as high a number of overlap bits on the lest significant buffers that I could get. My usage accepts in worst case 32 overlapping pixels with maximum weight (in the distance). I think that is something I can live with :-) Anyhow, I got a range (18 bit) that was good enough for my usage and it gives a decent cloud sorting for clouds seen up to 40 kilometers away. I must stress one point: - If you ever try using the alpha channel for this then remember to turn off alpha-clipping (set alpha-func to always). Viggo Date: Mon, 2 Jun 2008 10:05:24 +0200 From: [EMAIL PROTECTED]
Re: [osg-users] osgdb-png plugin crash (release only)
Hi again, Of course, the minute after I pressed the send button, I found the source of the problem, and this was the assertion that was false: I also tried renaming the PNG DLLs (libpng13.dll and libpng13d.dll) adding .bk to see if those were really the libs it was picking up, and it seems so. The stock osgviewer was getting the libpng13.dll in its own bin directory, but my application was getting one that ships with GTK for Windows, and which is probably a slightly different version. This of course is caused by the fact that the Windows puts the directory from which an executable runs first in the search order for DLLs. Sorry for the noise. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDEM usage...
Hi Shayne; I think You should use image which has a georeferenced data. So if you download images from osgdem wiki instroductions, it is normally getting wrong results. I will fix the osgdem wiki page in a few days. The instructions belongs for previous version of osgdem. If you want to create terrain database with hight relief, first of all you should an image which has a georeferenced data ( for example you can download geospatial images from http://seamless.usgs.gov/ and dem files from http://geoengine.nga.mil/geospatial/SW_TOOLS/NIMAMUSE/webinter/rast_roam.html ) or you have to learn using gdal ( http://www.gdal.org/ ), especially gdal_vrt ( http://www.gdal.org/gdal_vrttut.html ) to make add georeference data to any image. For example you downloaded x.tif and its releated y.dem data from given web pages. Then you can use this command; osgdem -t x.tif -d y.dem -v 5.0 -so builde.source -o database/sample_terrain.ive osgdem -s build.source -l 4 Then you should have an terrain with height relief. This can be a bit complex but you should search about osgdem from mail-list ( http://dir.gmane.org/gmane.comp.graphics.openscenegraph.user/ ) and always try to use georeferenced images. Good Luck; ÜMİT UZUN Date: Mon, 2 Jun 2008 19:54:25 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgDEM usage... Hi Shayne, On Mon, Jun 2, 2008 at 5:20 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: The files were originally PNG files that I converted per the instructions on the wiki to the .tif format. Whether or not that makes them GeoTiffs I don't know. How can I convert the files to GeoTiffs? If you want to do any geospatial work then you really need to familiarise yourself with tools like gdal, they have plenty of docs an links on their project website. VirtualPlanetBuilder uses GDAL internally, so what you learn about gdal also will help you understand about what VPB can handle. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live Spaces – hayatınız, Alanınız. Daha fazlasını öğrenmek için buraya tıklayın. http://get.live.com/spaces/overview ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDEM usage...
Thanks to all who have replied to my inquiries thus far regarding osgdem usage. Your input is much appreciated. I will take what's been suggested and make some more progress. I'm sure I'll have more questions... Regards, -Shayne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ümit uzun Sent: Monday, June 02, 2008 2:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDEM usage... Hi Shayne; I think You should use image which has a georeferenced data. So if you download images from osgdem wiki instroductions, it is normally getting wrong results. I will fix the osgdem wiki page in a few days. The instructions belongs for previous version of osgdem. If you want to create terrain database with hight relief, first of all you should an image which has a georeferenced data ( for example you can download geospatial images from http://seamless.usgs.gov/ and dem files from http://geoengine.nga.mil/geospatial/SW_TOOLS/NIMAMUSE/webinter/rast_roam.htm l ) or you have to learn using gdal ( http://www.gdal.org/ ), especially gdal_vrt ( http://www.gdal.org/gdal_vrttut.html ) to make add georeference data to any image. For example you downloaded x.tif and its releated y.dem data from given web pages. Then you can use this command; osgdem -t x.tif -d y.dem -v 5.0 -so builde.source -o database/sample_terrain.ive osgdem -s build.source -l 4 Then you should have an terrain with height relief. This can be a bit complex but you should search about osgdem from mail-list ( http://dir.gmane.org/gmane.comp.graphics.openscenegraph.user/ ) and always try to use georeferenced images. Good Luck; ÜMİT UZUN Date: Mon, 2 Jun 2008 19:54:25 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgDEM usage... Hi Shayne, On Mon, Jun 2, 2008 at 5:20 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: The files were originally PNG files that I converted per the instructions on the wiki to the .tif format. Whether or not that makes them GeoTiffs I don't know. How can I convert the files to GeoTiffs? If you want to do any geospatial work then you really need to familiarise yourself with tools like gdal, they have plenty of docs an links on their project website. VirtualPlanetBuilder uses GDAL internally, so what you learn about gdal also will help you understand about what VPB can handle. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live Spaces - hayatınız, Alanınız. Daha fazlasını öğrenmek için buraya tıklayın. http://get.live.com/spaces/overview ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.4.1 stable release?? If/when/when/who
I'm willing to help port bug fixes back to stable branches. I have an ulterior motive though; I made a particular change in the Inventor plugin that is now in SVN that I would like to see in a stable release. I think that only bug fixes should be ported back; API changes would have to wait for a developer release or a new stable release. This would prevent SO version conflicts between release and developer versions. -Eric Robert Osfield wrote: Hi Paul, On Mon, Jun 2, 2008 at 4:03 PM, Paul Melis [EMAIL PROTECTED] wrote: Why not branch to _create_ the 2.6.x series, instead of branching _after_ 2.6.0? The former is far more commonplace. The system since the 1.9.x dev series has been that we tag when ready to officially make a release, with the 1.9.x series converging towards a point when 2.0.0, using the last few dev releases as release candidates, and finally the trunk was in good enough state to have 2.0.0 tagged from SVN trunk. The other approach, which you suggest, is rather than use the dev releases as release candidates, branch a stable release when we get to a feature freeze period and then make release candidates based on this branch. The final official release would then bee a branch + a revision number than holds the particular release in a point in time. When moving to having maintainence releases of a stable series using dev series as pre releases doesn't work, as the dev series already heads off in towards then next major stable point release. So... now we a proposing the stable maintaince releases then we need to move to a new system - branch first then stabilising this code base in readiness for a 2.4.1, 2.4.2 seems like the way to go from here on out. For 2.6.0, it'd suggest we use SVN trunk/later 2.5.x dev series as pre releases of 2.6.0 get things tested enough to know we are roughly in the right ball park functionality/quality wise, then copy trunk across to a 2.6.0 branch and then use this as the base of release candidate series before the final 2.6.0. Once the 2.6.0 branch happens the stable release maintainer would then become actively involved in shepherding the code base to its eventual official release. As the differences between 2.4 and SVN are still small now is the time to start the process... I'm willing to help to backport fixes and other things from trunk to the 2.4 branch. I can't tell you at this moment if this would be a long-term commitment, though. I think it'd be hard for anyone to sign up long term to something, taking short term responsibility won't be a problem as long as we all follow a set of systems that are published and adhered too/use the same scripts/tools - so others can easily drop in to help out when others move on/are away on holiday. Right now we don't have all the systems published/scripts etc, so it'd be a case of documenting as we go along. First step is to find a set of volunteers who are willing to going along this journey, get them write access to making branches of the OSG. It might even be worth having a scratch pad set of branches that we can new maintainers can experiment with. I'm open to suggestions. Robert. ___ 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] osgDEM usage...
Robert (or anyone else), Can you enlighten me on the --TERRAIN, --LOD, and --PagedLOD options in osgdem? What are the benefits or drawbacks for using these? Which is the best combination to use for performance, quality, etc.? Thanks, -Shayne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, June 02, 2008 12:54 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDEM usage... Hi Shayne, On Mon, Jun 2, 2008 at 5:20 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC [EMAIL PROTECTED] wrote: The files were originally PNG files that I converted per the instructions on the wiki to the .tif format. Whether or not that makes them GeoTiffs I don't know. How can I convert the files to GeoTiffs? If you want to do any geospatial work then you really need to familiarise yourself with tools like gdal, they have plenty of docs an links on their project website. VirtualPlanetBuilder uses GDAL internally, so what you learn about gdal also will help you understand about what VPB can handle. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] avoid Esc key on keyboard
OSG1.2 Hello Eric. You can also try changing the setup parameters of the viewer to something like this: viewer-setUpViewer(osgProducer::Viewer::STANDARD_SETTINGS ~osgProducer::Viewer::ESCAPE_SETS_DONE ); Good luck, Guy. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: Monday, June 02, 2008 5:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] avoid Esc key on keyboard Hi Eric, As the compiler said, the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool) method is not static, so just call it from your osgProducer viewer object (viewer-setEscapeSetDone(false)) and it should work. Cheers, On Mon, Jun 2, 2008 at 4:57 PM, Eric Pouliquen [EMAIL PROTECTED] wrote: Hi, i'm using OSG 1.2 on an old project, and i want to switch off the default Esc key behavior (exiting my application). This project uses a osgProducer::viewer, and i created a class herited of GUIeventHandler to manage mouse and keyboard events. I can manage all keys except the 'Esc' key... Someone said to look at the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool), i see in it in the corresponding code, but how can i use it (a simple call causes an error due to non static style of the function) in my app ? I tried to manage the Esc key in the handle function, returning true, and pushing front the handler in the eventHandlerList, but it doesn't work. Help :) Robert Osfield a écrit : Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis [EMAIL PROTECTED] wrote: Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: ... So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- Eric Pouliquen === Silicon Worlds S.A. 224 rue St Denis 75002 Paris France Tel: +33 (0) 1 53.90.11.13 Fax: +33 (0) 1 53.90.11.12 www.silicon-worlds.fr === ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
