Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi Sergey Im afraid I dont have an answer, but I can back up your observations. We are using two cameras for our application one for a standard view the other for an IR targeting POD. The two cameras are looking in opposite directions and have different lodscales. I have also notised that the memmory usage keeps rising untill the app chrashes and that this will happen faster if the IR camera is zoomed with according lodscale. I have tried various settings for the database pager, but the problem remains. Brgs. Ralf Stokholm 2009/10/7 sergey leontyev sleon...@ist.ucf.edu Hello, (i am using OSG 2.8.2) Let me try to explain the problem : I have a big database (TerraPage). I load it into my application. I have two views (cameras) within a window and i can position each camera individually looking directly down at the terrain ( I am using orthographic projection ). If I move 2 cameras to an identical location everything is fine, and I can keep moving them to the same position. However, when i move them to a different locations ( looking at different tiles i presume). The memory usage starts to increase at about 0.5mb per second and never stops. It seems to only happen when i use setViewAsLookAt which changes the modelview matrix. I used to move around the map using the ortographic projection matrix(by setting left and right top and bottom params) i have never noticed the memory increase. In other words it seems that having 2 views with cameras positioned in different places break something in the databasepager. I have tried playing with some settings such setTargetMaximumNumberOfPageLOD or calling clear on the database pager. Does anyone have or had similar issues? I have no idea how to debug this. Is what i am saying possible? and the databsepager has a bug? Does anyone have any ideas? How to debug this? How to rule out the that there is a bug in databasepager? Any help or advices are appreciated. Thanks! Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17989#17989 ___ 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] [3rdparty] osgOcean collision detection
Dimitrios Filiagos dfili...@yahoo.com wrote: One other thing what is the functionality of _isDirty and buid() in Jean Claudes code ? It will save me a lot of time. isDirty forces a rebuild of the data structures and build() does the actual construction of the surface. Your original code didn't have it and I was seeing a crash when a callback was trying to determine the height of the surface before the arrays were initialized. This avoids it. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How do I toggle the osgViewer::Viewer full screen mode?
Hi, I'm new to the OSG and just starting out with some simple examples. The osgViewer::Viewer by default displays in full screen mode. But in my application I want it to be a smaller window by default. How do I do that? I found the event handler WindowSizeHandler which has the facility to toggle the full screen mode but couldn't quite figure out how to make it work. Thanks in advance! Regards, Ash. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17930#17930 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I toggle the osgViewer::Viewer full screen mode?
Hi, Ash Pat wrote: Hi, I'm new to the OSG and just starting out with some simple examples. The osgViewer::Viewer by default displays in full screen mode. But in my application I want it to be a smaller window by default. How do I do that? I found the event handler WindowSizeHandler which has the facility to toggle the full screen mode but couldn't quite figure out how to make it work. You can use the same code as the WindowSizeHandler uses internally. Search the osg examples for traits and you'll get many examples of creating windows. See e.g. osgwindows. jp Thanks in advance! Regards, Ash. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17930#17930 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::GraphicsWindowCarbon with wxWidgets/wxMac
Hi there, I've seen somewhere in the list somebody had some success with using the GraphicsWindowCarbon within bare Carbon. Now I am trying the same with wxWidgets 2.8.10 and it seems not to work as expected (corrupted Window background). Did somebody on the list had some success and can share a code snippet? I got it working with GTK and Win32 (wxGTK and wxMSW respectively). Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert, What results do you get with the bug fixes I've just checked in? I've just updated and now I get a single corrupted image flashed onto the screen and then a segfault. $ osgmovie --mouse --interactive --shaders -e ffmpeg file.avi image-s()640 image-t()=480 aspectRatio=1 _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Created new TextureObject, _numOfTextureObjects 1 GLBufferObjectSet::GLBufferObjectSet _profile._size=1228800 Segmentation fault If I run in gdb the corrupted image stays, but I'll have to recompile with debug info to give you a more sensible backtrace. Tomorrow... have to go now. Debug build still did not provide a nice backtrace, but I've followed the crash to void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp At the line: dataPtr = reinterpret_castunsigned char*(pbo-getOffset(image-getBufferIndex())); dataPtr gets assigned 0 and then the glTexSubImage2D call generates the segfault. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I toggle the osgViewer::Viewer full screen mode?
Hi, J.P. Delport wrote: Hi, Ash Pat wrote: Hi, I'm new to the OSG and just starting out with some simple examples. The osgViewer::Viewer by default displays in full screen mode. But in my application I want it to be a smaller window by default. How do I do that? I found the event handler WindowSizeHandler which has the facility to toggle the full screen mode but couldn't quite figure out how to make it work. You can use the same code as the WindowSizeHandler uses internally. Search the osg examples for traits and you'll get many examples of creating windows. See e.g. osgwindows. you can also just do, e.g.: viewer.setUpViewInWindow(0, 0, 640, 480); viewer.realize(); jp jp Thanks in advance! Regards, Ash. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17930#17930 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn't work)
Hi, amazing news - i do own an ATI 4850 - I will try to update my drivers or consider to swap to another graphics card. Are you able to test this example with an ati card? Were you able to use CLAMP_TO_BORDER too? Thank you! Greetings, Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17999#17999 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clarification on use of Manipulators in CAD-Style app
Hi Vincent, On Tue, Oct 6, 2009 at 5:19 PM, Vincent Gadoury vgado...@humancad.com wrote: It seems there is a glitch with the new osgManipulator event handling and the TrackballManipulator. In the osgmanipulator example, if you keep ctrl or 'a' pressed when you rotate the trackball using the left mouse button, the trackball might get crazy (rotating of arbitrary - probably high - angle). The trick to reproduce the bug is to try to release the mouse button on a dragger. I'm able to reproduce it constantly. I was never able to reproduce it when the ctrl or 'a' key were not pressed. I tested it on revisions 10593 and 10606. I can't reproduce this on svn/trunk 10606 so there must be some knack to it. Unfortunately, I did not have the time to track it down (it's not a big problem for me at the moment). I just wanted to let you know about it. Could you have a bash at tracking it down as I can't track down something I can't reproduce. Also, are there any clues about when 2.9.6 will be released(/tagged)? My plan is to make 2.9.6 towards the end of this week. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Pankaj, Jan, J-S, I've now added a RELEASE_ONLY_BUILD option to the CMakeLists which removes the need for debug libraries. This is now committed to the osgOcean trunk. In visual studio this removes the debug projects from the build menu. Note: CMake will still look for the debug versions and list them as not found. This behaviour is is part of the CMake's own macros for finding OSG and openthreads so I thought it best to leave it as it is. However, as long as the release only build button is checked it will generate the build without complaining about them. I'd be grateful if you could test this for me. I've run it through VS2008 and it seemed to work but I haven't been able to test it on anything else. Regards, Kim. 2009/10/6 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Jan, Thanks for the investigations on your machine. It finds the non-debug OSG successfully but fails on finding debug version of OpenThreads (which I didn't compile, I have only release one). I think the issue is in the FindOpenThreads.cmake lacking the code you have pointed out. Yeah, ok so for that we can easily send a patch to the CMake project. However: I can live with it for the time being, but it should be fixed, IMO. Well if Kim can get what he said working, it would be even better. I agree that silently using the release lib in a debug build would be bad (on Windows at least, and there's no platform guard for this in the CMake module's code). At the very least it should warn that it's doing this, but even better would be setting up our project so that we can do release-only or release+debug builds as required. So good luck Kim, hope you get it working without too much trouble! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking (computeIntersection) bug with POINT_ROT_EYE Billboards
Hi Nathan, Thanks for the example. I can reproduce the picking problems using: osgpick singletree.osg So thumbs up there. As to the cause, it's almost certainly a bug in the computation of the matrix that should be positioning the billboard, or the lack of coordination of point at which the billboard should be rotated about. It's almost certainly not a precision issue. I'm afraid I'm not in position to go looking into bugs right now, so would appreciate if others members of the community could dive in and have a look. Robert. On Tue, Oct 6, 2009 at 7:00 PM, Nathan Monteleone nathan.montele...@lmco.com wrote: Hi, I'm having trouble getting picking (via View::computeIntersection) to work on Billboards in POINT_ROT_EYE mode. Attached is a .osg file that creates a single billboard tree -- if I open this file with osgPick in OSG 2.9.5, I can only get a hit if I click near the very base of the tree. As far as I can tell this has always been a problem; billboard picking wasn't really supported at all pre-2.8. I tried tracing this through IntersectionVisitor and I couldn't figure out why it didn't work. I have two guesses: 1. A precision problem in the matrix math or 2. The billboard matrix is coming out differently in the visitor than in the actualy cull traversal. It seems to be using the intersection vector start point as the eyepoint when calculating the matrix for the billboard -- isn't this wrong? I'll keep looking at it, but I could really use a second set of eyes. Thanks! - Nathan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17980#17980 ___ 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] setUpViewerAsEmbeddedInWindow and wxPython glcanvas
Hi Randolf, On Wed, Oct 7, 2009 at 1:32 AM, Randolph Fritz rfritz...@gmail.com wrote: One question: the osgViewerGLUT example holds the reference to its osgViewer::GraphicsWindow in an osg::observer_ptr, rather than an osg::ref_ptr. What's the reasoning behind that? I don't recall the code, but the use of observer_ptr rather ref_ptr is to not take ownership of an object, rather just observer it which it's alive and let other objects that actually own the object in question (i.e. the viewer) to destruct it when it's done. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Trying To obtain all statsets in a Graph
Hi All osg Users
I'm using a visitor to obtain all Statsets in a graph. But the visitor dose not
collects all statsets, why?
Code im using is simply this:
class GetStatsetsVissitor : public osg::NodeVisitor
{
public:
GetStatsetsVissitor(){
setTraversalMode(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN);
};
~GetStatsetsVissitor(){};
typedef std::setosg::ref_ptrosg::StateSet
StatsetSet;
StatsetSet GetStatset(void){return m_Statsets;};
protected:
void apply(osg::Node n)
{
if(n.getStateSet())
{
m_Statsets.insert(n.getStateSet());
}
traverse(n);
};
StatsetSet m_Statsets;
};
Regards Ragnar
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
HI Sergey and Ralf, I haven't seen this behavior in the DatabasePager before, and it might not be directly related to the DatabasePager at all. The DatabasePager itself doesn't actually know anything about cameras, it just handles requests made to it from the cull traversals. The code for handling the requests is thread safe so there should be no problem with having multiple cameras making multiple requests. If you do have multiple cameras then you will naturally be requiring more data to be loaded into memory, and less data will able to be expired than normal. Whether this can explain the growth in memory you are seeing I would doubt though. Perhaps the OpenGL drivers is playing tricks. If you can try your app on a different OS/driver/hardware combination to see if the same behavior exists. Another thing you could try is the svn/trunk version of the OSG as it now contains and texture and buffer object pool mechanism that you can turn on that will keep a lid on how much OpenGL memory you're app is using and might just be what you need. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi J.P, On Wed, Oct 7, 2009 at 7:59 AM, J.P. Delport jpdelp...@csir.co.za wrote: Debug build still did not provide a nice backtrace, but I've followed the crash to void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp At the line: dataPtr = reinterpret_castunsigned char*(pbo-getOffset(image-getBufferIndex())); dataPtr gets assigned 0 and then the glTexSubImage2D call generates the segfault. It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. Do you get a crash if you use the --texture2D on the osgmovie command line? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trying To obtain all statsets in a Graph
Hi Ragnar,
On 7/10/09 10:48 AM, Ragnar Hammarqvist wrote:
I'm using a visitor to obtain all Statsets in a graph. But the visitor dose not
collects all statsets, why?
Code im using is simply this:
...
void apply(osg::Noden)
{
if(n.getStateSet())
{
m_Statsets.insert(n.getStateSet());
}
traverse(n);
};
You're only collecting StateSets attached to nodes, but they can also be attached to
Drawables, so you need to handle Geodes separately (iterating over all drawables).
HTH,
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi Robert Unfortunatly I cant upgrade to trunk without a considerable effort, so that wont happen right now. But the texture pools looks really interesting with regards to large paged terrains. I doubt if its a driver thing directly, as Im able to run osgviewer on the same dataset without problems, if i for instance move far away from the terrain memmory will drop etc. If I do the same in my application moovi both cameras far away from the paged data wont result in the same drom in mommory consumption. These observations are done in windows task mgr so they might not be completely valid, but the end result is that if i fly back and fourth usin the viewer it will never chrash, if I do it using my application it will eventually chrash, this might well be me screwing up somewhere else but it supports the observations Sergey are making. Database is VPB database app 500 Gig OSG 2.8.2 Windows vista and XP Nvidia GTX280 Graphics latest drivers. I was wondering if somthing in the database pager is preventing the release like a copy of a refptr or similar? Brgs Ralf 2009/10/7 Robert Osfield robert.osfi...@gmail.com HI Sergey and Ralf, I haven't seen this behavior in the DatabasePager before, and it might not be directly related to the DatabasePager at all. The DatabasePager itself doesn't actually know anything about cameras, it just handles requests made to it from the cull traversals. The code for handling the requests is thread safe so there should be no problem with having multiple cameras making multiple requests. If you do have multiple cameras then you will naturally be requiring more data to be loaded into memory, and less data will able to be expired than normal. Whether this can explain the growth in memory you are seeing I would doubt though. Perhaps the OpenGL drivers is playing tricks. If you can try your app on a different OS/driver/hardware combination to see if the same behavior exists. Another thing you could try is the svn/trunk version of the OSG as it now contains and texture and buffer object pool mechanism that you can turn on that will keep a lid on how much OpenGL memory you're app is using and might just be what you need. 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] New OpenGL texture object and buffer object pool support
Hi Robert, Robert Osfield wrote: Hi J.P, On Wed, Oct 7, 2009 at 7:59 AM, J.P. Delport jpdelp...@csir.co.za wrote: Debug build still did not provide a nice backtrace, but I've followed the crash to void TextureRectangle::applyTexImage_subload in TextureRectangle.cpp At the line: dataPtr = reinterpret_castunsigned char*(pbo-getOffset(image-getBufferIndex())); dataPtr gets assigned 0 and then the glTexSubImage2D call generates the segfault. It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. Do you get a crash if you use the --texture2D on the osgmovie command line? No, it runs, but with Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. jp Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi Ralf. On Wed, Oct 7, 2009 at 10:33 AM, Ralf Stokholm alfma...@arenalogic.com wrote: I was wondering if somthing in the database pager is preventing the release like a copy of a refptr or similar? I believe this would be very unlikely. There is no special handling of multiple view points, and there needn't be as the DatabasePager page is designed to be completely agnostic to the number of views. I would recommend investigating just how many nodes are kept in memory. I also strongly recommend trying another OS. Vista can be a real problem w.r.t graphics memory managent. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi J.P., What hardware and OS are you testing on right now? On Wed, Oct 7, 2009 at 10:36 AM, J.P. Delport jpdelp...@csir.co.za wrote: It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. I've just done a code review of TextureRectangle.cpp code and it looks to be binding the PBO and setting the data pointer appropriately. I'm afraid I haven't yet spotted any lead of what to look into next. Do you get a crash if you use the --texture2D on the osgmovie command line? No, it runs, but with Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. I upped the granularity of GL error checked via: export OSG_GL_ERROR_CHECKING=ONCE_PER_ATTRIBUTE And it then generated the warning after the texture apply, still an invalid enumerant. Add more fine grained checks into osg::Texture, Texture2D and TextureRectangle to further isolate which gl call is the problem is probably required. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg Simplifier and crash in ive writer
Hi all, I'm currently looking at a way to simplify a big IVE file. (850Mbytes) To make some test, I open the file, get all the geodes with a visitor, simplify their geometries with osg Simplifier and write the new file. But, when I put the simplification sample ratio to 0.1 and 0.3 (currently testing 0.6), the simplification works well but during the writing of the file there is a crash... I cannot give you the original file... and I tested it on a little file and it worked... So, these are the questions : Are there some limitation for the osg simplifier ? Is there a way to ask the simplifier to remove about 80% of the datas ? (destructive simplification of course) How can I use it better ? Thanks for your help Regards, Vincent __ Information from ESET NOD32 Antivirus, version of virus signature database 4485 (20091006) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi, you 're right now I understand why I had some crashes from time to time Thanks! Cheers, Dimitrios -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18014#18014 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi, It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. Do you get a crash if you use the --texture2D on the osgmovie command line? No, it runs, but with Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. just some more comments... I've compared code for Texture::applyTexImage2D_subload vs TextureRectangle::applyTexImage_subload in the former the result of pbo-getOffset() is never used. If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to the image data, it runs the same as --texture2D, i.e. Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) after every frame. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn'twork)
Johannes, We tested on ATI 4890. Vista 64 bit. Catalyst 9.9. Clamp to edge works. Clamp to border does not. Problems with dual monitors but it does not count here, I guess. Wojtek - Original Message - From: Johannes SchA1th acco...@jotschi.de To: osg-users@lists.openscenegraph.org Sent: Wednesday, October 07, 2009 9:21 AM Subject: Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn'twork) Hi, amazing news - i do own an ATI 4850 - I will try to update my drivers or consider to swap to another graphics card. Are you able to test this example with an ati card? Were you able to use CLAMP_TO_BORDER too? Thank you! Greetings, Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17999#17999 ___ 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] osg Simplifier and crash in ive writer
Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4486 (20091007) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trying To obtain all statsets in a Graph
Ulrich,
Thanx. This realy did the trick.
Regards Ragnar
-Ursprungligt meddelande-
Från: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] För Ulrich Hertlein
Skickat: den 7 oktober 2009 11:11
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] Trying To obtain all statsets in a Graph
Hi Ragnar,
On 7/10/09 10:48 AM, Ragnar Hammarqvist wrote:
I'm using a visitor to obtain all Statsets in a graph. But the visitor dose
not collects all statsets, why?
Code im using is simply this:
...
void apply(osg::Noden)
{
if(n.getStateSet())
{
m_Statsets.insert(n.getStateSet());
}
traverse(n);
};
You're only collecting StateSets attached to nodes, but they can also be
attached to Drawables, so you need to handle Geodes separately (iterating over
all drawables).
HTH,
Cheers,
/ulrich
___
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] New OpenGL texture object and buffer object pool support
Hi J.P, On Wed, Oct 7, 2009 at 11:26 AM, J.P. Delport jpdelp...@csir.co.za wrote: just some more comments... I've compared code for Texture::applyTexImage2D_subload vs TextureRectangle::applyTexImage_subload in the former the result of pbo-getOffset() is never used. If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to the image data, it runs the same as --texture2D, i.e. Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) Could you pinpoint the code you are referring to? Copying and pasting into an email would be fine, or even line numbers might be OK if you are working against svn/trunk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn't work)
Hi, one more question. Did clamp to border work on nvidia chips? Wojciech Lewandowski wrote: We tested on ATI 4890. Vista 64 bit. Catalyst 9.9. Clamp to edge works. Clamp to border does not. Any idea why clamp to border does not work with ATI 4890? Greetings Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18019#18019 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcement: OpenGL ES 2.0 port underway
Hi All, I have just posted an update to the wiki page dedicated to the OpenGL-ES port: http://www.openscenegraph.org/projects/osg/wiki/Community/OpenGL-ES Please feel free to critique/ask questions/volunteer your assistance :-) Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn'twork)
Yes, one of the pictures was showing this: I changed the border color to pink to make it more clear. In fact I also checked mixed mode CLAMP_TO_EDGE on S coord, and CLAMP_TO_BORDER on T coord and it also works on NVidia. Cheers, Wojtek - Original Message - From: Johannes SchA1th acco...@jotschi.de To: osg-users@lists.openscenegraph.org Sent: Wednesday, October 07, 2009 12:54 PM Subject: Re: [osg-users] Texture Wrapping Texture2DArray (Clamping doesn'twork) Hi, one more question. Did clamp to border work on nvidia chips? Wojciech Lewandowski wrote: We tested on ATI 4890. Vista 64 bit. Catalyst 9.9. Clamp to edge works. Clamp to border does not. Any idea why clamp to border does not work with ATI 4890? Greetings Johannes -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18019#18019 ___ 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] New OpenGL texture object and buffer object pool support
Hi Robert, Robert Osfield wrote: Hi J.P., What hardware and OS are you testing on right now? Debian 32-bit, Nvidia driver. On Wed, Oct 7, 2009 at 10:36 AM, J.P. Delport jpdelp...@csir.co.za wrote: It's normal for pbo-getOffset() to return a 0, and correct to pass this to glTexSubImage2D, but only if a PBO is bound, if it isn't then it will result in a seg fault. Perhaps there is some mistake in the code that isn't binding the PBO when it should. OK, I'll try to check this too. I've just done a code review of TextureRectangle.cpp code and it looks to be binding the PBO and setting the data pointer appropriately. I'm afraid I haven't yet spotted any lead of what to look into next. Found it. Typo/copypasted line in PBO constructor. Target was set to wrong value and that made the bind fail. Modded file attached. TextureRectangle now works fine in osgmovie. The world feels better :) jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. BufferObject.cpp.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking (computeIntersection) bug with POINT_ROT_EYE Billboards
robertosfield wrote: As to the cause, it's almost certainly a bug in the computation of the matrix that should be positioning the billboard, or the lack of coordination of point at which the billboard should be rotated about. It's almost certainly not a precision issue. I'm afraid I'm not in position to go looking into bugs right now, so would appreciate if others members of the community could dive in and have a look. Thanks Robert. I understand about not having time to chase bugs :) I do have a conceptual question (for anyone) that's going to affect the fix: when doing intersection tests, should billboards point align to the start point of the intersector, or toward the eyepoint? Seems like it depends on the case -- if you're doing a pick based on a screen coordinate, you'd want it aligned to the eyepoint. But if you're using a point and a ray or two points, you probably do want the billboard pointed toward the start point, because those kinds of queries usually try to answer the question, If I were at point x looking toward point y, what would I see? If that behavior is really what we want, I think I can just fix it by changing the screen-coordinate forms of computeIntersection to explicitly set the reference eyepoint. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18025#18025 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Endless loop osg::ClipNode::computeBound
Hi Robert, like the subject says, there's an endless loop in 'osg::ClipNode::computeBound'. Here is a part of the gdb backtrace. #23 0x2b85733d44fc in osg::ClipNode::computeBound (this=0x29679c0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSce neGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 #24 0x2b857141dc61 in osg::Node::getBound (this=0x29679c0) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #25 0x2b857347396a in osg::Group::computeBound (this=0x298db40) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #26 0x2b857141dc61 in osg::Node::getBound (this=0x298db40) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #27 0x2b857347396a in osg::Group::computeBound (this=0x1e3b3b0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #28 0x2b85733d44fc in osg::ClipNode::computeBound (this=0x1e3b3b0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert,
Robert Osfield wrote:
Hi J.P,
On Wed, Oct 7, 2009 at 11:26 AM, J.P. Delport jpdelp...@csir.co.za wrote:
just some more comments...
I've compared code for
Texture::applyTexImage2D_subload
vs
TextureRectangle::applyTexImage_subload
in the former the result of pbo-getOffset() is never used.
If in TextureRectangle::applyTexImage_subload I leave dataPtr to point to
the image data, it runs the same as --texture2D, i.e.
Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)
Could you pinpoint the code you are referring to? Copying and pasting
into an email would be fine, or even line numbers might be OK if you
are working against svn/trunk.
In Texture::applyTexImage2D_subload Texture.cpp line 2064
glTexSubImage2D( target, 0,
0, 0,
inwidth, inheight,
(GLenum)image-getPixelFormat(),
(GLenum)image-getDataType(),
data - dataMinusOffset + dataPlusOffset);
is called with data
line 1987
unsigned char* data = (unsigned char*)image-data();
line 2035, still same function...
const unsigned char* dataPtr = image-data();
GLBufferObject* pbo = image-getOrCreateGLBufferObject(contextID);
if (pbo !needImageRescale !useGluBuildMipMaps)
{
state.bindPixelBufferObject(pbo);
dataPtr = reinterpret_castunsigned
char*(pbo-getOffset(image-getBufferIndex()));
dataPtr is set here, but not used at all further in the function.
If you compare this with TextureRectangle::applyTexImage_subload you
will see that dataPtr is set and used there.
So, osgmovie --texture2D now still gives corrupted images, even with the
BufferObject fix applied. It used to work because the binding failed.
Hope I explained better.
jp
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Endless loop osg::ClipNode::computeBound
Hi Robert, sorry, I haven't been aware, that it's not the same ClipNode object in the backtrace. I have a scenegraph with three ClipNodes. And two of these are calling computeBound on each other (). #185 0x2ad784e294fc in osg::ClipNode::computeBound (this=0x1fe4ac0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 #186 0x2ad782e72c61 in osg::Node::getBound (this=0x1fe4ac0) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #187 0x2ad784ec896a in osg::Group::computeBound (this=0x2971890) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #188 0x2ad782e72c61 in osg::Node::getBound (this=0x2971890) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #189 0x2ad784ec896a in osg::Group::computeBound (this=0x21e24e0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #190 0x2ad784e294fc in osg::ClipNode::computeBound (this=0x21e24e0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 #191 0x2ad782e72c61 in osg::Node::getBound (this=0x21e24e0) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #192 0x2ad784ec896a in osg::Group::computeBound (this=0x208fb00) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #193 0x2ad782e72c61 in osg::Node::getBound (this=0x208fb00) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #194 0x2ad784ec896a in osg::Group::computeBound (this=0x1fe4ac0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #195 0x2ad784e294fc in osg::ClipNode::computeBound (this=0x1fe4ac0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 #196 0x2ad782e72c61 in osg::Node::getBound (this=0x1fe4ac0) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #197 0x2ad784ec896a in osg::Group::computeBound (this=0x2971890) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #198 0x2ad782e72c61 in osg::Node::getBound (this=0x2971890) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #199 0x2ad784ec896a in osg::Group::computeBound (this=0x21e24e0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #200 0x2ad784e294fc in osg::ClipNode::computeBound (this=0x21e24e0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 #201 0x2ad782e72c61 in osg::Node::getBound (this=0x21e24e0) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #202 0x2ad784ec896a in osg::Group::computeBound (this=0x208fb00) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #203 0x2ad782e72c61 in osg::Node::getBound (this=0x208fb00) at /scr/bug/framework-3rd/versions/0.50/linux-64/osg/include/osg/Node:334 #204 0x2ad784ec896a in osg::Group::computeBound (this=0x1fe4ac0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/Group.cpp:357 #205 0x2ad784e294fc in osg::ClipNode::computeBound (this=0x1fe4ac0) at /soft/os/openscenegraph/sc.iViz-OSG/OpenSceneGraph-2.8.1/OpenSceneGraph-2.8.1/src/osg/ClipNode.cpp:154 Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] Multisampling/RenderBuffer Support
As I said before: multisampling is not a feature of osgPPU it is rendering related. The patch I submited previously, has been included into osg. Hence multisampling should work now. The HDR example can be easy rewritten to support multisampling as described before in this thread. cheers, art pankajnagarkoti80 wrote: I'm looking at similar requirements and was looking at osgPPU today to see if multisampling was implemented. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18030#18030 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Endless loop osg::ClipNode::computeBound
Hi Daniel, On Wed, Oct 7, 2009 at 1:40 PM, Daniel Trstenjak daniel.trsten...@science-computing.de wrote: sorry, I haven't been aware, that it's not the same ClipNode object in the backtrace. I have a scenegraph with three ClipNodes. And two of these are calling computeBound on each other (). It really sounds like you've created a loop into scene graph where a node has a parent amongst it's children. Recursion is not supported in the OSG so you need to avoid this type of circular scene graph setup. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Endless loop osg::ClipNode::computeBound
Hi Robert, It really sounds like you've created a loop into scene graph where a node has a parent amongst it's children. Recursion is not supported in the OSG so you need to avoid this type of circular scene graph setup. Yeah. Currently I'm looking at our code which handles the insertion/removal of ClipNodes, and it looks very strange. So yes, there's is potential for a circle. :-) Thanks for the hint. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] help to simulate SAR radar
Hi, i need to make a SAR radar with OSG, and I don't know from where to begin. Has somebody an idea or an example of the way that I can use ? thank's Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering problem
Hi,
Currently the rendering is handled by a thread which calls
while(!viewer.done)
{
viewer.frame);
}
but in the software there can be up to 3 viewers active at one time, all
running a seperate thread to render, this is a CPU hog and ideally i want to
only update the viewer if the scene has changed.
Does anybody know of any ways of detecting changes in the scene graph?
or a better way of handling the rendering?
Cheers
Adam
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18032#18032
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] help to simulate SAR radar
Firstly your question is so open ended that your not going to get great help We handle the data but I'm unable to discuss what we do with it unfortunately If you do know the basics of OSG I would recommend you first learn that before proceeding (see the Quick start guide, you'll find a link on the OSG web site) Then it demands on what you want to do with the SAR data, has it been cleaned , processed, do you want to use this an imagery or as DEM, do you understand the SAR format, you will need to write an import tool to OSG to ingest either as imagery and or some form of elevation data, break the data in to manageable paging chunks etc.. There are many examples around they simply don't do it with SAR data just other data so you could use those as a basis for your own code Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Benoît Poulard Sent: Wednesday, October 07, 2009 9:39 AM To: osg-users Subject: [osg-users] help to simulate SAR radar Hi, i need to make a SAR radar with OSG, and I don't know from where to begin. Has somebody an idea or an example of the way that I can use ? thank's Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Simplifier and crash in ive writer
simplifier ?
Is there a way to ask the simplifier to remove about 80% of the datas
? (destructive simplification of course)
How can I use it better ?
Thanks for your help
Regards,
Vincent
__ Information from ESET NOD32 Antivirus, version of virus
signature database 4485 (20091006) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus
signature database 4486 (20091007) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4486 (20091007) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
/**
*
*FILE:DrawElementsUByte.cpp
*
*DESCRIPTION:Read/Write osg::DrawElementsUByte in binary format to disk.
*
*CREATED BY:Auto generated by iveGenerated
*and later modified by Rune Schmidt Jensen.
*
*HISTORY:Created 20.3.2003
*
*Copyright 2003 VR-C
**/
#include Exception.h
#include DrawElementsUByte.h
#include PrimitiveSet.h
using namespace ive;
void DrawElementsUByte::write(DataOutputStream* out){
// Write DrawElementsUByte's identification.
out-writeInt(IVEDRAWELEMENTSUBYTE);
// If the osg class is inherited by any other class we should also write this to file.
osg::PrimitiveSet* prim = dynamic_castosg::PrimitiveSet*(this);
if(prim){
((ive::PrimitiveSet*)(prim))-write(out);
}
else
throw Exception(DrawElementsUByte::write(): Could not cast this osg::DrawElementsUByte to an osg::PrimitiveSet.);
// Write DrawElementsUByte's properties.
// Write array length and its elements.
out-writeInt(size());
if (size()!=0) out-writeCharArray((const char*)front(), size() * CHARSIZE);
}
void DrawElementsUByte::read(DataInputStream* in){
// Read DrawElementsUByte's identification.
int id = in-peekInt();
if(id == IVEDRAWELEMENTSUBYTE){
// Code to read DrawElementsUByte's properties.
id = in-readInt();
// If the osg class is inherited by any other class we should also read this from file.
osg::PrimitiveSet* prim = dynamic_castosg::PrimitiveSet*(this);
if(prim){
((ive::PrimitiveSet*)(prim))-read(in);
}
else
throw Exception(DrawElementsUByte::read(): Could not cast this osg::DrawElementsUByte to an osg::PrimitiveSet.);
// Read array length and its elements.
int size = in-readInt();
resize(size);
if (size!=0) in-readCharArray((char*)front(), size * CHARSIZE);
}
else{
throw Exception(DrawElementsUByte::read(): Expected DrawElementsUByte identification.);
}
}
/**
*
*FILE:DrawElementsUInt.cpp
*
*DESCRIPTION:Read/Write osg::DrawElementsUInt in binary format to disk.
*
*CREATED BY:Copied from DrawElementsUShort.cpp by Marco Jez
*
*
*HISTORY:Created 20.3.2003
*
*Copyright 2003 VR-C
**/
#include Exception.h
#include DrawElementsUInt.h
#include PrimitiveSet.h
#include osg/Endian
using namespace ive;
void DrawElementsUInt::write(DataOutputStream* out){
// Write DrawElementsUInt's identification.
out-writeInt(IVEDRAWELEMENTSUINT);
// If the osg class is inherited by any other class we should also write this to file.
osg::PrimitiveSet* prim = dynamic_castosg::PrimitiveSet*(this);
if(prim){
((ive::PrimitiveSet*)(prim))-write(out);
}
else
throw Exception(DrawElementsUInt::write(): Could not cast this osg::DrawElementsUInt to an osg::PrimitiveSet.);
// Write DrawElementsUInt's properties.
// Write array length and its elements.
out-writeInt(size());
if (size()!=0) out-writeCharArray((const char*)front(), size() * INTSIZE);
}
void DrawElementsUInt::read(DataInputStream* in)
{
// Read DrawElementsUInt's identification.
int id = in-peekInt();
if(id == IVEDRAWELEMENTSUINT){
// Code to read DrawElementsUInt's properties.
id = in-readInt();
// If the osg class is inherited by any other class we should also read this from file.
osg::PrimitiveSet* prim = dynamic_castosg::PrimitiveSet*(this);
if(prim){
((ive::PrimitiveSet*)(prim))-read(in);
}
else
throw Exception(DrawElementsUInt::read(): Could not cast this osg::DrawElementsUInt to an osg::PrimitiveSet.);
// Read array length and its elements.
int size = in-readInt();
resize(size);
if (size!=0) in-readCharArray((char
Re: [osg-users] help to simulate SAR radar
sorry for my previous mail, I have make a wrong manipulation. I have an application made with OSG, this app simulate a fligh's cockpit. I need to add a radar view as SAR radar in the main view. I thought use multi post process render with some shader effects. I have a terrain that is loaded from ive files, and I want to use this to compute the radar's view. I never done somethink like radar view with OSG, and I need some help to start to produce the effect that I want I hope to have been the most clear as possible. Ben 2009/10/7 Tomlinson, Gordon gtomlin...@overwatch.textron.com Firstly your question is so open ended that your not going to get great help We handle the data but I'm unable to discuss what we do with it unfortunately If you do know the basics of OSG I would recommend you first learn that before proceeding (see the Quick start guide, you'll find a link on the OSG web site) Then it demands on what you want to do with the SAR data, has it been cleaned , processed, do you want to use this an imagery or as DEM, do you understand the SAR format, you will need to write an import tool to OSG to ingest either as imagery and or some form of elevation data, break the data in to manageable paging chunks etc.. There are many examples around they simply don't do it with SAR data just other data so you could use those as a basis for your own code *Gordon Product Manager 3d *__ *Gordon Tomlinson **Email * : gtomlinson @ overwatch.textron.com __ -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Benoît Poulard *Sent:* Wednesday, October 07, 2009 9:39 AM *To:* osg-users *Subject:* [osg-users] help to simulate SAR radar Hi, i need to make a SAR radar with OSG, and I don't know from where to begin. Has somebody an idea or an example of the way that I can use ? thank's Ben ___ 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] osg Simplifier and crash in ive writer
cannot give you the original file... and I tested it on a little file and it worked... So, these are the questions : Are there some limitation for the osg simplifier ? Is there a way to ask the simplifier to remove about 80% of the datas ? (destructive simplification of course) How can I use it better ? Thanks for your help Regards, Vincent __ Information from ESET NOD32 Antivirus, version of virus signature database 4485 (20091006) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4486 (20091007) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4486 (20091007) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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] Picking (computeIntersection) bug withPOINT_ROT_EYE Billboards
Nathan Monteleone wrote: I do have a conceptual question (for anyone) that's going to affect the fix: when doing intersection tests, should billboards point align to the start point of the intersector, or toward the eyepoint? Seems like it depends on the case -- if you're doing a pick based on a screen coordinate, you'd want it aligned to the eyepoint. But if you're using a point and a ray or two points, you probably do want the billboard pointed toward the start point, because those kinds of queries usually try to answer the question, If I were at point x looking toward point y, what would I see? If that behavior is really what we want, I think I can just fix it by changing the screen-coordinate forms of computeIntersection to explicitly set the reference eyepoint. An excellent question, and your argument makes perfect sense to me. On brief consideration, I can't think of a reason why you wouldn't orient the billboard based on the start point of the ray. There may be cases where you wouldn't, but I can't think of any at the moment. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Simplifier and crash in ive writer
of the file there is a crash... I cannot give you the original file... and I tested it on a little file and it worked... So, these are the questions : Are there some limitation for the osg simplifier ? Is there a way to ask the simplifier to remove about 80% of the datas ? (destructive simplification of course) How can I use it better ? Thanks for your help Regards, Vincent __ Information from ESET NOD32 Antivirus, version of virus signature database 4485 (20091006) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4486 (20091007) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4486 (20091007) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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 __ Information from ESET NOD32 Antivirus, version of virus signature database 4487 (20091007) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering problem
Adam Heppenstall wrote:
Hi,
Currently the rendering is handled by a thread which calls
while(!viewer.done)
{
viewer.frame);
}
but in the software there can be up to 3 viewers active at one time, all running a seperate thread to render, this is a CPU hog and ideally i want to only update the viewer if the scene has changed.
Does anybody know of any ways of detecting changes in the scene graph?
or a better way of handling the rendering?
How much of a hog is it? If you have vsync enabled, it shouldn't be
drawing more than 60 times a second or so. If you don't have it
enabled, try enabling it and see if that helps.
If you really only want to render when the scene changes, there were
some threads on the list a while a go about doing on-demand rendering.
You might try a search of the archives for those. Just be aware that
OSG wasn't designed for this usage, so you may run into a few issues
that not a lot of people have experience with.
As far as detecting changes, that's up to your application. I don't
think OSG can automagically do that for you.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::simplifier parameters
Hi,
I do an update on this topic, because I would like to understand well
the osgUtil::simlifier.
This implementation seems to be very complex and powerful, but I don't
know how to manage it better.
/For that I would like to know what do the following methods and how to
set the values to have the expected result :/
void setSampleRatio(float sampleRatio) { _sampleRatio =
sampleRatio; }
/** Set the maximum point error that all point removals must
be less than to permit removal of a point.
* Note, Only used when down sampling. i.e. sampleRatio 1.0*/
void setMaximumError(float error) { _maximumError = error; }
/** Set the maximum length target that all edges must be
shorted than.
* Note, Only used when up sampling i.e. sampleRatio 1.0.*/
Maybe this is a noob question, but I think it can help/inform other osg
users to know precisely how to configure the Simplifier...
I set the Sample ratio to values 1, and this seems to do some good job
on my model, but not enough... I am looking at a way to destruct a mesh
from 800 Mbyte (.ive) to 100Mbyte (.ive) (for LOD usage mainly)
I know the size of the ive file is not a good reference, but it is
important for my application. And I know that if a file is lesser, the
mesh will be lighter too...
Relative to that,
/What can make an ive file heavy// or light ?/ (example : 20M triangles
in a 850Mbyts ive file, not proportional to 13M triangles in a 710Mbytes
file)
Thanks for your help.
Regards,
Vincent.
Vincent Bourdier a écrit :
Hi Andrew
Thanks for the tip on the simplifier, lower the sample ratio is, lower
the vertex number is. (I get a crash under 0.6 but I'm not sure this
is an osg crash)
Concerning the optimiser, this do not reduce the vertex number but the
inverse... on a 460k vertices model, the optimizer returns me a 480k
vertices model ...
I'm looking for a destructive optimizer/simplifier for my model... Do
you have any other tips or idea ?
Thanks.
Regards,
Vincent.
2009/9/21 Andrew Burnett-Thompson aburnettthomp...@googlemail.com
mailto:aburnettthomp...@googlemail.com
Hi there,
I've experimented with the simplifier, but am not using it.
I found the setSampleRatio() method affects how coarse or fine a
result you get. The simplification with a sample ratio less that
1.0 appears to be destructive (i.e. Geometry out does not equal
Geometry in). So far I've not found the right settings to be
beneficial for my needs (which is reduction of memory consumption
while keeping the mesh the same or similar).
Another way of reducing the vertex count in your scene is to use
the Optimizer. Here I have found that using the Optimizer with the
options MERGE_GEOMETRY, CHECK_GEOMETRY and TRISTRIP_GEOMETRY can
significantly reduce the number of vertices/primitives in each
Geometry object, while giving you essentially the same mesh out.
On Mon, Sep 21, 2009 at 10:10 AM, Vincent Bourdier
vincent.bourd...@gmail.com mailto:vincent.bourd...@gmail.com
wrote:
Up ?
No one does osg simplifications ?
Thanks,
Vincent.
2009/9/17 Vincent Bourdier vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com
Hi all,
Using the osg simplifier on a geometry, I'm just surprised
to see that there is no way to set a level of
simplification or something like that.
Maybe I didn't saw it, but for the moment I just found
_sm-setDoTriStrip(true); //what for ? do triangle strip
are more optimized ?
_sm-setSampleRatio(?); //what does it mean ? what does it
changes ?
...
How can I control the simplification level ?
Is this simplifier a destructive one ? (can deform the
geometry)
Thanks.
Regards,
Vincent.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4487 (20091007) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clarification on use of Manipulators in CAD-Style app
Hi Robert, Robert Osfield wrote: Hi Vincent, On Tue, Oct 6, 2009 at 5:19 PM, Vincent Gadoury vgado...@humancad.com wrote: It seems there is a glitch with the new osgManipulator event handling and the TrackballManipulator. In the osgmanipulator example, if you keep ctrl or 'a' pressed when you rotate the trackball using the left mouse button, the trackball might get crazy (rotating of arbitrary - probably high - angle). The trick to reproduce the bug is to try to release the mouse button on a dragger. I'm able to reproduce it constantly. I was never able to reproduce it when the ctrl or 'a' key were not pressed. I tested it on revisions 10593 and 10606. Could you have a bash at tracking it down as I can't track down something I can't reproduce. I've done a little investigation and it is not directly related to osgManipulator, although the TabBoxDragger seems to create the perfect environnemnt to reproduce it (at least on my machine). The problem is that sometimes two mouse-dragging events are sent to the TrackballManipulator with a very little time difference. It might be system specific (I'm on Windows Vista 64-bit). If you happen to release the mouse button just after these events, the trackball's throwScale value will become huge (around 100 instead of around 1) and the trackball will start spinning randomly or zoom to great distances. I tracked the occurrence of these events by outputting the time difference on drag events in TrackballManipulator.cpp with something like: [code] static double lastDragTime = ea.getTime(); osg::notify(osg::NOTICE)dt: ea.getTime() - lastDragTimestd::endl; lastDragTime = ea.getTime(); [/code] I usually get time differences between 0.02 and 0.005, both with a key pressed or not. But in osgManipulator with a TabBoxDragger (or TabBoxTrackballDragger) in the scene, I start getting sparse events with a dt 0.0002. And if I keep any key pressed, I get these reading regularly about every second, which might be related to key repeating. It helps if you move the mouse quickly. I was also able to reproduce the glitch in osgteapot, where I get a few events with a dt around 7e-5, usually following dt 0.01. It seems unrelated to key state. Unfortunately, that's as deep as I can investigate. And I'm sorry about hijacking this topic with a not-so-related bug. Using the new osgManipulator with ctrl pressed was the first way I found to reproduce the glitch. regards, Vincent Gadoury ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hello, I am happy to see that others have the same problem, which means I am not crazy :-). I am going to try to port my application to trunk verstion of the OSG and to see if this issue was solved. Cheers, sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18044#18044 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text color not what I'm expecting
1. Fixed the typo in the subject. (now - not)
2. I discovered that if I remove the material setting at the geode
level, the material set in my osgText::Text instance takes effect.
I'm still confused.
Cory
Cory Riddell wrote:
Can somebody please take a look at the attached osg file. If you open it
with osgviewer, you will see the alphabet rendered at the bottom of the
screen (might be small) in white. I'm trying to figure out why the text
isn't black. I've set a material on my osgText::Text instance but it
seems to be ignored.
To find the text drawable, search for "ABCDEF". The material looks like:
Material {
UniqueID Material_106
ColorMode AMBIENT
ambientColor 0.2 0.2 0.2 1
diffuseColor FRONT 0 0 0 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 1 1 1 1
specularColor BACK 0 0 0 1
emissionColor 0 0 0 1
shininess FRONT 120
shininess BACK 0
}
Thanks.
Cory
___
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] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Kim, Kim Bale kcb...@googlemail.com wrote: Pankaj, Jan, J-S, I've now added a RELEASE_ONLY_BUILD option to the CMakeLists which removes the need for debug libraries. This is now committed to the osgOcean trunk. In visual studio this removes the debug projects from the build menu. Note: CMake will still look for the debug versions and list them as not found. This behaviour is is part of the CMake's own macros for finding OSG and openthreads so I thought it best to leave it as it is. However, as long as the release only build button is checked it will generate the build without complaining about them. I'd be grateful if you could test this for me. I've run it through VS2008 and it seemed to work but I haven't been able to test it on anything else. I have tried the current trunk and the option works on my Linux. However, I think you should make this type of a build the default. That will simplify the life of everyone who is not actively developing osgOcean, merely using it as a dependency. OSG itself has a release build as a default as well and one has to explicitly enable debug if it is required. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setUpViewerAsEmbeddedInWindow and wxPython glcanvas
On 2009-10-07, Robert Osfield robert.osfi...@gmail.com wrote: On Wed, Oct 7, 2009 at 1:32 AM, Randolph Fritz rfritz...@gmail.com wrote: One question: the osgViewerGLUT example holds the reference to its osgViewer::GraphicsWindow in an osg::observer_ptr, rather than an osg::ref_ptr. What's the reasoning behind that? I don't recall the code, but the use of observer_ptr rather ref_ptr is to not take ownership of an object, rather just observer it which it's alive and let other objects that actually own the object in question (i.e. the viewer) to destruct it when it's done. I see. Thanks. Now, if I can just resolve my CullVistor detected NaN problem... -- Randolph Fritz design machine group, architecture department, university of washington rfr...@u.washington.edu -or- rfritz...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with shader on ATI Radeon HD 4350
Hello all, I'm currently seeing a really weird problem with a shader on a Radeon HD 4350 card (both with drivers dating from July and with the most recent drivers dating 9/9/2009). The shader is rather convoluted, but the problem seems centered around code similar to this: float light = 1.0 if (shadows_enabled) light = shadow2DProj(shadowTexture, gl_TexCoord[1]).r; shadows_enabled is a uniform bool, and shadowTexture is a sampler2DShadow. Now, I know for a fact that at the root of my graph, shadow_enabled is set to false, and it is not changed anywhere in the graph. And I can also verify that the if is never entered by rendering everything white and changing it to black in the if. Nothing is rendered black. So the if is never entered. Nevertheless, here's the problem: if I keep the shadow2DProj line, objects seem to get textured with the wrong texture and be semi-transparent. It's really weird. I get no compile errors for the shader. If I comment out the shadow2DProj line and replace it by a dummy line like light = 0.0;, then all is well and the rendering is what I'd expect. I would expect results like that if the shadow2DProj line was being executed with a bad texture (perhaps because the shadow map texture was undefined) but the line isn't being executed... The other weird thing is that removing the other texture lookup I have in the shader (vec4 textureColor = texture2D(...);) but keeping the shadow2DProj line also works. So it seems that removing one or the other of these texture lookups works, but keeping them both (even if both are not executed) gives visual artifacts. Why would commenting a line that doesn't even get executed change the output of a shader? Is there a limit of number of texture lookups per shader, or something like that, on these cards? We actually don't have any other ATI cards in the office (this machine was built as a test to see if it would be viable) so I can't test on other cards to see if it's just the 4350 that has a problem with this shader. Can anyone suggest what might be wrong? I'm really clutching at straws here trying to figure out what the problem is, and I don't have a clue. Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi,
here's the code for normal interpolation I promised
osg::Vec3f OceanTile::normBiLinearInterp(float x, float y ) const{
float dx = x / _spacing;
float dy = y / _spacing;
unsigned int ix = dx;
unsigned int iy = dy;
dx -= ix;
dy -= iy;
osg::Vec3f s00 = getNormal(ix,iy);
osg::Vec3f s01 = getNormal(ix + 1,iy);
osg::Vec3f s10 = getNormal(ix,iy + 1);
osg::Vec3f s11 = getNormal(ix + 1,iy + 1);
return s00*(1.f - dx)*(1.f-dy) + s01*dx*(1.f-dy) + s10*(1.f - dx)*dy +
s11*dx*dy;
}
and the code for getSurfaceDataAt()
osg::Vec4f FFTOceanSurface::getSurfaceDataAt(float x, float y) {
if(_isDirty)
build();
const unsigned int SAMPLE_SIZE = 5;
//ocean surface coordinates
float oceanX, oceanY;
//value to return
osg::Vec4f surfData(0.0f,0.0f,0.0f,0.0f);
//df osg::Vec3f tileOffset;
//translate x, y to oceanSurface origin coordinates
oceanX = -_startPos.x() + x;
oceanY = _startPos.y() - y;
//calculate the corresponding tile on the ocean surface
unsigned int ix/*tile_x*/ = oceanX/_tileResolution;
unsigned int iy/*tile_y*/ = oceanY/_tileResolution ;
//This might not be corect but I don't want to ruin data encapsulation of
OceanDataType class
unsigned int frame = _oldFrame;
//Test if the tile is valid
if(ix _numTiles iy _numTiles){
const OceanTile data = _mipmapData[_oldFrame][0];//curData[
tile-getLevel() ];
float tile_x = oceanX - ix * _tileResolution;
float tile_y = oceanY - iy * _tileResolution;
osg::Vec3f norm = data.normBiLinearInterp(tile_x, tile_y);
surfData.x() = norm.x();
surfData.y() = norm.y();
surfData.z() = norm.z();
surfData.w() = data.biLinearInterp(tile_x, tile_y);
}
return surfData;
}
then you can position an object on the ocean surface by doing something like:
osg::Vec4f data(m_oceanSurface-getSurfaceDataAt (x,y));
then data.w() is the height and as rotation you can use something like:
(data.x()*180.0f/PI,data.y()*180.0f/PI,(1.0f - data.z())*180.0f/PI)
Cheers,
Dimitrios
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18049#18049
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Snow Leopard stl issues? (osg 2.9.5)
Hi again! :)
So it's just a problem with OSG in general it seems. I've tried building and
linking in many different ways, all end in segfaults when trying to get the
name of a node. I haven't tried much else because that's a pretty basic first
step.
The attached code also segfaults on OSX and runs fine on Linux so it's no
longer a Qt related issue as far as I can tell.
built with the following;
osx: g++ -framework osg -framework osgDB test.cpp -o test
linux: g++ -losg -losgDB test.cpp -o test
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18050#18050
#include iostream
#include string
using namespace std;
#include osg/Node
#include osg/Group
#include osg/NodeVisitor
#include osgDB/ReadFile
class EnumerateVisitor : public osg::NodeVisitor
{
public:
EnumerateVisitor(){}
virtual ~EnumerateVisitor(){}
virtual void apply(osg::Node node)
{
cout node.getName() endl;
traverse(node);
}
};
int main(int argc, char* argv[])
{
int result = 0;
osg::Group *root =
dynamic_castosg::Group*(osgDB::readNodeFile(argv[1]));
EnumerateVisitor visitor;
root-accept(visitor);
return result;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Resolved! Re: Text color not what I'm expecting
I'm not sure if this is correct, but it seems that my text was picking
up a material setting from some parent node. It was rendering the text
with the diffuse color from the material.
I ended up turning GL_LIGHTING off for my osgText::Text node and now
the text is being rendered with the color I was expecting.
One question, is the GL_LIGHTING bit the correct setting to turn off,
or is there a more correct way to turn of material usage for a drawable?
Thanks,
cory
Cory Riddell wrote:
1. Fixed the typo in the subject. (now - not)
2. I discovered that if I remove the material setting at the geode
level, the material set in my osgText::Text instance takes effect.
I'm still confused.
Cory
Cory Riddell wrote:
Can somebody please take a look at the attached osg file. If you open it
with osgviewer, you will see the alphabet rendered at the bottom of the
screen (might be small) in white. I'm trying to figure out why the text
isn't black. I've set a material on my osgText::Text instance but it
seems to be ignored.
To find the text drawable, search for "ABCDEF". The material looks like:
Material {
UniqueID Material_106
ColorMode AMBIENT
ambientColor 0.2 0.2 0.2 1
diffuseColor FRONT 0 0 0 1
diffuseColor BACK 0.8 0.8 0.8 1
specularColor FRONT 1 1 1 1
specularColor BACK 0 0 0 1
emissionColor 0 0 0 1
shininess FRONT 120
shininess BACK 0
}
Thanks.
Cory
___
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] Snow Leopard stl issues? (osg 2.9.5)
2009/10/7 Chip Collier pho...@gmail.com: Hi again! :) So it's just a problem with OSG in general it seems. I've tried building and linking in many different ways, all end in segfaults when trying to get the name of a node. I haven't tried much else because that's a pretty basic first step. The attached code also segfaults on OSX and runs fine on Linux so it's no longer a Qt related issue as far as I can tell. built with the following; osx: g++ -framework osg -framework osgDB test.cpp -o test linux: g++ -losg -losgDB test.cpp -o test -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18050#18050 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Chip, I have had similar trouble on Windows (and I use Leopard - not Snow Leopard - at home); it was related to third-party dependencies, which were compiled with mingw compiler (gcc) but I was using MSVC. On Mac OS X, I basically compiled every third party library myself and deleted entire third-party libraries I've fetched before, then removed fink as well. No offense, but fink people may have forgotten that Macs have universal binaries (Mach-O) that supports multiple platforms, not only i386. Just because uname reports so does not mean target should be _only_ i386. This was related to photo gallery I wanted to setup on my Mac Pro and it turned out that fink never had 64-bit binaries (apache2.2 is running as Intel 64 bit and I stood still - everything else should also support 64-bit rather than simply compiling apache for 32-bit. That's the right approach, I believe). Of course, my OSG build also benefit from that; all (3rd party) libraries are now Mach-O both x86_64 and i386. Nevertheless, I am not exactly sure that your problem is related to 32-64 bit conflicts, because run-time linker wouldn't load 32-bit-only libraries, if you compiled for 64-bit (or the other way around). So, problem may be different (e.g. compiler upgrade and broken ABI?). I think you should build everything with your current toolchain. I strongly recommend you to build all third party dependencies (libjpeg, png, zlib, etc.) with CFLAGS including both Intel platforms; namely, i386 and x86_64 *with your current toolset* (new Xcode? gcc45?) I myself didn't upgrade to Snow Leopard because I've experienced trouble when I first migrated to Leopard. So, I will wait until 10.6.3-4 and I may buy a copy of Snow Leopard afterwards. My Mac Pro was my last Apple product, and I will never buy another Apple product ever again with my free will (unless I have to). Ismail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Dimitrios Filiagos dfili...@yahoo.com wrote: Hi, here's the code for normal interpolation I promised Cool, this looks good. Jean-Se, Kim, could we get these things merged in, please? Right now I am maintaining my own patch based on Dimitrios's code, but this is really useful. Of course, the function needs to be exposed in the higher-level classes too, so that we can actually get to it from the viewer. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi Jan, Kim, However, I think you should make this type of a build the default. That will simplify the life of everyone who is not actively developing osgOcean, merely using it as a dependency. OSG itself has a release build as a default as well and one has to explicitly enable debug if it is required. I would make it the default on all platforms except Win32. Otherwise, people using osgOcean as a dependency on Windows will have their app crash. On windows you need to have debug OSG libraries anyways if you want to make a debug build of your app, so it's not any additional problem to make osgOcean require it too. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi Jan, Dimitrios, Cool, this looks good. Jean-Se, Kim, could we get these things merged in, please? Right now I am maintaining my own patch based on Dimitrios's code, but this is really useful. Of course, the function needs to be exposed in the higher-level classes too, so that we can actually get to it from the viewer. Send us the whole files of what you need and I'll have a look for sure. I'm not the one who needs this so I don't want to start guessing in which classes you need access to this... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hope this is the right way to post this (osgEphemeris problem with simple example)
Don Dakin wrote:
hi Donald,
[...]
When I try to load
osgEphemerisModel::EphemerisModel {
Latitude 38.4765
Longitude -122.493
SkyDomeRadius 10
}
in an .osg file I always get
no data loaded..
[...]
Post generated by Mail2Forum
The DLL osgdb_osgEphemeris.dll must be renamed osgdb_osgEphemerisModel.dll
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18055#18055
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Snow Leopard stl issues? (osg 2.9.5)
Hi, Chip Collier schrieb: Hi again! :) So it's just a problem with OSG in general it seems. I've tried building and linking in many different ways, all end in segfaults when trying to get the name of a node. I haven't tried much else because that's a pretty basic first step. The attached code also segfaults on OSX and runs fine on Linux so it's no longer a Qt related issue as far as I can tell. Can you check if root is NULL in your code? Perhaps you have problems with symbol visibilty, perhaps gcc 4.2 has some new defaults which breaks your code. dynamic_cast is done by comparing pointers to class-definitions, not via string comparision as on windows / visual studio. Perhaps you have two class definitions one in osgDB and one in your main.o. I tested your code on Snow Leopard with 2.9.x compiled with gcc 4.0.x with the deprecated XCode-projects part of the osg-distribution and the code worked without any problems. Also my big projects compile + run fine on Snow Leopard, but I am using gcc 4.0 and I am targeting 10.4. I haven't tried gcc 4.2 (the new standard compiler on OS X) because it targets 10.5 and up. HTH, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowCarbon with wxWidgets/wxMac
Hi Hartmut, Hartmut Seichter schrieb: I've seen somewhere in the list somebody had some success with using the GraphicsWindowCarbon within bare Carbon. Now I am trying the same with wxWidgets 2.8.10 and it seems not to work as expected (corrupted Window background). Did somebody on the list had some success and can share a code snippet? I got it working with GTK and Win32 (wxGTK and wxMSW respectively). I've done some tests integrating a GraphicsWindowCarbon into a webbrowser, and it worked somehow but I ditched it because of other reasons. How did you integrate the GraphicsWindowCarbon with your code? It's hard to help without seeing any code. If wxwidgets can work with cocoa I highly suggest the GraphicsWindowCococa backend, it's easier to integrate into existing apps. HTH, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi,
Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote:
Send us the whole files of what you need and I'll have a look for sure.
I'm not the one who needs this so I don't want to start guessing in
which classes you need access to this...
J-S
I need it in the following two: OceanScene and then OceanTechnique. I am
attaching the two modified headers. My FFTOceanSurface.cpp
and its header contain a similar function float getSeaHeight(float x, float y)
as the one Dimitrios originally posted. I am not sending those, because I
think his latest version is better and has the normal calculation too which
mine doesn't.
These changes allow to retrieve the sea surface height from the viewer, with
just a pointer to OceanScene instance.
Regards,
Jan
/*
* This source file is part of the osgOcean library
*
* Copyright (C) 2009 Kim Bale
* Copyright (C) 2009 The University of Hull, UK
*
* This program is free software; you can redistribute it and/or modify it under
* the terms of the GNU Lesser General Public License as published by the Free Software
* Foundation; either version 3 of the License, or (at your option) any later
* version.
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
* FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
* http://www.gnu.org/copyleft/lesser.txt.
*/
#pragma once
#include osgOcean/Export
#include osg/Geode
#include osgUtil/CullVisitor
#include osgGA/GUIEventHandler
namespace osgOcean
{
class OSGOCEAN_EXPORT OceanTechnique : public osg::Geode
{
public:
OceanTechnique( void );
OceanTechnique( const OceanTechnique copy, const osg::CopyOp copyop=osg::CopyOp::SHALLOW_COPY );
virtual const char* libraryName() const { return osgOcean; }
virtual const char* className() const { return OceanTechnique; }
virtual bool isSameKindAs(const osg::Object* obj) const { return dynamic_castconst OceanTechnique*(obj) != 0; }
virtual void build( void );
virtual void stopAnimation( void ){
_isAnimating = false;
}
virtual void startAnimation( void ){
_isAnimating = true;
}
bool isAnimating( void ) const{
return _isAnimating;
}
virtual float getSurfaceHeight(void) const;
inline bool isDirty(void) const{
return _isDirty;
}
inline void dirty(void){
_isDirty=true;
}
/** Check if the ocean surface is visible or not. Basic test is very
simple, subclasses can do a better test. */
bool isVisible( osgUtil::CullVisitor cv, bool eyeAboveWater );
/** Base class for the OceanTechnique event handler. Subclasses of
* OceanTechnique can subclass this to provide support for
* manipulating their particular properties, calling the base class
* handle() to inherit the base class's events (or not as desired).
* If subclasses subclass this handler, they need to override
* getEventHandler() in order for it to return the right concrete
* event handler instance.
*/
class EventHandler : public osgGA::GUIEventHandler
{
public:
EventHandler(OceanTechnique* oceanSurface);
virtual bool handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter aa, osg::Object*, osg::NodeVisitor*);
virtual void getUsage(osg::ApplicationUsage usage) const;
protected:
OceanTechnique* _oceanSurface;
};
/** Virtual constructor for OceanTechnique::EventHandler - override in
* derived classes to return subclass-specific handler if needed.
*/
virtual EventHandler* getEventHandler()
{
if (!_eventHandler.valid())
_eventHandler = new EventHandler(this);
return _eventHandler.get();
}
/*
* JC hacks
*/
virtual float getSeaHeightAt(float x, float y) = 0;
protected:
virtual ~OceanTechnique(void){};
protected:
bool _isDirty;
bool _isAnimating;
osg::ref_ptrEventHandler _eventHandler;
};
}
/*
* This source file is part of the osgOcean library
*
* Copyright (C) 2009 Kim Bale
* Copyright (C) 2009 The University of Hull, UK
*
* This program is free software; you can redistribute it and/or modify it under
* the terms of the GNU Lesser General Public License as published by the Free Software
* Foundation; either version 3 of the License, or (at your option) any later
* version.
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
* FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
*
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi Jan, Dimitrios, On the face of it this all looks good, but I'll take some time to review and test the code at the weekend, but as J-S says could you send the whole files where the changes are made as it makes my life a lot easier to test. Of course, the function needs to be exposed in the higher-level classes too, so that we can actually get to it from the viewer. Jan - I'm not sure what is meant by get to it from the viewer here? Cheers, Kim. 2009/10/7 Jan Ciger jan.ci...@gmail.com Dimitrios Filiagos dfili...@yahoo.com wrote: Hi, here's the code for normal interpolation I promised Cool, this looks good. Jean-Se, Kim, could we get these things merged in, please? Right now I am maintaining my own patch based on Dimitrios's code, but this is really useful. Of course, the function needs to be exposed in the higher-level classes too, so that we can actually get to it from the viewer. Regards, Jan ___ 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] Snow Leopard stl issues? (osg 2.9.5)
That's awesome to hear! Big thing for me is that I require the 10.6 SDK for OpenCL support so I'm trying to use the toolchain that supports this. If I grab information from the node other than the name such as the className I'll get a classname for each node in the scene. If I just do nothing to query modify the scene I can view everything without a problem which is why this is so vexing. The segfault occurs someplace in basic_str. I'll try your suggestions and see what comes of it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18061#18061 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
J-S, Jan, I'll have a look at how this is done in the OSG CMakelists, For the OSG, CMake has always defaulted to a debugrelease build configuration under windows, I just presumed that was the norm. Whilst we're on the issue, is a default release build standard behaviour for MacOS as well? Regards, Kim. 2009/10/7 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Jan, Kim, However, I think you should make this type of a build the default. That will simplify the life of everyone who is not actively developing osgOcean, merely using it as a dependency. OSG itself has a release build as a default as well and one has to explicitly enable debug if it is required. I would make it the default on all platforms except Win32. Otherwise, people using osgOcean as a dependency on Windows will have their app crash. On windows you need to have debug OSG libraries anyways if you want to make a debug build of your app, so it's not any additional problem to make osgOcean require it too. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Dear OSGlers, is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() - method with external viewer: see attached image, the menubar gets unusable - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. 2) using wxOSX (2.9 configure flag --with-osx_carbon) and branch 2.8 of OSG (carbon viewer) - GraphicsCanvas seems the only way to get it working proper I had to swap harddrive yesterday and went the whole plunge for SL - fighting now with STL problems reported earlier - I can't seem to be able to load files in Release but all works fine in Debug (this is for OSG 2.8 combined with wxWidgets 2.8) - it almost feels like Visual Studio now - sigh :( Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZattachment: wxOSX_OSG_trunk.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Kim Bale kcb...@googlemail.com wrote: Jan - I'm not sure what is meant by get to it from the viewer here? I am accessing the code like this within my viewer's main loop: // osgOcean::OceanTechnique *ocean; float height = ocean-getSeaHeightAt(pos.x(), pos.y()); ... Therefore the function needs to be exposed at the abstract OceanTechnique level already, not only in the FFTOceanSurface. It even makes sense - the sea surface height is likely not going to be dependent on which simulation technique you use to implement it. I have put a pure virtual function in the OceanTechnique which is then redefined in the FFTOceanSurface. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Hi Hartmut, li...@technotecture.com schrieb: is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. GraphicsWindowCocoa is the one who creates the NSView. You pass a windowdata with the flags CreateOnlyView to the constructor and after the GraphicsWindowCocoa is constructed you can query the NSView from the WindowData via getCreatedNSView() and add it to your NSWindow / NSView. For this method you'll have to create your window (or load it from a nib-file) yourself. Here's a small snippet: osgViewer::GraphicsWindowCocoa::WindowData* wdata = new osgViewer::GraphicsWindowCocoa::WindowData(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits(); traits-x = 0; traits-y = 0; traits-width = 800; traits-height = 600; traits-inheritedWindowData = wdata; traits-doubleBuffer = true; traits-sharedContext = 0; traits-vsync = true; // create graphics context osg::ref_ptrosgViewer::GraphicsWindowCocoa gc = dynamic_castosgViewer::GraphicsWindowCocoa*(osg::GraphicsContext::createGraphicsContext(traits.get())); NSView *view = wdata-getCreatedNSView(); // Mainview is the main-view of the window ... [mainview addSubview: view]; // add the view created by GraphicsWindowCocoa to the main-view If you want a NSWindow containing only one NSView, use the GraphicsWindowCocoa with a GraphicsWindowCocoa::WindowData(0), then GraphicsWindowCocoa does not create the app-specific stuff and returns the window only. You can get the NSWindow-reference via GraphicsWindowCocoa::getWindow() To recap the three options: CreateOnlyView: GraphicsWindowCocoa creates only the view (a NSOpenGLView) and store it in the WindowData-class (no window, nada) CheckForEvents: osgViewer queries the system for new events and handles them (mimicking the Cocoa event loop) . If you are using a real cocoa app which installs an event loop, you don't want this. PoseAsStandaloneApp: osgViewer constructs a standard menubar and installs some handler for it and some other stuff. If you are using a real cocoa app which handles the menubar automagically, you don't want this. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() I have no experience with setUpViewerAsEmbeddedInWindow but to my knowledge you'll have to manage the OpenGLContext (make current, swap, etc) by yourself - method with external viewer: see attached image, the menubar gets unusable see my previous notes about WindowData(0) - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. You'll have to be careful which thread handles the events. Mac OS X does not like, if you handle events on another thread than the main-thread. Perhaps WindowData(0) is your friend here, too. Hope this helps Cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Snow Leopard stl issues? (osg 2.9.5)
Hi, Ok well, I built the latest OpenSceneGraph from the svn repo with cmake (so no frameworks just dylibs) and it works fine. :) I did have to modify a couple of files to get it to build though: In the osgdb_lwo plugin the ID4 struct needed it's array renamed from id to ID to avoid a keyword clash (I guess id is a reserved word in ObjC in 10.6). I had to the modify any use of that struct with this update. In the osgdb_imageio plugin on line 979 of ReaderWriterImageIO.cpp the constructure was: ReaderWriterImageIO::ReaderWriterImageIO() which needed to simply be: ReaderWriterImageIO() And I had to modify the plugins CMakeLists file to exclude building osgdb_qt. After that everything built fine and once I linked with that build I was golden. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18066#18066 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Thanks Stephan, for the explanation - I will see if I can make this work with wxWidgets trunk. Cheers, H On Thu, 08 Oct 2009 01:06:31 +0200, Stephan Huber ratzf...@digitalmind.de wrote: Hi Hartmut, li...@technotecture.com schrieb: is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. GraphicsWindowCocoa is the one who creates the NSView. You pass a windowdata with the flags CreateOnlyView to the constructor and after the GraphicsWindowCocoa is constructed you can query the NSView from the WindowData via getCreatedNSView() and add it to your NSWindow / NSView. For this method you'll have to create your window (or load it from a nib-file) yourself. Here's a small snippet: osgViewer::GraphicsWindowCocoa::WindowData* wdata = new osgViewer::GraphicsWindowCocoa::WindowData(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits(); traits-x = 0; traits-y = 0; traits-width = 800; traits-height = 600; traits-inheritedWindowData = wdata; traits-doubleBuffer = true; traits-sharedContext = 0; traits-vsync = true; // create graphics context osg::ref_ptrosgViewer::GraphicsWindowCocoa gc = dynamic_castosgViewer::GraphicsWindowCocoa*(osg::GraphicsContext::createGraphicsContext(traits.get())); NSView *view = wdata-getCreatedNSView(); // Mainview is the main-view of the window ... [mainview addSubview: view]; // add the view created by GraphicsWindowCocoa to the main-view If you want a NSWindow containing only one NSView, use the GraphicsWindowCocoa with a GraphicsWindowCocoa::WindowData(0), then GraphicsWindowCocoa does not create the app-specific stuff and returns the window only. You can get the NSWindow-reference via GraphicsWindowCocoa::getWindow() To recap the three options: CreateOnlyView: GraphicsWindowCocoa creates only the view (a NSOpenGLView) and store it in the WindowData-class (no window, nada) CheckForEvents: osgViewer queries the system for new events and handles them (mimicking the Cocoa event loop) . If you are using a real cocoa app which installs an event loop, you don't want this. PoseAsStandaloneApp: osgViewer constructs a standard menubar and installs some handler for it and some other stuff. If you are using a real cocoa app which handles the menubar automagically, you don't want this. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() I have no experience with setUpViewerAsEmbeddedInWindow but to my knowledge you'll have to manage the OpenGLContext (make current, swap, etc) by yourself - method with external viewer: see attached image, the menubar gets unusable see my previous notes about WindowData(0) - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. You'll have to be careful which thread handles the events. Mac OS X does not like, if you handle events on another thread than the main-thread. Perhaps WindowData(0) is your friend here, too. Hope this helps Cheers, Stephan ___ 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] [3rdparty] How to run osgOcean
Hi, I have tried to run that example you suggested but the output.txt is empty after runing the example as ... osgviewer cow.osg output.txt 21 the example ran well i mean there was no problems as the cow.osg was loaded properly and i was able to see it in the osgViewer Thank you! gopal -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18068#18068 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] wxPython and CullVisitor nan on Mac
On 2009-10-07, Randolph Fritz rfritz...@gmail.com wrote: More details at http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-June/029500.html I have now confirmed that, just as Mike Wozniewski found in June, this problem occurs on Macintosh (MacBook Pro, Mac OS 10.5.8) but not on Linux (Ubuntu 8.04 LTS). I badly need it working on Windows or Mac, and would really rather have it working on Mac. Dare I hope that this problem has been debugged in the 2.8 trunk? (I have a few more tests to run if it hasn't already been fixed. Experimenting with osgviewerWX would probably be a good thing to try, but it's a nuisance to build against the MacPorts OSG.) -- Randolph Fritz design machine group, architecture department, university of washington rfr...@u.washington.edu -or- rfritz...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
