Re: [osg-users] more on Windows debugging
Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? Yes. PDB is a huge container of various information. It contains both relative paths (prefixed with ./) and absolute paths of my source files. Also contains whole commands used to compile and link. I googled PDB a little. Found few interesting links but nothing realy spectacular. Some information on microsoft site says that copying .pdb files to working directory may help: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 : The new Visual C++ debugger uses the project.PDB file created by the linker directly, and embeds the absolute path to the .PDB in the .EXE or .DLL file. If the debugger can't find the .PDB file at that location or if the path is invalid (if, for example, the project was moved to another computer), the debugger looks for it in the current directory. If you are desperate you may try to grab DIA sdk and build dia2dump example and see what exactly your PDB contains. http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx Hope it helps, Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, September 26, 2007 10:34 PM Subject: RE: [osg-users] more on Windows debugging Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from my app dir I was still able to step into OSG sources. Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for OpenThreadsd.pdb string. There is only one line containing this string and this line contains full absolute path to the place where OpenThreadsd.pdb was built. In my case this is C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB in hexeditor. PDB seems to keep all the absolute paths to the source cpp files. My PDB still resides in this directory where DLL points (ie where DLL was linked) and my source OSG cpp files are still at the same directory where PDB points (ie where they were compiled). DLL may be moved wherever I want and VS is still able to find the sources. I guess VS first loads DLL, reads the PDB absolute path, then loads PDB and finds absolute paths to sources. I suppose VS may have trouble if PDB or cpp files absolute paths change. But it looks that DLL can be moved freely. PS. I use VS 2005 SP1 maybe it matters. Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Skinner Sent: Wednesday, September 26, 2007 7:26 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks. I have some of the same setup, but I don't get OSG from the place where I built it. I'm afraid that moving the dlls has lost their connection with the source. I've got paths set to specify the source, but it doesn't seem to be helping, in the same way it didn't help you to remove them. :) thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 11:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Below is my OSG configuration. Apparently it works well with Visual Studio 2005 Express intellibase as I am able to step down into OSG sources from my OSG based projects. This may be no solution for you but I hope it may be helpful somehow if you will be able to find differences and maybe finally isolate the cause of the problems. 1. I keep all my projects in C:\DEV directory. All OSG svn related projects are kept in C:\DEV\OSG_SVN\ directory. And OpenSceneGraph distribution is located in C:\DEV\OSG_SVN\OpenSceneGraph. 2. After OpenScenGraph SVN update I run CMake and change OSG
Re: [osg-users] Transparency problem
Hello everybody. I have a transparency problem which you can see in the attached image. As you can see the strings rendered on the orange window, which is in front of another blue window, have a blue outline from the blue window behind. The strings are in front of a semi-transparent rectangle in front of the semi-transparent window. What might be happening? Hi! I had the same problem with billboards and I fixed it with setting the stateset's RenderBinNumber. RenderBins in OSG is used to specify which objects are going to be drawn first. -- Andreas Richter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] more on Windows debugging
Hi guys Just my 2 cents: have you tried to put the pdb files along with the DLLs ? My post-build step copies all the DLLs and the PDBs and stores them in the same folder (say 'c:\libs\bin' - must be in %PATH%), and I've never experienced any problems, except when a PDB does not match a DLL - which is expected. This technique works with all the libraries I've been working with so far, not only the OSG. The only drawback is that PDBs are huge files and make the post-build step a bit slow. Thibault On 9/26/07, Andy Skinner [EMAIL PROTECTED] wrote: Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from my app dir I was still able to step into OSG sources. Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for OpenThreadsd.pdb string. There is only one line containing this string and this line contains full absolute path to the place where OpenThreadsd.pdb was built. In my case this is C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB in hexeditor. PDB seems to keep all the absolute paths to the source cpp files. My PDB still resides in this directory where DLL points (ie where DLL was linked) and my source OSG cpp files are still at the same directory where PDB points (ie where they were compiled). DLL may be moved wherever I want and VS is still able to find the sources. I guess VS first loads DLL, reads the PDB absolute path, then loads PDB and finds absolute paths to sources. I suppose VS may have trouble if PDB or cpp files absolute paths change. But it looks that DLL can be moved freely. PS. I use VS 2005 SP1 maybe it matters. Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Skinner Sent: Wednesday, September 26, 2007 7:26 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks. I have some of the same setup, but I don't get OSG from the place where I built it. I'm afraid that moving the dlls has lost their connection with the source. I've got paths set to specify the source, but it doesn't seem to be helping, in the same way it didn't help you to remove them. :) thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 11:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Below is my OSG configuration. Apparently it works well with Visual Studio 2005 Express intellibase as I am able to step down into OSG sources from my OSG based projects. This may be no solution for you but I hope it may be helpful somehow if you will be able to find differences and maybe finally isolate the cause of the problems. 1. I keep all my projects in C:\DEV directory. All OSG svn related projects are kept in C:\DEV\OSG_SVN\ directory. And OpenSceneGraph distribution is located in C:\DEV\OSG_SVN\OpenSceneGraph. 2. After OpenScenGraph SVN update I run CMake and change OSG INSTALL directory variable to '.' (dot - current directory). It has the effect that install will make bin and lib subdirectories in OpenSceneGraph root directory. Ie: C:\DEV\OSG_SVN\OpenSceneGraph\bin and C:\DEV\OSG_SVN\OpenSceneGraph\lib. DLLs and EXEs land in: C:\DEV\OSG_SVN\OpenSceneGraph\bin Libraries land in: C:\DEV\OSG_SVN\OpenSceneGraph\lib Headers remain in (Cmake is clever and does not copy them over themselves): C:\DEV\OSG_SVN\OpenSceneGraph\include 3. My system PATH variable inludes C:\DEV\OSG_SVN\OpenSceneGraph\bin directory 4. With VisualStudio I load Cmake generated sln and run BUILD ALL and then BUILD INSTALL to copy binaries to above directories. I do it twice - once for Release and
Re: [osg-users] osg with c# winforms and simpleopenglcontrol Tao framework
Hi Peter, I know nothing of c# or Toa, but the one question I can answer is that the values in setUpViewerAsEmbeddedInWindow(x,y,width,hieght) are for the glViewport dimensions within the window that your application creates. Robert On 9/27/07, Peter DeSantis [EMAIL PROTECTED] wrote: Hello Im new to OSG but have produced some opengl applications previously, some simple 3ds model loading applications using opengl for viewing in stereoscopic and multiwall VR settings. So im trying to get to grips with using c# with winforms and OSG, using the dotnet wrappers available. In additon to that im using the Tao Framework, that comes with simpleopenglcontrol, that allows a opengl panel to be dropped onto a winforms. I am wanting to use OSG with this opengl control on winforms, and the closest example of how to do this seems to be the GLUT sample code, in the examples section, using the setUpViewerAsEmbeddedInWindow(x,y,width,hieght) option. Do the paramters here just correspond to the glViewport paramters or do they specify the pixel location on screen of the window ? Can anyone confirm this would be the only way to use the simpleopenglcontrol from the tao framework ? Are there any other options. I thought perhaps passing the window hwd or the graphics context of the simpleopenglcontrol to the OSG viewer might be an option or not ? Perhaps i could pass the hwd of the winforms panel and use the option to create a win32 window in osg. I thought about pass the hwd to producer but it seems to still be in alpha stage and perhaps underdeveloped to use with osg in its current form If anyone could clarify these points or provide any other/or best examples of using osg with the tao framework simpleopengl control it would be appreciated. Thanks Peter DeSantis [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] MODKEY_CTRL problem
On 9/27/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi! After searching a little more, I see that after pressing Left Alt-Tab, default window manager shortcut to change applications, calls to getModKeyMask() will always return 256. You can see it in the osgkeyboard example, after pressing Alt-Tab alt is always pressed! There is a chance that is this is a window manager bug... What OS/Window manager are you using? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MODKEY_CTRL problem
Hi Robert. Linux/KDE. Panagiotis Papadakos On Thu, 27 Sep 2007, Robert Osfield wrote: On 9/27/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi! After searching a little more, I see that after pressing Left Alt-Tab, default window manager shortcut to change applications, calls to getModKeyMask() will always return 256. You can see it in the osgkeyboard example, after pressing Alt-Tab alt is always pressed! There is a chance that is this is a window manager bug... What OS/Window manager are you using? ___ 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] Is it possible to get a fixed constant framerate in OSG?
Hi all!, Does anyone know if it's possible to controll the application framerate in any way ? We have now V-sync on and if for example we have a refresh frequency of 72Hz and the framerate is during all the execution of the application over 40fps we'd like to now if there's any function in OSG 2.0 so that we can fix the framerate constant to 36fps (for example). Thanks a lot, Carlos. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Redistribute OSG on Vista
Hi Serge, i don't know what's exactly going wrong with this. but one problem is that you don't have the redist installed. the latest version of VS 2005 force per default the manifest file building and the CRT lib. there should be 2 solutions to solve this, i am not sure and i did test it, but i rember that i did once similar: try to: (1) remove manifest build (2) try to et crt lib settings in the project if you test it on a system VS 2005 installed, everythings works nice. otherwise i doesnt. so try to test also under xp (without installed VS 2005) /if you still have problems, let me know, then may i can have then a deep look into the issue 2007/9/27, Serge Lages [EMAIL PROTECTED]: Hi all, Here is my problem : I develop with WinXP and VS8 SP1, and I have an OSG application I need to redistribute on Win2K, WinXP and Vista. The important thing to note is that the users will not have administration rights on their computers when installing my application. That's why I can't install Microsoft's vcredist_x86.exe on these computers. So to make it work, I followed the instructions here (the second method) : http://msdn2.microsoft.com/library/ms235291(VS.80).aspxhttp://msdn2.microsoft.com/library/ms235291%28VS.80%29.aspx I have put Microsoft.VC80.CRT folders with the correct dlls and manifest everywhere I have a dll (into the main binary folder and into the osgPlugins-* folder). Under WinXP and Win2K it works great but not on Vista. It makes my application crash. Its weird because if I don't put a Microsoft.VC80.CRTfolder into the plugins folder, my application doesn't crash (but no textures or objects are loaded as the plugins fail to be loaded). So it seems to come from the plugins. Anyone as a clue on what I am doing wrong ? Thanks in advance for any help. PS : Of course, if I install vcredist_x86.exe on the Vista computer, my application works normally, so it's really a redistribution issue. -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MODKEY_CTRL problem
On 9/27/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi Robert. Linux/KDE. OK. I've reproduce the problem in osgkeyboard, it looks like the alt tab is prevent GraphicsWindowX11 from getting any events, and if it isn't getting any events then there is no way for it to know that anything has changed. Pressing 'alt' on its own in the osgkeyboard window fixes the problem. As to a solution? I don't know. One might need to dynamically query the modifier state rather than relying on events. This would require substantial changes though, and is not something I have time to go chasing after right now. Others are welcome to investigate. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it possible to get a fixed constant framerate in OSG?
Hi Carlos, There is no function in the OSG for setting the target frame rate. You own application has control over the dispatch of viewer.frame() (unless you call viewer.run()) so you can decide yourself if your app is ready to commence the next frame. Robert. On 9/27/07, Carlos Zoido [EMAIL PROTECTED] wrote: Hi all!, Does anyone know if it's possible to controll the application framerate in any way ? We have now V-sync on and if for example we have a refresh frequency of 72Hz and the framerate is during all the execution of the application over 40fps we'd like to now if there's any function in OSG 2.0 so that we can fix the framerate constant to 36fps (for example). Thanks a lot, Carlos. ___ 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] applying textures
Thanks for your interest on my problem David, i looked at your link but it
seems too low level... how can i say? i'm only trying to apply a texture to
a model node (thanks to osg scenegraph approach): if i use texgen with
spere_map flag, the texture is applied to my node, but it moves when i move
the camera. if i use eye_linear or object_linear the texture gets black. if
i don't use texgen the node change only its color (assuming the main color
of the texture).
I really need some help!!
Enrico
2007/9/25, David Callu [EMAIL PROTECTED]:
Hi Enrico
For a good explanation of texture mapping and texcoord generator, take
a look the
redbookhttp://fly.cc.fer.hr/%7Eunreal/theredbook/chapter09.htmland to the
OpenGL Specification, Chap
2.11.4 , p 50. Keep in mind that osg is a c++ wrapper of OpenGL (and
little more of course :-)), and all graphic concep t come from OpenGL. as
the texcoord generator.
HTH
david
2007/9/25, Enrico Villani [EMAIL PROTECTED]:
Hi to all!
i'm a newbie of osg and i would share my problem with the
community...
i'm developing a VR application which should load various kind of 3D
models (mainly flt and osg/ive), insert them into an appropriate
environement and allow to modify all the scenegraph at runtime. in fact it
shows the scenegraph and the user can decide to change positions of nodes,
their visibility, etc. When the user chooses to modify the texture of these
models, he searches the disk for a good looking image (bmp, jpg, etc), but
the texture is not mapped correctly (the node selected by the user changes
only its color, texture too big ). otherwise when he applies these
textures onto the environement sphere or the terrain, all look more or less
correct. I use an extended nodevisitor to traverse the scenegraph from the
node choosed by the user in search of geodes. Every time the visitor finds a
geode it does:
int Num = geode.getNumDrawables();
for(int j = 0; j Num; j++) {
osg::StateSet* stateset = geode.getDrawable
(j)-getOrCreateStateSet();
osg::Texture2D* myTexture=new osg::Texture2D;
myTexture-setDataVariance(osg::Object::DYNAMIC);
myTexture-setImage(myImage);
stateset-setTextureAttributeAndModes(0, myTexture,
osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
geode.getDrawable(j)-setStateSet(stateset);
}
I'm in trouble understanding texture mapping. I looked at BumpMapping to
get useful hints about texcoordgenerator... but i don't know how to use it.
Having multiple geometries, how to map them correctly or even
approssimatively?
Can anyone help me??
Sorry for my maybe silly question but I'm new to to the computer
graphics world!
I'd be very grateful..
Many thanks in advance..
Enrico
___
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] ClipNode / clipplane, rendering water with RTT camera
Hello, could anyone give me a hint on my problem described below? I cannot figure out how to setup a clipplane for the reflection camera correctly. thanks, Michael. Michael Ebner wrote: Hello OSG users, i'm trying to render a water surface with reflections. Rendering the reflected scene into a texture and projecting it on a water plane already works. What i need is a clipplane at water height to avoid rendering anything below the water surface. I've tried to setup a ClipNode with clipplanes in various ways (also activating them on different positions at the scenegraph) but nothing gets clipped. I post a code snippet below, perhaps i'm missing something obvious. I tried, setting up the ClipNode at root level and activating the plane at reflection cameras level. Tried adding the ClipNode above the reflection camera and activating it there. And below is the code, where the ClipNode is child of the RTT reflection_camera, but it doesn't work either. snippet: // reflection texture reflection_tex_ = new osg::Texture2D; reflection_tex_-setTextureSize(1024,1024); reflection_tex_-setInternalFormat(GL_RGBA); reflection_tex_-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR); reflection_tex_-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR); reflection_tex_-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER); reflection_tex_-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER); reflection_tex_-setBorderColor(osg::Vec4(1.0f,1.0f,1.0f,1.0f)); // reflection camera -- reflection_camera_ = new osg::Camera; reflection_camera_-setName(WaterReflectionCamera); reflection_camera_-setClearColor(osg::Vec4(0.1f,0.1f,0.3f,1.0f)); reflection_camera_-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); reflection_camera_-setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR); reflection_camera_-setReferenceFrame(osg::Camera::ABSOLUTE_RF); reflection_camera_-setViewport(0, 0, reflection_tex_-getTextureWidth(), reflection_tex_-getTextureHeight()); reflection_camera_-setRenderOrder(osg::Camera::PRE_RENDER); reflection_camera_-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); reflection_camera_-attach(osg::Camera::COLOR_BUFFER, reflection_tex_.get()); // add clip node with clip plane, to avoid rendering anything below water surface osg::ClipNode * clip_node = new osg::ClipNode(); clip_node-setName(Clip Node XZ plane); clip_node-addClipPlane(new osg::ClipPlane(0,0.0,1.0,0.0,water_height)); osg::StateSet* clip_state = clip_node-getOrCreateStateSet(); clip_state-setMode(GL_CLIP_PLANE0, osg::StateAttribute::PROTECTED | osg::StateAttribute::ON); clip_node-addChild(reflected_nodes.get()); reflection_camera_-addChild(clip_node); root_node-addChild(reflection_camera_.get()); //--- Thanks in advance for any help, Michael. ___ 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] more on Windows debugging
Yes, I've tried that. But VS is definitely finding the pdb files and loading symbols. It just isn't finding the source. thanks, andy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thibault Genessay Sent: Thursday, September 27, 2007 5:01 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Hi guys Just my 2 cents: have you tried to put the pdb files along with the DLLs ? My post-build step copies all the DLLs and the PDBs and stores them in the same folder (say 'c:\libs\bin' - must be in %PATH%), and I've never experienced any problems, except when a PDB does not match a DLL - which is expected. This technique works with all the libraries I've been working with so far, not only the OSG. The only drawback is that PDBs are huge files and make the post-build step a bit slow. Thibault On 9/26/07, Andy Skinner [EMAIL PROTECTED] wrote: Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from my app dir I was still able to step into OSG sources. Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for OpenThreadsd.pdb string. There is only one line containing this string and this line contains full absolute path to the place where OpenThreadsd.pdb was built. In my case this is C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB in hexeditor. PDB seems to keep all the absolute paths to the source cpp files. My PDB still resides in this directory where DLL points (ie where DLL was linked) and my source OSG cpp files are still at the same directory where PDB points (ie where they were compiled). DLL may be moved wherever I want and VS is still able to find the sources. I guess VS first loads DLL, reads the PDB absolute path, then loads PDB and finds absolute paths to sources. I suppose VS may have trouble if PDB or cpp files absolute paths change. But it looks that DLL can be moved freely. PS. I use VS 2005 SP1 maybe it matters. Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Behalf Of Andy Skinner Sent: Wednesday, September 26, 2007 7:26 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks. I have some of the same setup, but I don't get OSG from the place where I built it. I'm afraid that moving the dlls has lost their connection with the source. I've got paths set to specify the source, but it doesn't seem to be helping, in the same way it didn't help you to remove them. :) thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 11:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Below is my OSG configuration. Apparently it works well with Visual Studio 2005 Express intellibase as I am able to step down into OSG sources from my OSG based projects. This may be no solution for you but I hope it may be helpful somehow if you will be able to find differences and maybe finally isolate the cause of the problems. 1. I keep all my projects in C:\DEV directory. All OSG svn related projects are kept in C:\DEV\OSG_SVN\ directory. And OpenSceneGraph distribution is located in C:\DEV\OSG_SVN\OpenSceneGraph. 2. After OpenScenGraph SVN update I run CMake and change OSG INSTALL directory variable to '.' (dot - current directory). It has the effect that install will make bin and lib subdirectories in OpenSceneGraph root directory. Ie: C:\DEV\OSG_SVN\OpenSceneGraph\bin and C:\DEV\OSG_SVN\OpenSceneGraph\lib. DLLs and EXEs land in: C:\DEV\OSG_SVN\OpenSceneGraph\bin Libraries land in: C:\DEV\OSG_SVN\OpenSceneGraph\lib Headers remain in (Cmake is clever and
Re: [osg-users] Transparency problem
Hi Andreas. Well I have already tried to change the stateset of the geode of the osgText for example with something like stateSetGeode-setRenderBinDetails(15, RenderBin, osg::StateSet::OVERRIDE_RENDERBIN_DETAILS) , but it doesn't seem to help. The bigger the renderbin the later it is rendered in the scene, right? Panagiotis Papadakos On Thu, 27 Sep 2007, [EMAIL PROTECTED] wrote: Hello everybody. I have a transparency problem which you can see in the attached image. As you can see the strings rendered on the orange window, which is in front of another blue window, have a blue outline from the blue window behind. The strings are in front of a semi-transparent rectangle in front of the semi-transparent window. What might be happening? Hi! I had the same problem with billboards and I fixed it with setting the stateset's RenderBinNumber. RenderBins in OSG is used to specify which objects are going to be drawn first. -- Andreas Richter ___ 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] ParallelSplitShadowMap ....
Thanks Adrian, Changes now merged and submitted to SVN. Visual quality is better with the suggested options in the README but still not great, in particular I loose shadows when near to objects and at shallow angles to the surfaces under shadow. I've played around with the polygonoffset and found that changing units makes no difference for the models/views I've tested, but factor to to 4 or 5 seems sufficient to avoid the z fighting. The values you've chosen for NVidia look excessive. I am beginning to wonder about the value of using PolygonOffset in this context, its just not reliable enough across hardware. Alternatives to using PolygonOffset are tweaking the depth range via osg::Depth or via a small tweak to the projection matrix. Replacing osg::PolygonOffset by osg::Depth might well be a useful thing to try. Robert. On 9/26/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi Robert, please update the PSSM, i did some bug fixes and added new features to move the camera virtual against the view direction by applaying a simple distance factor (a), which is calculated camera eye - camera center distance. and we can move the light camera against the light direction (b). (a) some objects behind the camera can cast shadow (b) object aboive the camera can cast shadow then i fixed the shadow map orientation, now screen x coordinate alinged which improve the quality /adegli -- Adrian Egli ___ 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] Realize callback in 2.x?
I'm porting an app from 1.2 to 2.x, and it is not immediately obvious to me how to implement a callback I was setting with Producer::RenderSurface::addRealizeCallback. (The callback toggles VSYNC via the WGL_EXT_swap_control extension.) What is the preferred method for doing this under osgViewer? Thank you! -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Realize callback in 2.x?
Hi Glenn, You can pass do the equivalent of realize callback by setting the RealizerOperation on the Viewer. See the osgshaderterrain example. Robert. On 9/27/07, Glenn Waldron [EMAIL PROTECTED] wrote: I'm porting an app from 1.2 to 2.x, and it is not immediately obvious to me how to implement a callback I was setting with Producer::RenderSurface::addRealizeCallback. (The callback toggles VSYNC via the WGL_EXT_swap_control extension.) What is the preferred method for doing this under osgViewer? Thank you! -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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] more on Windows debugging
Thanks to Wojtek, I think I'm getting somewhere. When he looked at strings in his pdb files, he saw paths to source code, and I didn't. But I was pretty sure I was generating things with flags, because I was creating pdb files and the debugger was finding symbols. Well, apparently something was creating pdb files, but not with enough info. I added some of the flags that I thought had to be there anyway to generate the files in the first place, and I'm seeing the source file paths in the pdb files. I'm still building, but I should be able to test soon. I'm not sure what options built debug and made pdb files and symbols but didn't put the source paths in the pdb files, but I think I'll be able to resolve this now. andy -Original Message- From: Wojciech Lewandowski [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 4:35 AM To: Andy Skinner; OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? Yes. PDB is a huge container of various information. It contains both relative paths (prefixed with ./) and absolute paths of my source files. Also contains whole commands used to compile and link. I googled PDB a little. Found few interesting links but nothing realy spectacular. Some information on microsoft site says that copying .pdb files to working directory may help: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 : The new Visual C++ debugger uses the project.PDB file created by the linker directly, and embeds the absolute path to the .PDB in the .EXE or .DLL file. If the debugger can't find the .PDB file at that location or if the path is invalid (if, for example, the project was moved to another computer), the debugger looks for it in the current directory. If you are desperate you may try to grab DIA sdk and build dia2dump example and see what exactly your PDB contains. http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx Hope it helps, Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, September 26, 2007 10:34 PM Subject: RE: [osg-users] more on Windows debugging Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from my app dir I was still able to step into OSG sources. Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for OpenThreadsd.pdb string. There is only one line containing this string and this line contains full absolute path to the place where OpenThreadsd.pdb was built. In my case this is C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB in hexeditor. PDB seems to keep all the absolute paths to the source cpp files. My PDB still resides in this directory where DLL points (ie where DLL was linked) and my source OSG cpp files are still at the same directory where PDB points (ie where they were compiled). DLL may be moved wherever I want and VS is still able to find the sources. I guess VS first loads DLL, reads the PDB absolute path, then loads PDB and finds absolute paths to sources. I suppose VS may have trouble if PDB or cpp files absolute paths change. But it looks that DLL can be moved freely. PS. I use VS 2005 SP1 maybe it matters. Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Skinner Sent: Wednesday, September 26, 2007 7:26 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks. I have some of the same setup, but I don't get OSG from the place where I built it. I'm afraid that moving the dlls has lost their connection with the source. I've got paths set
Re: [osg-users] more on Windows debugging
It works, and I'm debugging. Thanks so much. We've got several OSG developers here, and this will be very helpful. I've asked how come this flag isn't included for our 3rd party builds, and I'm curious why we got pdb files and symbols without it. That's why I was confused for a long time. But I'm going now, anyway. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Thursday, September 27, 2007 10:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks to Wojtek, I think I'm getting somewhere. When he looked at strings in his pdb files, he saw paths to source code, and I didn't. But I was pretty sure I was generating things with flags, because I was creating pdb files and the debugger was finding symbols. Well, apparently something was creating pdb files, but not with enough info. I added some of the flags that I thought had to be there anyway to generate the files in the first place, and I'm seeing the source file paths in the pdb files. I'm still building, but I should be able to test soon. I'm not sure what options built debug and made pdb files and symbols but didn't put the source paths in the pdb files, but I think I'll be able to resolve this now. andy -Original Message- From: Wojciech Lewandowski [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 4:35 AM To: Andy Skinner; OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? Yes. PDB is a huge container of various information. It contains both relative paths (prefixed with ./) and absolute paths of my source files. Also contains whole commands used to compile and link. I googled PDB a little. Found few interesting links but nothing realy spectacular. Some information on microsoft site says that copying .pdb files to working directory may help: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 : The new Visual C++ debugger uses the project.PDB file created by the linker directly, and embeds the absolute path to the .PDB in the .EXE or .DLL file. If the debugger can't find the .PDB file at that location or if the path is invalid (if, for example, the project was moved to another computer), the debugger looks for it in the current directory. If you are desperate you may try to grab DIA sdk and build dia2dump example and see what exactly your PDB contains. http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx Hope it helps, Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, September 26, 2007 10:34 PM Subject: RE: [osg-users] more on Windows debugging Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from my app dir I was still able to step into OSG sources. Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for OpenThreadsd.pdb string. There is only one line containing this string and this line contains full absolute path to the place where OpenThreadsd.pdb was built. In my case this is C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB in hexeditor. PDB seems to keep all the absolute paths to the source cpp files. My PDB still resides in this directory where DLL points (ie where DLL was linked) and my source OSG cpp files are still at the same directory where PDB points (ie where they were compiled). DLL may be moved wherever I want and VS is still able to find the sources. I guess VS first loads DLL, reads the PDB absolute path, then loads PDB and finds absolute paths to sources. I suppose VS may have
Re: [osg-users] more on Windows debugging
I am glad to hear that. Out of curiosity which option was missing ? Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, September 27, 2007 5:10 PM Subject: Re: [osg-users] more on Windows debugging It works, and I'm debugging. Thanks so much. We've got several OSG developers here, and this will be very helpful. I've asked how come this flag isn't included for our 3rd party builds, and I'm curious why we got pdb files and symbols without it. That's why I was confused for a long time. But I'm going now, anyway. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Thursday, September 27, 2007 10:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks to Wojtek, I think I'm getting somewhere. When he looked at strings in his pdb files, he saw paths to source code, and I didn't. But I was pretty sure I was generating things with flags, because I was creating pdb files and the debugger was finding symbols. Well, apparently something was creating pdb files, but not with enough info. I added some of the flags that I thought had to be there anyway to generate the files in the first place, and I'm seeing the source file paths in the pdb files. I'm still building, but I should be able to test soon. I'm not sure what options built debug and made pdb files and symbols but didn't put the source paths in the pdb files, but I think I'll be able to resolve this now. andy -Original Message- From: Wojciech Lewandowski [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 4:35 AM To: Andy Skinner; OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? Yes. PDB is a huge container of various information. It contains both relative paths (prefixed with ./) and absolute paths of my source files. Also contains whole commands used to compile and link. I googled PDB a little. Found few interesting links but nothing realy spectacular. Some information on microsoft site says that copying .pdb files to working directory may help: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 : The new Visual C++ debugger uses the project.PDB file created by the linker directly, and embeds the absolute path to the .PDB in the .EXE or .DLL file. If the debugger can't find the .PDB file at that location or if the path is invalid (if, for example, the project was moved to another computer), the debugger looks for it in the current directory. If you are desperate you may try to grab DIA sdk and build dia2dump example and see what exactly your PDB contains. http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx Hope it helps, Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, September 26, 2007 10:34 PM Subject: RE: [osg-users] more on Windows debugging Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from my app dir I was still able to step into OSG sources. Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for OpenThreadsd.pdb string. There is only one line containing this string and this line contains full absolute path to the place where OpenThreadsd.pdb was built. In my case this is C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB in hexeditor. PDB seems to keep all the
Re: [osg-users] more on Windows debugging
It was /Zi. I knew I saw it set (it was put in another variable and not put in the one I was using), and I knew I was getting pdb files, so I really thought it was being applied. Oh, well. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Thursday, September 27, 2007 11:19 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging I am glad to hear that. Out of curiosity which option was missing ? Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, September 27, 2007 5:10 PM Subject: Re: [osg-users] more on Windows debugging It works, and I'm debugging. Thanks so much. We've got several OSG developers here, and this will be very helpful. I've asked how come this flag isn't included for our 3rd party builds, and I'm curious why we got pdb files and symbols without it. That's why I was confused for a long time. But I'm going now, anyway. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Thursday, September 27, 2007 10:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Thanks to Wojtek, I think I'm getting somewhere. When he looked at strings in his pdb files, he saw paths to source code, and I didn't. But I was pretty sure I was generating things with flags, because I was creating pdb files and the debugger was finding symbols. Well, apparently something was creating pdb files, but not with enough info. I added some of the flags that I thought had to be there anyway to generate the files in the first place, and I'm seeing the source file paths in the pdb files. I'm still building, but I should be able to test soon. I'm not sure what options built debug and made pdb files and symbols but didn't put the source paths in the pdb files, but I think I'll be able to resolve this now. andy -Original Message- From: Wojciech Lewandowski [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 4:35 AM To: Andy Skinner; OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? Yes. PDB is a huge container of various information. It contains both relative paths (prefixed with ./) and absolute paths of my source files. Also contains whole commands used to compile and link. I googled PDB a little. Found few interesting links but nothing realy spectacular. Some information on microsoft site says that copying .pdb files to working directory may help: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 : The new Visual C++ debugger uses the project.PDB file created by the linker directly, and embeds the absolute path to the .PDB in the .EXE or .DLL file. If the debugger can't find the .PDB file at that location or if the path is invalid (if, for example, the project was moved to another computer), the debugger looks for it in the current directory. If you are desperate you may try to grab DIA sdk and build dia2dump example and see what exactly your PDB contains. http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx Hope it helps, Wojtek - Original Message - From: Andy Skinner [EMAIL PROTECTED] To: [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, September 26, 2007 10:34 PM Subject: RE: [osg-users] more on Windows debugging Thanks. I have been looking at strings in these files, too. I did not see the path to the cpp files listed in the pdb file. I see paths to .obj files, a something.dll.embed.manifest.res file, some source files (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a volume f) but no OSG source files. There are some .exp files. Do you actually have the OSG (or in this case OpenThreads) source path names, up to the .cpp extension in your pdb file? In the meantime, I have been trying to debug just looking at stack traces. I should see how far I can get using linux, too, although I'm not fond of gdb. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: Wednesday, September 26, 2007 4:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] more on Windows debugging My INSTALL step does copy these DLLs to the different location. They were compiled in OpenSceneGraph\src\subproject and linked in OpenSceneGraph\lib\release or debug directories and INSTALL places them in OpenSceneGraph\bin directory. Technically its almost the same situation as yours. I did an extra test and moved DLLs to my sample project directory. Even if they were loaded from
Re: [osg-users] Suitable for Pointcloud/LIDAR data
Hi Martin, The OSG can certainly be used for point data, 100M points will starting hitting memory size and bandwidth issues down on the graphics card. The OSG does support paging and VBO's which can certainly help, the scene graphs will still have to be very carefully management to get good throughout - you will still have to understand how the graphics cards/OpenGL works to make the best use of it - there isn't anything magical the OSG can do, it can just help. Robert. On 9/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I need to develop an application to handle a 3D point-cloud of a few 100M points. It will have to handle displaying points, meshes and surfaces quickly. Currently my app uses raw opengl but I need a more efficent solution for large data sets. Is openscenegraph suitable for this? I am conceend that the file format isn't very compact - do I have to use this format or can I simply load my data and create a model 'on the fly'? How does it manage data sets too large to fit in memory? Will osg manage selecting points/regions efficently with such large data sets? Any pointers to the suitability greatly apprreciated Thanks, Martin ___ 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] Redistribute OSG on Vista
Does your app need MFC? The redist installs assemblies for that as well. Do the versions in the manifest file match the ones in the dlls and the ones in the manifests embedded in the exe and plugin dlls? I found this thread useful http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465 http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465SiteID=1 SiteID=1 osg loads its plugins via loadlibrary (as opposed to implicit loading via the exe loader) which is why you need private assemblies in the plugin directory as well. Only ms could dream up something this Byzantine! I found the ms dependency walker (http://www.dependencywalker.com http://www.dependencywalker.com/ ) and the CFF Explorer (http://www.ntcore.com/products.php) useful in tracking this stuff down. Roger _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: 27 September 2007 11:04 To: OpenSceneGraph Users Subject: Re: [osg-users] Redistribute OSG on Vista On 9/27/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi Serge, i don't know what's exactly going wrong with this. but one problem is that you don't have the redist installed. the latest version of VS 2005 force per default the manifest file building and the CRT lib. there should be 2 solutions to solve this, i am not sure and i did test it, but i rember that i did once similar: try to: (1) remove manifest build (2) try to et crt lib settings in the project if you test it on a system VS 2005 installed, everythings works nice. otherwise i doesnt. so try to test also under xp (without installed VS 2005) My current solution (including Microsoft.VC80.CRT folders) works with a fresh WinXP install (without VS8 nor redist package installed). But it doesn't work on a fresh Vista install, that is why I am so disappointed. :/ Anyone have manage to redistribute an OSG app on a Windows Vista without having to install the redistributable package ? -- Serge Lages http://www.magrathea-engine.org http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Redistribute OSG on Vista
Thanks for that thread pointer, useful info there. I found the It's that simple. comment mildly humorous. -- mew Mike Weiblen -- Zebra Imaging -- Austin Texas USA -- http://www.zebraimaging.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Roger James Sent: Thursday, September 27, 2007 11:55 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Redistribute OSG on Vista Does your app need MFC? The redist installs assemblies for that as well. Do the versions in the manifest file match the ones in the dlls and the ones in the manifests embedded in the exe and plugin dlls? I found this thread useful http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465SiteID=1 osg loads its plugins via loadlibrary (as opposed to implicit loading via the exe loader) which is why you need private assemblies in the plugin directory as well. Only ms could dream up something this Byzantine! I found the ms dependency walker (http://www.dependencywalker.com http://www.dependencywalker.com/ ) and the CFF Explorer (http://www.ntcore.com/products.php) useful in tracking this stuff down. Roger From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Serge Lages Sent: 27 September 2007 11:04 To: OpenSceneGraph Users Subject: Re: [osg-users] Redistribute OSG on Vista On 9/27/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi Serge, i don't know what's exactly going wrong with this. but one problem is that you don't have the redist installed. the latest version of VS 2005 force per default the manifest file building and the CRT lib. there should be 2 solutions to solve this, i am not sure and i did test it, but i rember that i did once similar: try to: (1) remove manifest build (2) try to et crt lib settings in the project if you test it on a system VS 2005 installed, everythings works nice. otherwise i doesnt. so try to test also under xp (without installed VS 2005) My current solution (including Microsoft.VC80.CRT folders) works with a fresh WinXP install (without VS8 nor redist package installed). But it doesn't work on a fresh Vista install, that is why I am so disappointed. :/ Anyone have manage to redistribute an OSG app on a Windows Vista without having to install the redistributable package ? -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Redistribute OSG on Vista
Something I forgot. I have seen mention that having the private assembly in a sub-directory doesn't work when loading dlls. I have never tried it. Maybe someone who understands this maze can comment. So just copy the runtime dlls and their manifest up into the plugin directory. Roger _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger James Sent: 27 September 2007 17:55 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Redistribute OSG on Vista Does your app need MFC? The redist installs assemblies for that as well. Do the versions in the manifest file match the ones in the dlls and the ones in the manifests embedded in the exe and plugin dlls? I found this thread useful http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465 http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465SiteID=1 SiteID=1 osg loads its plugins via loadlibrary (as opposed to implicit loading via the exe loader) which is why you need private assemblies in the plugin directory as well. Only ms could dream up something this Byzantine! I found the ms dependency walker (http://www.dependencywalker.com http://www.dependencywalker.com/ ) and the CFF Explorer (http://www.ntcore.com/products.php) useful in tracking this stuff down. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] more on Windows debugging
Oh, we're building the OSG with an enormous pile of scaffolding. There is a process for building all our 3rd party software. I still haven't heard why they don't include /Zi for 3rd party stuff, or why I was getting pdb file at all (even if not containing everything) without it. I'd love to know how to get the paths in the pdb file to be UNC paths, rather than the volume number. My sandbox is my S: volume, but if I'd like to keep the build area in my sandbox and let other people use it, I'd like to use the UNC name (\\mathworks\devel\sandbox\askinner). I don't know if there is a way to get that name into the file instead of S: or not. Until I figure that out, they'll have to copy my build area (with src directory and pdb files) as well as my install (with include, bin, and lib). I'd like for them to just have to get the install. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Thursday, September 27, 2007 2:32 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] more on Windows debugging Hello Andy, Glad you got this sorted, it was bugging me too. Not your messages :-), but the fact you got the problem when I have had no problem debugging inside the OSG DLLs -- of course stating I have no problem doesn't help at all, which is why I didn't say anything. It was /Zi. I knew I saw it set (it was put in another variable and not put in the one I was using), and I knew I was getting pdb files, so I really thought it was being applied. Oh, well. I wonder, how were you building the OSG? On my side, when I generate the build files with CMake, using the build configuration list in Visual Studio to switch from Release to Debug sets the correct flags (including /Zi)... Were you building the OSG with a different build tool or from your own scripts? I'm just wondering, because if not, that would indicate that in some circumstances CMake will generate invalid build files (without /Zi for the debug build, at least), and I'd like to get to the bottom of that so others don't get that problem in the future... OTOH, if the problem was totally on your side, then I'm just glad you got it fixed. I remember a few threads I started that lasted a few days/weeks and where the problem was ultimately totally on my side, so I can relate. :-) J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ 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] MODKEY_CTRL problem
On 9/27/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/27/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi Robert. Linux/KDE. OK. I've reproduce the problem in osgkeyboard, it looks like the alt tab is prevent GraphicsWindowX11 from getting any events, and if it isn't getting any events then there is no way for it to know that anything has changed. Pressing 'alt' on its own in the osgkeyboard window fixes the problem. As to a solution? I don't know. One might need to dynamically query the modifier state rather than relying on events. This would require substantial changes though, and is not something I have time to go chasing after right now. Others are welcome to investigate. Robert. Since I've been trying to learn more Xlib, I took a look at this and it seems that OSG is using KeyPress/Release events on the modifier keys themselves to set the GUIEventAdapter modifier mask rather than using the modifier state contained in the X key, button, motion and border crossing events (the 'state' member of those events). I used xev to trace the events, and I think what happens is: Alt is pressed, the EventQueue's modifier state is set, and then the window loses keyboard focus when the window manager sees Alt-Tab. If the Alt key is released while switched away (or the user Alt-Tabs back to the OSG window), the window never gets a KeyRelease event for Alt because the event happens while it has lost keyboard focus. The Alt state in the EventQueue is then stuck on until it is pressed and released again. One solution would be to ignore KeyPress/Release events for modifier keys and use the modifier state masks in the other keyboard and pointer events. This also honors the current modifier mapping (MappingNotify would also need to be handled) as reported by xmodmap. Howver, another option is to select for KeymapNotify events to get the current modifier state when the keyboard/pointer focus comes back (KeymapNotify follows EnterNotify and FocusIn events). The KeymapNotify event includes state for all keys (a 256 bit vector indexed by keycode). EnterNotify also includes the modifier state in the event, but FocusIn does not. Leif Delgass ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MODKEY_CTRL problem
Hi Leif Robert, This is the same problem that was reported this summer on the Win32 platform. A fix for it was prepared and submitted, but it required equivalent changes on the X11 and OSX graphics windows class implementations since changes to the core OSG libraries were made. It would be great if somebody could volunteer on the X11 and OSX sides to make these. André -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leif Delgass Sent: September-27-07 5:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MODKEY_CTRL problem On 9/27/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/27/07, Panagiotis Papadakos [EMAIL PROTECTED] wrote: Hi Robert. Linux/KDE. OK. I've reproduce the problem in osgkeyboard, it looks like the alt tab is prevent GraphicsWindowX11 from getting any events, and if it isn't getting any events then there is no way for it to know that anything has changed. Pressing 'alt' on its own in the osgkeyboard window fixes the problem. As to a solution? I don't know. One might need to dynamically query the modifier state rather than relying on events. This would require substantial changes though, and is not something I have time to go chasing after right now. Others are welcome to investigate. Robert. Since I've been trying to learn more Xlib, I took a look at this and it seems that OSG is using KeyPress/Release events on the modifier keys themselves to set the GUIEventAdapter modifier mask rather than using the modifier state contained in the X key, button, motion and border crossing events (the 'state' member of those events). I used xev to trace the events, and I think what happens is: Alt is pressed, the EventQueue's modifier state is set, and then the window loses keyboard focus when the window manager sees Alt-Tab. If the Alt key is released while switched away (or the user Alt-Tabs back to the OSG window), the window never gets a KeyRelease event for Alt because the event happens while it has lost keyboard focus. The Alt state in the EventQueue is then stuck on until it is pressed and released again. One solution would be to ignore KeyPress/Release events for modifier keys and use the modifier state masks in the other keyboard and pointer events. This also honors the current modifier mapping (MappingNotify would also need to be handled) as reported by xmodmap. Howver, another option is to select for KeymapNotify events to get the current modifier state when the keyboard/pointer focus comes back (KeymapNotify follows EnterNotify and FocusIn events). The KeymapNotify event includes state for all keys (a 256 bit vector indexed by keycode). EnterNotify also includes the modifier state in the event, but FocusIn does not. Leif Delgass ___ 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] Please test SVN version of OpenSceneGraph
Robert Osfield wrote:
The errors don't make any sense to me, the line is:
inline float log2(float v) { return logf(v) * static_castfloat(INVLN_2);
}
And the error you get is:
/usr/src/OpenSceneGraph/include/osg/Math:197: error: expected `)'
before '/' token
/usr/src/OpenSceneGraph/include/osg/Math:197: error: expected `,' or
`;' before '/' token
It's like the compiler is treating the definition of INVLN_2 as a
macro not a const double. The definition of INVLN_2 is near the top
of include/osg/Math :
const double LN_2 = 0.69314718055994530942;
const double INVLN_2 = 1.0 / LN_2;
This really looks like a bug in the compiler. Perhaps changing the
above be a hardwired value i.e. const double INVLN_2 = 1.442... might
get around this bug, could you try this?
Robert.
I tried the change you suggested but no go. I think it might be deeper in
/usr/include/math.h where they do a define on log2 and log2f as follows
but
#define log2(x) (log(x) / M_LOG2_E)
#define log2f(x) (logf(x) / (float) M_LOG2_E)
not sure.
bk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.1.10 windows refresh / performance
Thanks André I'll try it out. G On Fri, 28 Sep 2007 08:39:21 +1200, [EMAIL PROTECTED] wrote: Hi Gert, FYI, I've just submitted a fix for the taskbar not being repainted when a full-screen graphics window is going to windowed mode. André -- Gert van Maren Head of Research Development K2Vi Virtual Reality Software Data Interface Technologies Ltd Phone: +64 21 2855581 Email: [EMAIL PROTECTED] Web: http://www.k2vi.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
