Re: [osg-users] vsync (was: OSG CPU usage)
Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGEdit 0.7.0 RC1
I have the same problem here, i can't compile it because my osg install is in a custom directory. I ll try to hack files to compile Jeremy L. Moles wrote: On Tue, 2007-11-06 at 20:11 +0100, Rubén López wrote: El lun, 05-11-2007 a las 12:19 -0500, Jeremy L. Moles escribió: On Mon, 2007-11-05 at 12:33 +0100, Harald A. wrote: HI, great to hear that a new version of osgedit is comming. here my evaluatoin report for the current rc1 Build was not realy easy, I really love the effort that goes into OSGEdit, but I can't help but agree with this. I'm more than competent when it comes to building software and using a development environment, and I just didn't have the energy required to fix the build system to make it work for me... I do not have installed my developmentstuff systemwide, and scons ignored my enviroment vars (LIBRARY_PATH, CPLUS_INCLUDE_PATH C_INCLUDE_PATH and also (in parts) CPATH) The migration from automake/autoconf to SCons have lost a lot of standard things like these that just worked automagically, and I am too used to install things system-wide (making my own debian packages if needed). Could you provide some pointer to documentation on the standard building variables? I will try to support them before the final release. Thanks. Sure. I'm anxious to get it working with as little effort as possible... however, if my work makes it easier in the long run then I'm more than willing to contribute. I can try my hand at it and submit a patch generated by svn diff--is this acceptable? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setClientActiveTextureUnit
Gents, In State::setClientActiveTextureUnit (State.cpp, line759) the test (I think) should be: if (_glClientActiveTexture unit (unsigned int)_glMaxTextureUnits) and not _glMaxTextureCoords Joseph Steel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer Screenshots (was picture-in-picture view)
Hi Berg, The ideal way to insert a capture of main camera would be to insert a custom osg::GraphicsOperation into set of rendering operations attached to each GraphicsContext that you want to capture, you need to insert this custom operation before after the cameras but before the swap buffer. Right now there isn't a convenient way of inserting this operation in the right place, we need to add some more API to GraphicsContext to do it, possible osgViewer::ViewerBase itself is something to extend as well to provide a high level way of add such operations. Until these methods are added, you'll need to make do with a post draw callback on the last camera to be drawn. Robert. On Nov 17, 2007 11:10 PM, Berg, Michael [EMAIL PROTECTED] wrote: Robert, Thanks for the tips. After experimenting with the code in the osghud example, I was finally able to get a basic version of what I wanted working with the CompositeViewer. However, I now have another question. I want to be able to take a screenshot of the entire screen. I currently have a PostDrawCallback that successfully takes a screenshot, but since this callback is set on the main scene's camera, it only takes a screenshot of the main scene (and doesn't include the contents of the additional view/camera in the corner). The setPostDrawCallback method is only available from osg::Camera Is there a way to remedy this? Or am I going to have to write code to individually screenshot every camera in the CompositeViewer and then stitch together and overlay each into a single screenshot? Thanks again, Michael Robert Osfield wrote: Hi Michael, osgViewer::CompositeViewer is the appropriate tool for this type of work, although you can use a slave camera in osgViewer::Viewer to as well, but this isn't as logically clean. The osghud examples provide a range of examples of use of an iscene graph camera, a slave camera, and a separate view - its for doing a HUD but the ideas are similar. As to why it isn't working for you, but best guess is that there is a rendering order issue with the cameras - the full screen view rendering after the insert view. osg::Camera has support for specifying the rendering order, so try something like insert_camera-setRenderOrder(osg::Camera::POST_RENDER); You can also provide an int to setRenderOrder as a second parameter to help differentiate between multiple post/pre draw cameras. 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] Problems when rendering multiple models
Hi Brain, It really sounds like you models and state are messed up, you shouldn't need to go round forcing state on to models if they are set up correctly in the first place. These two lines shout out problems to me: ss-setMode(GL_TEXTURE_COORD_ARRAY, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON); ss-setMode(GL_VERTEX_ARRAY, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF); osg::Geometry manages vertex arrays completely, you should never set these manually yourselves, if you do then you'll be screwing up osg::Geometry rendering and resulting in undefined results. The above settings are most likely hiding as well as causing problems in the in your osg::Geometry. I suspect you are adding bugs in you database attempt to fix bugs database. As for OVERRIDE, is this is not a topic covered in the the QuickStartGuide? Robert. On Nov 17, 2007 11:24 PM, Brian [EMAIL PROTECTED] wrote: Hi Robert, Thanks for the tips. One way that we have combatted this issue is to force the same basic StateSet on all the models. This works in some cases, but in others it does not. For example, we do the following stateset changes on each model: osg::StateSet* ss = Model-GetOSGNode()-getOrCreateStateSet(); ss-setMode(GL_LIGHTING, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON); ss-setMode(GL_LIGHT0, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON); ss-setMode(GL_LIGHT1, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF); ss-setTextureMode(0, GL_TEXTURE_2D, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON); ss-setTextureMode(1, GL_TEXTURE_2D, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF); ss-setTextureMode(2, GL_TEXTURE_2D, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF); ss-setTextureMode(3, GL_TEXTURE_2D, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF); ss-setMode(GL_TEXTURE_COORD_ARRAY, osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON); ss-setMode(GL_VERTEX_ARRAY, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF); ss-setMode( GL_CULL_FACE, osg::StateAttribute::OVERRIDE | osg::StateAttribute::OFF ); ss-setRenderingHint( osg::StateSet::OPAQUE_BIN ); ss-setMode(GL_ALPHA_BITS, 8); osg::AlphaFunc* alphafunc = new osg::AlphaFunc; osg::BlendFunc* blendfunc = new osg::BlendFunc; alphafunc-setFunction(osg::AlphaFunc::GREATER,0.08f); blendfunc-setFunction(osg::BlendFunc::SRC_ALPHA,osg::BlendFunc::ONE_MINUS_SRC_ALPHA); ss-setAttributeAndModes(alphafunc, osg::StateAttribute::ON); ss-setAttributeAndModes(blendfunc, osg::StateAttribute::OFF); I wasn't the one who decided on these values, so I don't really know if they are necessary or not. I do know that if they are removed, then our rendering is worse than ever. However, to me it seems that if the model's file is set up correctly, then very little StateSet manipulation would have to occur. Is this a correct assumption? Also, there is a bit of confusion in my office as to what effects OVERRIDE and PROTECTED have on a node. It's my understanding that if OVERRIDE is used on a node, then each of that node's children will be forced to use that state unless they have specifically set another value for that state as being PROTECTED. Thanks, Brian On Sat Nov 17 6:26 , 'Robert Osfield' [EMAIL PROTECTED] sent: Hi Brian, State leakage in the OSG normally suggests that your osg::Geometry don't have tex coordinates, normals or colour arrays assigned to them so they are just inheriting them from what was last sent to OpenGL, if you add more models then the draw order will jump around and your ill conditioned models will inherit a far wider range of state, exactly what they'll inherit will change from frame to frame. To fix it you have to find out what models are poorly conditioned and are missing required arrays - if a particular model has a problem then convert this one to .osg and have a browse through it to see what arrays are present and which ones are missing. Robert. On Nov 17, 2007 10:17 AM, Brian [EMAIL PROTECTED] wrote: Hi, I have a scene in which I am rendering various models on top of a terrain database. Without modifying any of the model's statesets, the scene renders horribly (textures missing from some models but not others, polygons for some models are rendered incorrectly shooting out in all directions, etc.) However, if I load them separately into the viewer application, they render perfectly fine. Does anyone have any tips for finding the perfect stateset so my models and terrain can render correctly? The models themselves are in IVE format. I had thought that I might be able to convert them all to the OSG format, and then I could modify the statesets for all the models to
Re: [osg-users] crash in GL2Extensions::glDeleteShader
HI Sherman, This type of problem is either down to a thread not having the context current, or a bug in the OpenGL driver. Has anyone else see this problem? Robert. On Nov 18, 2007 1:59 AM, sherman wilcox [EMAIL PROTECTED] wrote: I'm getting a crash in OpenSceneGraph/src/osg/program.cpp in the void GL2Extensions::glDeleteShader(GLuint shader) const function on this line: ((DeleteShaderProc)_glDeleteShader)(shader); The crash occurs in the debugger (VS 2005). This is on Vista 64 using a nVidia 8800 GTX w/latest drivers. I've tried OSG 2.2 Stable as well as the latest SVN trunk. This just started when I added an extremely simple shader to my app. Any tips on diagnosing this? Here's the call stack nvoglv32.dll!696fd3d6() [Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll] osg25-osgd.dll!osg::GL2Extensions::glDeleteShader(unsigned int shader=2) Line 627 + 0xe bytes C++ osg25-osgd.dll!osg::Shader::flushDeletedGlShaders(unsigned int contextID=0, double __formal=67.800656088972204, double availableTime=100.00) Line 78 C++ osg25-osgd.dll!osg::GraphicsContext::close(bool callCloseImplementation=true) Line 473 + 0x25 bytesC++ osg25-osgViewerd.dll!osgViewer::CompositeViewer::~CompositeViewer() Line 107 + 0x14 bytes C++ osg25-osgViewerd.dll!osgViewer::CompositeViewer::`vbase destructor'() + 0x1d bytes C++ osgvislib_driver_mfc.exe!osgViewer::CompositeViewer::`scalar deleting destructor'() + 0x34 bytesC++ osg25-osgd.dll!osg::Referenced::unref() Line 155 + 0x23 bytes C++ osgvislib_driver_mfc.exe!osg::ref_ptrosgViewer::CompositeViewer::~ref_ptrosgViewer::CompositeViewer() Line 30 + 0x47 bytes C++ ___ 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] osgViewer render loop
Hi Bob,
The answer is in the source ;-)
Viewer::run() is bascially equivilant to:
while(viewer.done())
{
viewer.frame();
}
And frame itself is bascially just a call to advance(),
eventTraversal(), updateTraversal() and renderTraversals() so can be
rewritten long hand:
while(viewer.done())
{
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();
viewer.renderingTraversal();
}
There is no delays adding it to control frame rate, this left entirely
up to the OpenGL fifo, which in the end is blocked by vysnc, the loop
doesn't switch off until done is called. If you write the frame loop
yourself as above they you can insert a block/sleep anyhow you want.
Don't forget Viewer::run() and Viewer::frame() are just convenience
methods, nothing more.
Robert.
In you own app what you need to do is write you own run method and add
in an optional sleep method into the above loop:
On Nov 17, 2007 10:38 PM, Robert Balfour [EMAIL PROTECTED] wrote:
Robert Osfield wrote:
As for window minimization issues, this is something that is windowing
dependent. I don't recall having done any work personally on
explicitly handling window minimization, the app should be getting the
events though so an event handler in the view could probably be used
to switch off the rendering frame loop while the window is minimized.
I have an event handler recognizing window minimization, but w.r.t. the
rendering frame loop, after osgViewer-run() how does the app control:
1. the max frame rate (i.e. limiting it to 30Hz or 60Hz)?
2. pausing/restarting the rendering frame loop?
Thanks.
Bob.
--
Robert E. Balfour, Ph.D.
Exec. V.P. CTO, BALFOUR Technologies LLC
960 South Broadway, Suite 108, Hicksville NY 11801
Phone: (516)513-0030 Fax: (516)513-0027 email: [EMAIL PROTECTED]
___
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] Collada plugin DAE flaws
Hi Roger,
The Dae plugin needn't call findDataFiles() at all if the Collada DOM
will do this for you, alternatively you could parse the URI string and
then make it into something that findDataFiles() can parse then pass
this final file back to the rest of the plugin in a form it can
handle.
Robert.
On Nov 18, 2007 7:56 PM, Roger James [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson
Sent: 18 November 2007 19:17
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Collada plugin DAE flaws
Hi Roger
I cannot seem to get a URI that will load of a network location, I have
tried /SomeMachine/somedir/somefile.dae and
file:/SomeMachine/somedir/somefile.dae and variations but cannot
load
I just get a file note found while it works locally
Can you load of a networked file ?
Sadly I only have access to release files for a while so cannot really
step
into it to find the issue ;(
[Roger James]
Hi Gordon.
I am afraid it worse than I intimated in my last message. Dae uses uris
internally but osg only expects file names to be passed to plugins.
The dae reader contains the following code
osgDB::ReaderWriter::ReadResult
ReaderWriterDAE::readNode(const std::string fname,
const osgDB::ReaderWriter::Options* options) const
{
SERIALIZER();
std::string ext( osgDB::getLowerCaseFileExtension(fname) );
if( ! acceptsExtension(ext) ) return ReadResult::FILE_NOT_HANDLED;
std::string fileName( osgDB::findDataFile( fname, options ) );
if( fileName.empty() ) return ReadResult::FILE_NOT_FOUND;
findDataFile will choke on the uri you passed to it.
You can browse the source at www.openscenegraph.org just select the Browse
Source option from the menu bar. You might have saved yourself a bit of
head scratching that way :-)
This means that only simple path names get through complex windows ones
break it.
I doubt if
\\?\UNC\server\share
Will work :-)
Roger
___
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] extracting silhouette edges
Hi, osgShadow::OccluderGeometry was writen entirely for the purpose of doing internal calculations for shadow volumes. It potentially could be reused for other tasks but it wasn't written with this in mind. For an example of how to use you'll need to look at the source code that invokes OccluderGeometry. Robert. On Nov 18, 2007 8:19 PM, Crni Gorac [EMAIL PROTECTED] wrote: Anyone having a pointer to some code employing OccluderGeometry class from osgShadow to extract silhouette edges from a given node of OSG graph? The class documentation is lacking; I tried to read the source too, and I strongly suspect it could be done but, well, I don't get it... Thanks. ___ 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] FW: osgdem produces strips
Hi Umit, What version of VPB/osgdem are you using? What platform are you on? When you say strips, could you post a screenshot? As a general note, please don't post multiple times to the list, be patient and wait, also check your own mail tool to see if its set up to ignore your own posts. Robert. On Nov 18, 2007 6:44 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi All; I have tried to make *.osga database with osgdem command but database produces a stripted diffuse picture on the screen! Why is it happen? I read the introduction to making a database from http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem and try this! I download the images from http://www.cc.gatech.edu/projects/large_models/ps.html But only different is that, I try 4097 × 4097 formatted image instead of 16385 × 16385 formatted. What should I do? If you know any other reference about virtualplanetbuilder please let me know? Thanks a lot..! Umit UZUN Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! Buraya tıkla! ___ 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] Documentation osgParticle::PrecipitationEffect?
On Nov 19, 2007 7:56 AM, Raymond de Vries [EMAIL PROTECTED] wrote: Hi everyone, I am looking for documentation about the PrecipitationEffect but could not find it in the books nor on the website. Does anyone have background information that is used for the implementation? I'm afraid there is no background information beyond the osgpreciption example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
On Nov 19, 2007 9:25 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? OpenGL drivers have a FIFO, your app fills the fifo with tokens and data, at the end of the frame you send in a swap buffers token and this goes into the FIFO with everything else. Normally the swap buffers call itself doesn't block (although some implementations do this), but the FIFO itself can only be cleared at the rate for one swap buffers call per frame so it'll fill and once filled up it will effectively block until previous frame was begun dispatching. The driver may allow several frames worth data in the fifo before block, this is driver dependent, and also dependent on just how data you have to pass to OpenGL- if you have massive models the CPU will be block on the FIFO right on the same frame rather than more than one frame begin backed in the FIFO. The end result of this is simpler though - put vsync on, and your frame loop will block and should iddle while its waiting for the FIFO to begin accepting new data. Some OpenGL drivers have been known to CPU resources when waiting rather than idling - ATI drivers were doing this for a while, but I believe this has now been fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setClientActiveTextureUnit
Hi Joseph, I'll need to a proper graphics review of the code. Could you post what you think is correct to osg-submissions. Cheers, Robert. On Nov 19, 2007 10:02 AM, Joseph Steel [EMAIL PROTECTED] wrote: Gents, In State::setClientActiveTextureUnit (State.cpp, line759) the test (I think) should be: if (_glClientActiveTexture unit (unsigned int)_glMaxTextureUnits) and not _glMaxTextureCoords Joseph Steel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem produces strips
Hi Umit, From the screenshot it looks to me like there are invalid values or input coordinates are just wrong, could you please post the osgdem options you've used. Robert. On Nov 19, 2007 11:29 AM, ümit uzun [EMAIL PROTECTED] wrote: Hi Robert; First of all I am so sorry for sending lots of mail, but ıt happened mistakenly. I am using hotmail and when I post the mail the server get an error lots of time so I did't know I send all of them and then I try another..! I am using VirtualPlanetBuilder/osgdem version 0.9.1 with OpenSceneGraph Library 2.2.0. I am using Linux with PARDUS distibution! I only try the introduction which lead to make osga in osg wiki. I add the screenshot and if you want I send the database. Thank you very much..! Hi Umit, What version of VPB/osgdem are you using? What platform are you on? When you say strips, could you post a screenshot? As a general note, please don't post multiple times to the list, be patient and wait, also check your own mail tool to see if its set up to ignore your own posts. Robert. On Nov 18, 2007 6:44 PM, ümit uzun wrote: Hi All; I have tried to make *.osga database with osgdem command but database produces a stripted diffuse picture on the screen! Why is it happen? I read the introduction to making a database from http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem and try this! I download the images from http://www.cc.gatech.edu/projects/large_models/ps.html But only different is that, I try 4097 × 4097 formatted image instead of 16385 × 16385 formatted. What should I do? If you know any other reference about virtualplanetbuilder please let me know? Thanks a lot..! Umit UZUN Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! Buraya tıkla! ___ 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 _ Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! http://get.live.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] osgViewer render loop
Robert Osfield wrote:
And frame itself is bascially just a call to advance(),
eventTraversal(), updateTraversal() and renderTraversals() so can be
rewritten long hand:
while(viewer.done())
{
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();
viewer.renderingTraversal();
}
There is no delays adding it to control frame rate, this left entirely
up to the OpenGL fifo, which in the end is blocked by vysnc, the loop
hm.. and which of the above calls block on vsync?
Akos
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgdem produces strips
Hi Robert; I used ; osgdem --xx 10 --yy 10 -t ps_texture_1k.tif \ --xx 10 --yy 10 -d ps_height_1k.tif \ -l 8 -v 0.1 -o puget.ive -a pegout.osga options like in introductions. Is there any simple example about vpb? I aim to make flight simulation, I have plane model and I only want to environment database with osga! Hi Umit, From the screenshot it looks to me like there are invalid values or input coordinates are just wrong, could you please post the osgdem options you've used. Robert. On Nov 19, 2007 11:29 AM, ümit uzun wrote: Hi Robert; First of all I am so sorry for sending lots of mail, but ıt happened mistakenly. I am using hotmail and when I post the mail the server get an error lots of time so I did't know I send all of them and then I try another..! I am using VirtualPlanetBuilder/osgdem version 0.9.1 with OpenSceneGraph Library 2.2.0. I am using Linux with PARDUS distibution! I only try the introduction which lead to make osga in osg wiki. I add the screenshot and if you want I send the database. Thank you very much..! Hi Umit, What version of VPB/osgdem are you using? What platform are you on? When you say strips, could you post a screenshot? As a general note, please don't post multiple times to the list, be patient and wait, also check your own mail tool to see if its set up to ignore your own posts. Robert. On Nov 18, 2007 6:44 PM, ümit uzun wrote: Hi All; I have tried to make *.osga database with osgdem command but database produces a stripted diffuse picture on the screen! Why is it happen? I read the introduction to making a database from http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem and try this! I download the images from http://www.cc.gatech.edu/projects/large_models/ps.html But only different is that, I try 4097 × 4097 formatted image instead of 16385 × 16385 formatted. What should I do? If you know any other reference about virtualplanetbuilder please let me know? Thanks a lot..! Umit UZUN Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! Buraya tıkla! ___ 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 _ Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! http://get.live.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 _ Yeni nesil Windows Live Servisleri’ne şimdi ulaşın! http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight Multi-Texture
This problem is fixed by correcting the error in setClientActiveTextureUnit Joseph Steel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joseph Steel Sent: 16 November 2007 14:51 To: OpenSceneGraph Users Subject: Re: [osg-users] OpenFlight Multi-Texture Here is a very small sample -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Martz Sent: 16 November 2007 14:40 To: OpenSceneGraph Users Subject: Re: [osg-users] OpenFlight Multi-Texture Can you post a small file that reproduces the issue? Sent from my iPhone On Nov 16, 2007, at 3:55 AM, Joseph Steel [EMAIL PROTECTED] wrote: In OSG2.2 is there a known issue with multiple textures in flight files. I've a terrain model with two textures but only the first appears. Joseph Steel ___ 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] osgViewer render loop
On Nov 19, 2007 11:39 AM, Ákos Maróy [EMAIL PROTECTED] wrote: hm.. and which of the above calls block on vsync? Its the OpenGL fifo which is doing the blocking, and its only Viewer::renderingTraversals() does the dispatching to OpenGL so... its renderingTraversals() that does the blocking. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] crash in osgParticle
Hi Deiter, There is too little info to know what might be up, so further exploring will need to be done. First up I'd try changing the threading model to single thread: export OSG_THREADING=SingleThreaded Then see if there is a crash. Robert. On Nov 19, 2007 12:07 PM, Dieter Pfeffer [EMAIL PROTECTED] wrote: Hi my application crashes in osgParticle, but I can't reproduce it. I am using 0sg 2.1.6 under linux; I have attached a screendump from the debugger Can s.o. give me a hint how I can find the problem or can s.o. see in the screendump something wrong Thanks Dieter Unclassified Mail ___ 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] vsync (was: OSG CPU usage)
On Nov 19, 2007, at 6:02 AM, Robert Osfield wrote: On Nov 19, 2007 9:25 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? in short: yes. OpenGL drivers have a FIFO, your app fills the fifo with tokens and data, at the end of the frame you send in a swap buffers token and this goes into the FIFO with everything else. Normally the swap buffers call itself doesn't block (although some implementations do this), but the FIFO itself can only be cleared at the rate for one swap buffers call per frame so it'll fill and once filled up it will effectively block until previous frame was begun dispatching. The driver may allow several frames worth data in the fifo before block, this is driver dependent, and also dependent on just how data you have to pass to OpenGL- if you have massive models the CPU will be block on the FIFO right on the same frame rather than more than one frame begin backed in the FIFO. The end result of this is simpler though - put vsync on, and your frame loop will block and should iddle while its waiting for the FIFO to begin accepting new data. Some OpenGL drivers have been known to CPU resources when waiting rather than idling - ATI drivers were doing this for a while, but I believe this has now been fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org bob kuehne founder and ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Taking screenshots using OSG 2.2
Hi Edu,
OpenGL calls including glReadPixels are all relative to 0,0 placed at
the lower left of the window, not 0,0 of the whole screen. By control
the window rectangle is relative to the whole screen.
Your glReadPixels should use the same values as the Camera's Viewport.
Robert.
On Nov 19, 2007 1:28 PM, Eduardo Gutiérrez Sanmartín
[EMAIL PROTECTED] wrote:
Robert, Ralph,
many thanks!
Now I am taking screenshots correctly.
I also had some problems getting the correct window position - I would like
to comment the solution that I found, so it is
in the same thread as the previous problem.
I am using the following code - with the two methods that I am trying:
class ScreenShotCallback: public osg::Camera::DrawCallback
{
private:
osgViewer::Viewer::Windows_windows;
osg::Image *_image;
public:
ScreenShotCallback(osgViewer::Viewer::Windows windows)
{
_windows = windows;
_image = new osg::Image();
}
~ScreenShotCallback() {};
void operator() (const osg::Camera camera) const
{
int x, y, width, height;
// FIRST METHOD:
_windows[0]-getWindowRectangle(x, y, width, height);
std::cout \n Window: x, y: x , y \t width x
height: width x height std::endl;
_image-readPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE);
osgDB::writeImageFile(*_image, capture1.bmp);
// SECOND METHOD:
x = (int) camera.getViewport ()-x();y = (int)
camera.getViewport()-y();
width = (int) camera.getViewport()-width(); height = (int)
camera.getViewport()-height();
std::cout \n Viewport: x, y: x , y \t width x
height: width x height std::endl;
_image-readPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE);
osgDB::writeImageFile(*_image, capture2.bmp);
}
};
int main(int argc, char** argv)
{
...
osgViewer::Viewer::Windowswindows;
viewer.getWindows(windows);
viewer.getCamera()-setPostDrawCallback( new ScreenShotCallback(windows)
);
viewer.run();
}
There is one funny thing going on here. With
_windows[0]-getWindowRectangle, all values printed in the console are
right,
but in the capture x and y are not correct. However, with
camera.getViewport()-x()... the x and y values
are always printed as zero, but the capture is correct. I have no idea about
why this is happening, but at the end of the day, camera.getViewport() works
fine! :)
Thanks again,
Edu
___
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] Collada plugin DAE flaws
I have a fix that allows URI's to be used
I have gone for the quick fix in that I'm not converting a UNC to a URI ( as
that could get messy )
But the loader now works with a URI
I'll post to submissions shortly
Gordon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Monday, November 19, 2007 5:45 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Collada plugin DAE flaws
Hi Roger,
The Dae plugin needn't call findDataFiles() at all if the Collada DOM will
do this for you, alternatively you could parse the URI string and then make
it into something that findDataFiles() can parse then pass this final file
back to the rest of the plugin in a form it can handle.
Robert.
On Nov 18, 2007 7:56 PM, Roger James [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson
Sent: 18 November 2007 19:17
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Collada plugin DAE flaws
Hi Roger
I cannot seem to get a URI that will load of a network location, I have
tried /SomeMachine/somedir/somefile.dae and
file:/SomeMachine/somedir/somefile.dae and variations but
cannot load I just get a file note found while it works locally
Can you load of a networked file ?
Sadly I only have access to release files for a while so cannot
really step into it to find the issue ;(
[Roger James]
Hi Gordon.
I am afraid it worse than I intimated in my last message. Dae uses
uris internally but osg only expects file names to be passed to plugins.
The dae reader contains the following code
osgDB::ReaderWriter::ReadResult
ReaderWriterDAE::readNode(const std::string fname,
const osgDB::ReaderWriter::Options* options) const {
SERIALIZER();
std::string ext( osgDB::getLowerCaseFileExtension(fname) );
if( ! acceptsExtension(ext) ) return ReadResult::FILE_NOT_HANDLED;
std::string fileName( osgDB::findDataFile( fname, options ) );
if( fileName.empty() ) return ReadResult::FILE_NOT_FOUND;
findDataFile will choke on the uri you passed to it.
You can browse the source at www.openscenegraph.org just select the
Browse Source option from the menu bar. You might have saved
yourself a bit of head scratching that way :-)
This means that only simple path names get through complex windows
ones break it.
I doubt if
\\?\UNC\server\share
Will work :-)
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] HUD Editor?
Has anyone put together a HUD editor for OpenSceneGraph? We are using OpenSceneGraph in ossimPlanet for global visualization and it is being used in government installations where they need to place titling information on their output. Some of the other tools they currently use have 2D overlay templates that can be applied for various types of data, organizations, and classification levels. Before starting to write our own, we were wondering if anyone had already developed anything along those lines. TIA Mark ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem produces strips
Hi Umit, I think the likely problem here is the --xx --yy and -v values are appropriate for the large input images, not the cut down 1k by 1k one. Typically one uses osgdem with geospecific imagery/DEMs such as GeoTiff's and this provides osgdem with all the data required to place the data in the correct position, only in cases where you don't have geospefic imagery/DEMs you need to add the extra definition of the size of the imagery for instance: osgdem -t myimgaery.tif -d mydem.tif -a mymodel.osga Will work just fine, all the heights and positions should be correct. You can pass in whole directories for input as well. See osgdem --help. Quite soon I'll be posting a VPB 0.9.2 version and will be write some online docs for the new features. Robert. On Nov 19, 2007 11:48 AM, ümit uzun [EMAIL PROTECTED] wrote: Hi Robert; I used ; osgdem --xx 10 --yy 10 -t ps_texture_1k.tif \ --xx 10 --yy 10 -d ps_height_1k.tif \ -l 8 -v 0.1 -o puget.ive -a pegout.osga options like in introductions. Is there any simple example about vpb? I aim to make flight simulation, I have plane model and I only want to environment database with osga! Hi Umit, From the screenshot it looks to me like there are invalid values or input coordinates are just wrong, could you please post the osgdem options you've used. Robert. On Nov 19, 2007 11:29 AM, ümit uzun wrote: Hi Robert; First of all I am so sorry for sending lots of mail, but ıt happened mistakenly. I am using hotmail and when I post the mail the server get an error lots of time so I did't know I send all of them and then I try another..! I am using VirtualPlanetBuilder/osgdem version 0.9.1 with OpenSceneGraph Library 2.2.0. I am using Linux with PARDUS distibution! I only try the introduction which lead to make osga in osg wiki. I add the screenshot and if you want I send the database. Thank you very much..! Hi Umit, What version of VPB/osgdem are you using? What platform are you on? When you say strips, could you post a screenshot? As a general note, please don't post multiple times to the list, be patient and wait, also check your own mail tool to see if its set up to ignore your own posts. Robert. On Nov 18, 2007 6:44 PM, ümit uzun wrote: Hi All; I have tried to make *.osga database with osgdem command but database produces a stripted diffuse picture on the screen! Why is it happen? I read the introduction to making a database from http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem and try this! I download the images from http://www.cc.gatech.edu/projects/large_models/ps.html But only different is that, I try 4097 × 4097 formatted image instead of 16385 × 16385 formatted. What should I do? If you know any other reference about virtualplanetbuilder please let me know? Thanks a lot..! Umit UZUN Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! Buraya tıkla! ___ 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 _ Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! http://get.live.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 _ Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! http://get.live.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] Collada plugin DAE flaws
-Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: 19 November 2007 13:35 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws I have a fix that allows URI's to be used I have gone for the quick fix in that I'm not converting a UNC to a URI ( as that could get messy ) But the loader now works with a URI I'll post to submissions shortly Gordon [Roger James] Robert, Gordon, I am not sure if we should be allowing URIs to be passed through the osg plugin interface. My interpretation is that the filename parameter of the interface should contain a valid filename format for the local system. I think most of the other plugins expect this. The dae plugin should then convert this to a URI that is acceptable (this means it does not have to be a full URI) for passing through the collada api. It is chance at the moment that the collada api accepts relative Unix style path names as valid URIs. What is your view on this Robert? This would mean that we can leave the call to findDataFiles() in the reader path so that the behaviour is the same as most of the other plugins. However findDataFiles _may_ need looking at to ensure it can handle all the valid file name formats for the system it is running on (e.g. UNC formats on windows). Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada plugin DAE flaws
The fix I submitted keeps the findDataFiles and simply us the path as given if findDataFiles fails this is enough to all URI to be used directly and not break any other working path formats While it may be better thing to have the reader convert paths to URI that's a bit trickier and current dead lines don't allow me the time to do this This works for us for now and also by submitting it we are complying with the license etc ;) Gordon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger James Sent: Monday, November 19, 2007 9:57 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: 19 November 2007 13:35 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws I have a fix that allows URI's to be used I have gone for the quick fix in that I'm not converting a UNC to a URI ( as that could get messy ) But the loader now works with a URI I'll post to submissions shortly Gordon [Roger James] Robert, Gordon, I am not sure if we should be allowing URIs to be passed through the osg plugin interface. My interpretation is that the filename parameter of the interface should contain a valid filename format for the local system. I think most of the other plugins expect this. The dae plugin should then convert this to a URI that is acceptable (this means it does not have to be a full URI) for passing through the collada api. It is chance at the moment that the collada api accepts relative Unix style path names as valid URIs. What is your view on this Robert? This would mean that we can leave the call to findDataFiles() in the reader path so that the behaviour is the same as most of the other plugins. However findDataFiles _may_ need looking at to ensure it can handle all the valid file name formats for the system it is running on (e.g. UNC formats on windows). Roger ___ 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] Collada plugin DAE flaws
Not much better English ;) Hi Roger The fix I submitted keeps the findDataFiles and simply uses the path as given if findDataFiles fails this is enough to allow the URI to be used directly and not break any other working path formats for the loader While it may be better thing to have the reader convert paths to URI that's a bit trickier and current dead lines don't allow me the time to do this This works for us for now and also by submitting it we are complying with the license etc ;), now the other big one is the scaling issue and models not being in scene units Gordon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger James Sent: Monday, November 19, 2007 9:57 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: 19 November 2007 13:35 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws I have a fix that allows URI's to be used I have gone for the quick fix in that I'm not converting a UNC to a URI ( as that could get messy ) But the loader now works with a URI I'll post to submissions shortly Gordon [Roger James] Robert, Gordon, I am not sure if we should be allowing URIs to be passed through the osg plugin interface. My interpretation is that the filename parameter of the interface should contain a valid filename format for the local system. I think most of the other plugins expect this. The dae plugin should then convert this to a URI that is acceptable (this means it does not have to be a full URI) for passing through the collada api. It is chance at the moment that the collada api accepts relative Unix style path names as valid URIs. What is your view on this Robert? This would mean that we can leave the call to findDataFiles() in the reader path so that the behaviour is the same as most of the other plugins. However findDataFiles _may_ need looking at to ensure it can handle all the valid file name formats for the system it is running on (e.g. UNC formats on windows). Roger ___ 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] Collada plugin DAE flaws
-Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: 19 November 2007 15:13 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws now the other big one is the scaling issue and models not being in scene units Gordon [Roger James] You could always open the dae file directly in your app and add the scale units and orientation to it. However, beware that if you do it you will run into what may be a fairly serious flaw in the collada library that at the moment needs you to mod the dae plugin to delete its DAE object on every pass, not hang on to it as at the moment. I have just spent the last 3 days tracking that down and am currently awaiting a response from the Sony guys on it. You may also come across this bug if you use the current plugin to save the same file name more than once in one session. https://sourceforge.net/forum/forum.php?thread_id=1871237forum_id=531264 Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada plugin DAE flaws
I got a headache reading that thread ;) Sadly we cannot change the files, we typically only get read access to most data Now I need to figure out how to get the units out of the loader when a file loads, then we could at least apply a scale and possible origin relocation at that time At some point in the future it would be nice to have an option for the loader that takes the scene units and then the loader can convert to that if needed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger James Sent: Monday, November 19, 2007 11:13 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: 19 November 2007 15:13 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws now the other big one is the scaling issue and models not being in scene units Gordon [Roger James] You could always open the dae file directly in your app and add the scale units and orientation to it. However, beware that if you do it you will run into what may be a fairly serious flaw in the collada library that at the moment needs you to mod the dae plugin to delete its DAE object on every pass, not hang on to it as at the moment. I have just spent the last 3 days tracking that down and am currently awaiting a response from the Sony guys on it. You may also come across this bug if you use the current plugin to save the same file name more than once in one session. https://sourceforge.net/forum/forum.php?thread_id=1871237forum_id=531264 Roger ___ 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 window Handle and c# interface
Hello, In my c# application I would like to create a Level Editor around an engine using osg. I need an user Interface in c# and an osg viewer in the c# window. My problem is I don't how to put the osg viewer inside my c# window. I think I need to set the window handle to the osg viewer with the handle off my c# window. I would like to know if it's possible to set the window handle (hwnd) to an osgviewer? I want to do that because I need to draw the osgviewer in the c# window. I know there is osgDotNet but I don't see any function which permit me to set the window handle. osgDotNet is a managed c++ wrapper of the osg c++ class. This permit to use osg in c# application. http://www.openscenegraph.org/projects/osgDotNet/wiki Regards ___ Romain Blanchais ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] the secret behind environment reflections on coated surfaces?
Hello, My name is Heiko Schulz and I'm fairly new to OpenSceneGraph. I'm one of the many 3D-model Developers in FlightGear, the Open-Source FlightSimulator which switched to OSG last year. The abilities for us increased, and the first are using some Effects from OSG like Particle and Cube Mapping. My interest now is a reflective effect on surfaces of aircrafts. A single chrome surface isn't a problem - a coated surface is more! (lke cars) I little bit experimented with MultiTexture- one texture unit with a environment cube mapping and the scond texture unit with the Aircraft texture. But it looked like colored chrome. Another try was to add TexEnv to the second Texture Unit- better, but it seems to me looking weird. So how can I create a realistic look of coated surfaces? Do I really need a shader? ( which isn't suopported yet by FlightGear) Regards Heiko Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada plugin DAE flaws
Frankly it's stupid that the Collada DOM can't save or load files properly using native file system paths. Just in the last week I fixed this in the latest DOM code in the svn repo on SourceForge. Now there are some general file path -- URI conversion functions in the DOM, and the DAE interface exposes loadFile, saveFile, etc methods to work with native file system paths. These functions work by converting a file system path to a URI and using the old load, save, etc methods, which still work with URIs only. So now you can write code like this: DAE dae; dae.loadFile(c:\myFile.dae); UNC paths should also work fine. I'm not sure if this helps you guys at all, since this code isn't in an official release of the DOM yet, but I still wanted to let you know. Steve Gordon Tomlinson wrote: I got a headache reading that thread ;) Sadly we cannot change the files, we typically only get read access to most data Now I need to figure out how to get the units out of the loader when a file loads, then we could at least apply a scale and possible origin relocation at that time At some point in the future it would be nice to have an option for the loader that takes the scene units and then the loader can convert to that if needed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger James Sent: Monday, November 19, 2007 11:13 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: 19 November 2007 15:13 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Collada plugin DAE flaws now the other big one is the scaling issue and models not being in scene units Gordon [Roger James] You could always open the dae file directly in your app and add the scale units and orientation to it. However, beware that if you do it you will run into what may be a fairly serious flaw in the collada library that at the moment needs you to mod the dae plugin to delete its DAE object on every pass, not hang on to it as at the moment. I have just spent the last 3 days tracking that down and am currently awaiting a response from the Sony guys on it. You may also come across this bug if you use the current plugin to save the same file name more than once in one session. https://sourceforge.net/forum/forum.php?thread_id=1871237forum_id=531264 Roger ___ 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] shared points (between OSG and the application using OSG)
On 10/25/06, Soheil Sotoodeh [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks, I've checked that, it is a quite extensive
documentation.
I also have two question about the basic types.
Consider that we have a point cloud (a set of points).
As far as I understood, in openGL when we add the
pointcloud by a sequence of glVertex calls, openGL
makes a copy of the coordinate values. Now when we
have OSG we add the points by a osg::Geometry object.
[snip]
Q2: Is there any approach that I can use a custom
point/vec3 (my own type) instead of osg::Vec3 in
osg::Geometry?
By that I mean having shared point objects for both
OSG and my application.
[snip]
Thanks for your suggestions,
Cheers,
Soheil
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: shared points (between OSG and the application using OSG)
Hi Shoeil,
With real-time graphics go often end up with 3 copies of your imagery
and vertex data, one on the CPU side, one on the OpenGL driver, and
one on GPU.
The OSG supports deallocating imagery automatically once its passed
to OpenGL, so that only OpenGL retains it as a texture object.
Potentially you can do this on the geometry side too, but there are
more pitfalls as all your intersection code will fail.
As for passing custom geometry to osg::Geometry, perhaps subclassing
osg::Array will be sufficient. Not all OSG ops will work though, even
if the graphics works fine.
Hi Robert. I'm currently trying exactly what you describe here.
Creating my own subclass of osg::Array and using it as the vertex
array for a osg::Geometry. I've run into a few rough spots.
Geometry.cpp contains things like this:
const Vec2Array* vec2Array = 0;
const Vec3Array* vec3Array = 0;
const Vec4Array* vec4Array = 0;
Array::Type type = _vertexData.array-getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_castconst
Vec2Array*(_vertexData.array.get());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3Array*(_vertexData.array.get());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
Vec4Array*(_vertexData.array.get());
break;
default:
notify(WARN)Warning: Geometry::accept(PrimtiveFunctor) cannot
handle Vertex Array type
_vertexData.array-getType()std::endl;
return;
}
which means that user-defined subclasses of Array are not supported.
I could have my subclass return one of the existing values for
getType, but then the static_cast is not correct. I worked around
that with something like this:
const Vec2* vec2Array = 0;
const Vec3* vec3Array = 0;
const Vec4* vec4Array = 0;
Array::Type type = _vertexData.array-getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_castconst
Vec2*(_vertexData.array-getDataPointer());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3*(_vertexData.array-getDataPointer());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
Vec4*(_vertexData.array-getDataPointer());
break;
default:
notify(WARN)Warning: Geometry::accept(PrimtiveFunctor) cannot
handle Vertex Array type
_vertexData.array-getType()std::endl;
return;
}
and that seems to work OK, but it's not clear to me whether this
is how you intend getType to be used. Do you think that getType is
telling an Array's user what type of data it is holding, or what
type of Array class it is? Currently the two are the same, but if
you add new subclasses of Array, then the difference becomes
important.
There are a few other, similar downcasts of Array in Geometry.cpp.
I haven't seen any in other files.
The application here is that we have geometric data that is
already stored in something other than a std::vector and I'd like
to wrap it up for OSG's use without making a copy. What do you
think would be the best approach here?
Thanks,
- Mike Garrity
- The MathWorks
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] the secret behind environment reflections on coated surfaces?
HI Heiko, The way to do sophisticated lighting models on objects is to use shaders, I'm not familar with flight gear internals but I would have thought if you create a .osg file with a shader in place (like the glsl_*.osg examples in the OpenSceneGraph-Data distributed) and then load this as your aircraft model. Other approaches would be to use a cube map approach, the osgcubemap provides an example of specular highlight which be roughly what you are after. Try: osgcubemap cessna.osg Also have a look at the osgFX::SpecularHighlights node as a means for decorating the aircraft subgraphs to create the effect. Robert. On Nov 19, 2007 6:14 PM, Heiko Schulz [EMAIL PROTECTED] wrote: Hello, My name is Heiko Schulz and I'm fairly new to OpenSceneGraph. I'm one of the many 3D-model Developers in FlightGear, the Open-Source FlightSimulator which switched to OSG last year. The abilities for us increased, and the first are using some Effects from OSG like Particle and Cube Mapping. My interest now is a reflective effect on surfaces of aircrafts. A single chrome surface isn't a problem - a coated surface is more! (lke cars) I little bit experimented with MultiTexture- one texture unit with a environment cube mapping and the scond texture unit with the Aircraft texture. But it looked like colored chrome. Another try was to add TexEnv to the second Texture Unit- better, but it seems to me looking weird. So how can I create a realistic look of coated surfaces? Do I really need a shader? ( which isn't suopported yet by FlightGear) Regards Heiko Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail ___ 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] shared points (between OSG and the application using OSG)
Hi Mike,
I'm really cold on this topic right now, and can't really add much
without sitting down and spending time reviewing all the related code,
alas I have very little time for such activities right now.
What might help is to create an OSG example that demonstates what you
are trying to do and highlights the problem points. This example
could then be reviewed by others and checked into the OSG distribution
for testing purposes and for helping out others who walk this path in
the future.
Cheers.
Robert.
On Nov 19, 2007 7:34 PM, Mike Garrity [EMAIL PROTECTED] wrote:
On 10/25/06, Soheil Sotoodeh [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks, I've checked that, it is a quite extensive
documentation.
I also have two question about the basic types.
Consider that we have a point cloud (a set of points).
As far as I understood, in openGL when we add the
pointcloud by a sequence of glVertex calls, openGL
makes a copy of the coordinate values. Now when we
have OSG we add the points by a osg::Geometry object.
[snip]
Q2: Is there any approach that I can use a custom
point/vec3 (my own type) instead of osg::Vec3 in
osg::Geometry?
By that I mean having shared point objects for both
OSG and my application.
[snip]
Thanks for your suggestions,
Cheers,
Soheil
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: shared points (between OSG and the application using OSG)
Hi Shoeil,
With real-time graphics go often end up with 3 copies of your imagery
and vertex data, one on the CPU side, one on the OpenGL driver, and
one on GPU.
The OSG supports deallocating imagery automatically once its passed
to OpenGL, so that only OpenGL retains it as a texture object.
Potentially you can do this on the geometry side too, but there are
more pitfalls as all your intersection code will fail.
As for passing custom geometry to osg::Geometry, perhaps subclassing
osg::Array will be sufficient. Not all OSG ops will work though, even
if the graphics works fine.
Hi Robert. I'm currently trying exactly what you describe here.
Creating my own subclass of osg::Array and using it as the vertex
array for a osg::Geometry. I've run into a few rough spots.
Geometry.cpp contains things like this:
const Vec2Array* vec2Array = 0;
const Vec3Array* vec3Array = 0;
const Vec4Array* vec4Array = 0;
Array::Type type = _vertexData.array-getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_castconst
Vec2Array*(_vertexData.array.get());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3Array*(_vertexData.array.get());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
Vec4Array*(_vertexData.array.get());
break;
default:
notify(WARN)Warning: Geometry::accept(PrimtiveFunctor) cannot
handle Vertex Array type
_vertexData.array-getType()std::endl;
return;
}
which means that user-defined subclasses of Array are not supported.
I could have my subclass return one of the existing values for
getType, but then the static_cast is not correct. I worked around
that with something like this:
const Vec2* vec2Array = 0;
const Vec3* vec3Array = 0;
const Vec4* vec4Array = 0;
Array::Type type = _vertexData.array-getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_castconst
Vec2*(_vertexData.array-getDataPointer());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3*(_vertexData.array-getDataPointer());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
Vec4*(_vertexData.array-getDataPointer());
break;
default:
notify(WARN)Warning: Geometry::accept(PrimtiveFunctor) cannot
handle Vertex Array type
_vertexData.array-getType()std::endl;
return;
}
and that seems to work OK, but it's not clear to me whether this
is how you intend getType to be used. Do you think that getType is
telling an Array's user what type of data it is holding, or what
type of Array class it is? Currently the two are the same, but if
you add new subclasses of Array, then the difference becomes
important.
There are a few other, similar downcasts of Array in Geometry.cpp.
I haven't seen any in other files.
The application here is that we have geometric data that is
already stored in something other than a std::vector and I'd like
to wrap it up for OSG's use without making a copy. What do you
think would be the best approach here?
Thanks,
- Mike Garrity
- The MathWorks
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
[osg-users] OSG Training, Washington DC, USA, January 22-24, 2008
Hi OSG Users -- Registration is now open for OSG training in Washing ton DC, USA, January 22-24, 2008. To register, visit http://www.skew-matrix.com and click Training. This training event is co-instructed by Bob Kuehne (Blue Newt Software) and myself, Paul Martz (Skew Matrix Software). Bob and I have been hard at work refining our existing course and making it even better, while at the same time, adding a new terrain day to it, focusing on the latest with OSG and large terrain databases. The training will be held in the heart of Washington DC -- easy train, metro, and parking, all near the location. We're offering two courses over three days. Here's how it breaks down: January 22 23: OSG Intermediate course We'll teach you everything you need to know to move from basic OSG usage, to pretty detailed and comprehensive library features. Here's what you'll learn: * Memory management * Nodes, various node types, custom nodes and NodeKits * Traversals, NodeVisitors, Callbacks * Data manipulation tools * Drawables, Geometry, and state * Using plugins * Threads * Viewing and camera manipulation * Window system integration * Optimization techniques Finally, if you choose to stay for day 3, we're focusing on terrain: January 24: Terrain Databases in OSG This 1-day course covers creation and rendering of large terrain/urban databases in OSG. Topics covered include: * Large data set construction, display, and optimization * Paged data sets * Network served data * VirtualPlanetBuilder data generation * Shading * Tools Workflow Please register for one or both courses. We're looking forward to seeing you in January. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 Bob Kuehne Blue Newt Software LLC http://www.blue-newt.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
but does this mean that if I call rendering blocks unti the next vsync clock tick? It's really implementation dependent. The NVIDIA OpenGL driver on Windows, for example, allows you to issue a certain number of SwapBuffers calls before it blocks. I think the default is 2 calls, but this is controllable with a driver setting and can be as high as 10 (I think). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] crash in GL2Extensions::glDeleteShader
Familiar looking stack trace... Not that this will help you, but we were getting this an awful lot in both release and debug builds. The specific situation was that we had a subclass of an OpenThreads thread that had an osgViewer::Viewer as a member - or actually, we had a ref_ptr to the viewer as a member. The Viewer was realised() during the first thread::run. Trying to - carefully and gracefully, we thought - explicitly destroy the viewer by doing my_viewer = 0 in the thread's destructor (or anywhere else, in fact) resulted in exactly this error - i.e. a crash in the glDeleteShader call. Oddly, it went away if we didn't explicitly delete the viewer in the threads destructor, i.e. just let the ref_ptr decrement to zero and self delete. We got this behaviour for both CompositeViewer, and regular Viewer. I even got as far as preparing a similar osg-users plea for help, although I never sent it. Since the problem went away, we didn't try to reproduce the issue, so can't be much more helpful (deadlines, and all). This was on WinXP, 2-core, .NET, ATI GPUs. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet and exceptions
Hi Christoffer, Which version of OSG are you using with osgDotNet? There are still known problems with versions post 2.0. I wouldn't recommend using it in a production capacity with 2.2 or later until those are resolved. -Mike On Sun, Nov 18, 2007 at 09:30:42AM +0100, Christoffer Markusson wrote: Hi, I'm using osgDotNet in a Visual Studio project and are getting lots of exceptions thrown when running a release build of this project. The exceptions seems to happen at random but are always caused by calls to osg methods. Typically the error message is tried to read or write write protected memory. If I ignore the exceptions and just continue, the application still functions, but this is not a desirable solution. I know that it is a fuzzy question, but does anyone have any idea what could cause this? Is it OK to use the provided osgDotNet dll's in a release build? Are there some special considerations I should know about? I can provide more detailed info if anyone wants it. Christoffer ___ 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] CMake Search Paths ?
Hi, This may be an issues with the developers of cmake but I've had a difficult experience building OSG 2.2 official release on IRIX 6.5 using the cmake build process. Problems namely with specifying my own /include /lib paths. it seems to want to ignore any arguments I pass to it , I don't think Cmake even reads the PATH env variable . To solve this I've had to hard code the paths in CMakeCache and CmakeLists.txt and other areas in order for OSG to build with the headers and libs I want. Even using the SET command in CmakeLists.txt doesn't seem to fix the problem. It seems to me that Cmake has a set of hardcoded directories that it will search. Is there a simpler way to give cmake user defined search paths? Other modules I had to alter to make cmake search the directories I specify: In CmakeModules/ for all search paths: FIND_LIB /usr/nekoware/lib /usr/freeware/lib64 FIND_INCLUDE /usr/nekoware/include /usr/freeware/include /src/osgPlugins/jpeg/CMakeFiles/osgdb_jpeg.dir added: /usr/nekoware/lib/libjpeg.so I also wonder if cmake builds osg on 64 bit platforms in 64 bit? or does it build in 32 bit? How can you tell or know what cmake is doing? Regards Paul IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake Search Paths ?
There are a bunch of ways to deal with this. You shouldn't modify the CMakeCache directly. And you really shouldn't need to modify the CMakeLists.txt. 1) Use the ccmake instead of cmake. It exists for this very reason and is the easiest, most reliable answer. (I constantly beg people to use this so we don't get these kinds of questions over and over.) 2) Define the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH environmental variables. See the CMake documentation, but essentially: export CMAKE_LIBRARY_PATH=/usr/nekoware/lib 3) Define the OSGDIR environmental variable or OSG_ROOT environmental variable. This is something we put in, though I'm not sure if it is consistently applied everywhere yet. 4) Not recommended, but still better than editing the CMakeCache (but not by much), use the cmake -D var:type=value switch to explicitly set values. See the CMake documentation. -Eric On 11/19/07, Paul Pocock [EMAIL PROTECTED] wrote: Hi, This may be an issues with the developers of cmake but I've had a difficult experience building OSG 2.2 official release on IRIX 6.5 using the cmake build process. Problems namely with specifying my own /include /lib paths. it seems to want to ignore any arguments I pass to it , I don't think Cmake even reads the PATH env variable . To solve this I've had to hard code the paths in CMakeCache and CmakeLists.txt and other areas in order for OSG to build with the headers and libs I want. Even using the SET command in CmakeLists.txt doesn't seem to fix the problem. It seems to me that Cmake has a set of hardcoded directories that it will search. Is there a simpler way to give cmake user defined search paths? Other modules I had to alter to make cmake search the directories I specify: In CmakeModules/ for all search paths: FIND_LIB /usr/nekoware/lib /usr/freeware/lib64 FIND_INCLUDE /usr/nekoware/include /usr/freeware/include /src/osgPlugins/jpeg/CMakeFiles/osgdb_jpeg.dir added: /usr/nekoware/lib/libjpeg.so I also wonder if cmake builds osg on 64 bit platforms in 64 bit? or does it build in 32 bit? How can you tell or know what cmake is doing? Regards Paul IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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
