Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??
Hi, Sorry to resurrect an old thread, but I am running into a very similar problem: 3file INSTALL cannot find 3 C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/../../bin/ot11-OpenThreads.dll. The OP said that they could find this DLL (and others) in the specific directory. It seems that the OP's problem was that VS didn't have the right permissions to access the destination directory. My problem is a bit different. I'm running VS2010 as Administrator, but it still doesn't work. When I look at the above folder path, all it has are PDBs. In my case, that is not the correct path. The correct path is: C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/ All of my DLLs, etc., are in that path. They are not in the folder that the cmake install step is looking in. I don't know how to get them to build into the path that the cmake install step is looking for them in (aside from manually editing each project file by hand). Does anyone have any advice? Thank you! Cheers, Frank[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31875#31875 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_R32F (and others) float textures are being normalized
HI Juan, Clamping to 0.0 to 1.0 range is standard for OpenGL texturing. I believe this now a new GL extension for a float format that isn't clamped to the 0.0 to 1.0 range, so have a look on OpenGL .org and other places online for further info. Robert. On Mon, Sep 20, 2010 at 6:14 PM, Juan Hernando jherna...@fi.upm.es wrote: Dear all, I'm writing some GLSL code that needs to access a 1D floating point texture as input in a vertex shader. My problem is that I'm getting clamped/normalized (not sure which one) values inside GLSL instead of the full range values. For debug purposes I've setup a dummy texture like this: osg::Image *image = new osg::Image; float *tmp = new float; image-setImage(1, 1, 1, GL_R32F, GL_RED, GL_FLOAT, (unsigned char*)tmp, osg::Image::USE_NEW_DELETE); tmp[0] = 2 osg::Texture1D *texture = new osg::Texture1D(); texture-setFilter(osg::Texture::MIN_FILTER, osg::Texture::NEAREST); texture-setFilter(osg::Texture::MAG_FILTER, osg::Texture::NEAREST); texture-setImage(image); In this case, the following GLSL expression: texture1D(the_texture, 0.0).r returns 1. But if I change the image setup to: float *tmp = new float[4]; image-setImage(1, 1, 1, GL_RGBA32F, GL_RGBA, GL_FLOAT, (unsigned char*)tmp, osg::Image::USE_NEW_DELETE); it works fine. Looking at the source code from Texture.cpp I've found that Texture::computeInternalFormatType() does not deal with GL_R32F, GL_RG32F, GL_R32UI, ... they all fall into the default clause of the switch statement which assigns _internalFormatType to NORMALIZED. At the same time I've found no member function to change that attribute manually. Is that an omission or am I doing something wrong in the initialization? If that's an omission, is there an easy workaround that doesn't require recompiling the library? Thanks and best regards, Juan ___ 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] Running an OpenGL program with mesa instead of the platform's OpenGL driver?
Hi J-S, The only that comes to my mind is change all RPATHS on dependent libraries. This is a little bit complicated, and maybe a I need to reinstall OS :S. Using otool -L you can see all the rpaths associated to a library or executable in mac. Using install_name_tool you can change a concrete rpath for a library or executable. Some preinstalled frameworks and libraries on macosx have their rpaths prefixed, so doing this you can point all these libraries to your mesa libraries. To avoid a complete mess in your system, maybe you can copy all frameworks and libraries to a dir, and change all rpaths of all these libraries and your applications. But this is really tricky. There are also the env var DYLD_FRAMEWORK_PATH, that could help. Good luck! Rafa. 2010/9/20 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com: Hi Jordi, Did you try LD_PRELOAD? Something like 'export LD_PRELOAD=/usr/lib/mesa/libGL.so' May be it can do the trick.. Seems like the MacOSX version of LD_PRELOAD is DYLD_INSERT_LIBRARIES. So having built a recent mesa now, I tried: DYLD_INSERT_LIBRARIES=...path/to/libGL.dylib osgversion and I get the same message: dyld: Symbol not found: _gll_noop Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Expected in: /sw/lib/mesa/libGL.1.dylib in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Trace/BPT trap I can run with DYLD_PRINT_LIBRARIES=YES and I see each library that's loaded. The problem seems to come from the fact that the QuartzCore library (and others) depends on other libraries that are in the OpenGL.framework, so it loads that all the time, even if I want to use Mesa in its place. Seems to me there's too much magic going on behind the scenes for Mesa to be usable under MacOS X. Other libraries (including the window system) depend on OpenGL and shared libraries are being loaded from other places on the system... Unless someone with more knowledge than me in this area could help, I'm stuck. :-( J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Rafael Gaitán Linares Instituto de Automática e Informática Industrial http://www.ai2.upv.es http://gvsig3d.blogspot.com Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgParticle effects on a moving object...
Hi Shayne, There isn't trick that using picking invokes so there is no reason why you can't do it using others methods. The osgparticleeffects example does explain what you have to do differently with moving models - that is to place the emiter on the moving model, and the particle system/updater in world coordinates, and configure the effect accordingly. Please have a look at what it says about moving models. Robert. On Mon, Sep 20, 2010 at 6:07 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: All, I have a need to attach osgParticle effects on a moving object (i.e smoke and fire trail from a moving missile). I’ve looked at the osgparticleeffects.cpp example in where they attach these effects based off a hit node from the pick event to see how I might do this. Unfortunately I need to invoke the effects from the moving object’s UpdateCallback event rather than from a pick event. I have tried several things to get this to work without success. As anyone else been able to something similar to what I’m trying to accomplish? I would appreciate any suggestions anyone might have on how to get this to work… Thanks, -Shayne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet setAttribute(Material) question
Hi Tom, I haven't heard of assigning an osg::Material as a cause of memory growth before, and what you are doing sounds like it's something that has been done with the OSG for over a decade, so my guess is that the basic should be working just fine. The three aspects that could be a cause are a bug in the OpenGL driver, or a problem with the memory usage tool reporting an problem, something in your own set up of the material that is causing a leak. For the later you'd need to be creating a new osg::Material quite regularily and not using a ref_ptr to manage it, the OSG itself uses ref_ptr consistently so once you assign it to the scene graph it should just safely look after itself. There isn't really a way for me to dig any further into the problem on your system, try moving to another machine with a different graphics card/driver/OS to see if that affects the problem you are witnessing. Robert. On Mon, Sep 20, 2010 at 10:06 PM, Tom Pearce tmpea...@gmail.com wrote: Hi OSGers, I'm using setAttribute(osg::Material* mat) on a matrix transform to control the color of an object (just a simple sphere for now, nothing fancy). Just using task manager in windows to watch process memory usage, I noticed that upon adding an object to the scene, the memory usage would start to creep upward. Thinking this was a leak of some kind in my application I looked into it further and found that the creep (~20kB/sec) was dependent on calling getOrCreateStateSet()-setAttribute(Material) for the first time - If I never set a material, the memory usage stays constant. When I wait for a key press and then set the material, the creep starts right away. If I remove the node, the usage stops increasing but does not decrease. Finally, if I just let it run, after a while (~500kB worth) the memory usage plateaus and is steady. I'm wondering if this something I should be worried about or not moving forward, or if that just happens and it isn't really an issue... either way I wouldn't mind knowing what's going on. Thank you! Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31866#31866 ___ 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] file name case changes
Hi Don, This sounds like a TortoiseSVN bug, as include/osgViewer/api/X11 is definitely upper case and has always been. Try removing the directory and checking it out again, perhaps it will solve the problem. Robert. On Mon, Sep 20, 2010 at 10:54 PM, Don Leich d...@ilight.com wrote: Hi all, Now that I'm back after a short vacation I fully intend to see if the BIND_PER_PRIMITIVE bug is in the SVN trunk. As a sporatic user of SVN I find that each time I try to use it is a challenge. I've now come across something odd that may well be a quirk of TortoiseSVN or might be an indication on something funky with the SVN code base. I found that I had to change the case of several OSG files before I could build. The first indication was this error generating the cmake configuration... CMake Error in src/osg/CMakeLists.txt: Cannot find source file GL. Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx After some trial and error I found that I could build if I changed these files and the directory x11 to upper-case: src/include/gl src/include/glu src/include/lod src/osg/lod.cpp src/include/osgViewer/api/x11 src/osgPlugins/ive/lod.cpp src/osgPlugins/ive/lod.h src/osgPlugins/bsp/bitset.cpp src/osgPlugins/bsp/bitset.h -Don Leich ___ 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] GL_R32F (and others) float textures are being normalized
Hi Werner and Robert Thanks for the answers. Clamping to 0.0 to 1.0 range is standard for OpenGL texturing. I believe this now a new GL extension for a float format that isn't clamped to the 0.0 to 1.0 range, so have a look on OpenGL .org and other places online for further info. In ARB_texture_float (http://www.opengl.org/registry/specs/ARB/texture_float.txt) the overview says: Floating-point components are clamped to the limits of the range representable by their format. And issue 7: Are floating-point values clamped for the fixed-function GL? [...] For the programmable pipelines, no clamping occurs. If it has been changed, I understand from the revision log that user-controlled clamping was added in 2004, but only for fragment operations (which I don't care because I'm reading the texture, not writing to it). The only transformation should be for fixed point formats (like the typical GL_RGBA, not integer texture formats) that are normalized to [0..1]. As I understand, the current osg::Texture class is already aware of the differences between fixed point, integer and float formats. However, I have found neither code inside Texture.cpp nor specific wording in the spec for user control of color component clamping/normalization during texturing. It seems that there isn't such a thing and the GL implementation just chooses the correct behaviour depending on the texture format. GL_R32F comes from ARB_texture_rg for GL 2.1 and it's in GL 3.0 core. I've used these and GL_RG32F formats before as target formats for FBOs, and by default the results are written and read by the shaders without clamping as expected. My best guess is that the driver is clamping GL_R32F when glTexImage1D is called, hence I'd dare to say it's a driver bug. That osg::Texture doesn't compute the correct InternalFormatType for these relatively new formats is inconsistent but should be harmless. By the way, I'm using the NVIDIA linux driver version 256.44 with a 2.0 context in case someone is curious enough to try other setups. Nevertheless, I've realized my problem is easily solved using GL_LUMINANCE32F_ARB instead of the more bizarre GL_R32F. Regards, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphics Context Question
Hi Paul, All OpenGL calss have to be done from a thread with valid graphics context, and some GLX calls have the same restriction. When the osgViewer runs multi-threaded each GraphicsContext/GraphicsWindow has it's own GraphicsThread, so any GL/specific GLX calls you need to do will need to be done in this thread. Attaching a pre/initial or post/final draw callback on the viewer's camera will enable you to do your calls. In your case you are wanting to do calls between update and cull, which is a bit awkward as osgViewer is set up so that cull is not intended to require a valid graphic context. The only times when cull does have a valid graphics context is when you use CullDrawThreadPerContext or SingleThreaded threading models. In these cases you could use a custom osgViewer::Renderer assigned to the active cameras (be it master or slave), in this custom Renderer you could override the cull/cull_draw method. What you are doing is rather on the bleeding edge though, it's not something I've experimented with myself so it may well be awkward to implement, if it is too problematic then this suggests that osgViewer needs to be refactored a little to make it possible to do what you are after. Perhaps even integrating sync support directly into osgViewer might be the right thing to do. Robert. On Tue, Sep 21, 2010 at 2:20 AM, paul1...@yahoo.com wrote: I need to call glXWaitVideoSyncSGI() between the update and cull traversals. As I understand it, this needs to be called with a valid graphics context so I do viewer.getCamera()-getGraphicsContext()-makeCurrent() and then call glXWaitVideoSyncSGI() and then call the viewer.renderingTraversals(). However, the glXWaitVideoSyncSGI call is only working when I use a SingleThreading model. Otherwise, glXWaitVideoSyncSGI is returning with an error about a Bad Context. What am I doing wrong? Paul P. ___ 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] [osgPlugins] Missing plugins
Hi, I've got osgViewer running, but when I try osgviewer --image osg256.png (pg. 8 of the Quick Start Guide) I get an error, failing to load the PNG viewer plugin. I looked at the plugins folder and can't find anything with png in the name. I opened CMake-gui and inspected the configuration output and see these three lines: Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR) Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR) Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) So I dutifully added the six missing values, pointing them to what I think might be correct folders and paths, and click Configure. The six new entries that I made disappear and the three lines of output are still there. So what do I need to do to get plugins for those filetypes? I'm doing all this on a MinGW/MSYS system. I haven't tried it yet on my MacOSX system. Cheers, Daryl -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31884#31884 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Adding ShadowedScene as a child ?
Hi, I'm using osgShadow::ShadowedScene to render shadows using shadowmap. The shadows are rendered correctly. As my scene graph gets complex i want to add the ShadowedScene as a child to another node as shown below Code: ref_ptrGroup scene (new Group); //Main light source Vec3 lightPosition(0,0,3); LightSource* ls = new LightSource; ls-getLight()-setPosition(Vec4(lightPosition,1)); ls-getLight()-setAmbient(Vec4(0.2,0.2,0.2,1.0)); ls-getLight()-setDiffuse(Vec4(0.6,0.6,0.6,1.0)); //Shadow stuff!!! ref_ptrosgShadow::ShadowedScene shadowedScene = new osgShadow::ShadowedScene; ref_ptrosgShadow::ShadowMap sm = new osgShadow::ShadowMap; shadowedScene-setShadowTechnique(sm.get()); sm-setTextureSize(osg::Vec2s(2048, 2048)); sm-setTextureUnit(1); sm-setLight(ls); // Shadowed scene added as a child to scene scene-addChild(shadowedScene.get()); // Set scene data viewer.setSceneData(scene.get()); As shown above if i add the shadowedScene to scene and set the scene data to scene, the shadows are not getting rendered. If i set the sceneData to shadowedScene the shadows are rendered correctly. But the scene graph has some other elements such as ODE physics, shaders applied to some nodes etc., are getting disabled if i set sceneData to shadowedScene. Please provide some suggestions on how to get the shadow effect by by adding the shadowedScene as a child Thank you! Cheers, Saravanan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31885#31885 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Adding ShadowedScene as a child ?
Hi Saravanan, On 21/09/10 20:04 , Saravanan Sivaprahasam wrote: I'm using osgShadow::ShadowedScene to render shadows using shadowmap. The shadows are rendered correctly. As my scene graph gets complex i want to add the ShadowedScene as a child to another node as shown below ... As shown above if i add the shadowedScene to scene and set the scene data to scene, the shadows are not getting rendered. If i set the sceneData to shadowedScene the shadows are rendered correctly. But the scene graph has some other elements such as ODE physics, shaders applied to some nodes etc., are getting disabled if i set sceneData to shadowedScene. Are you setting your shadow casting/receiving objects to be children of the ShadowedScene node? Apart from that it shouldn't matter if the ShadowedScene is set as scene data directly or through one or more intermediate children. (Which can be useful if you want to have objects that are not affected by shadows, such as skydomes, HUDs, etc). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote: I confirmed that the bug persists in today's SVN trunk. In the example already supplied the overall color is not applied when normals are given as BIND_PER_PRIMITIVE. I've just tested svn/trunk and 2.9.3 and can confirm that there is different behaviour. I've also isolated the two geometries that use BIND_PER_PRIMITIVE and they just use this binding for normals, but have no colour array assigned at all. So... they will be inheriting their colour from other geometries in a completely undefined way. This to me doesn't look like a bug at all, but an issue with a under-defined scene graph, and just by luck it's worked before. Please assign colours to all the geometries that need it and then re-test. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] depthbuffer question
Hi osgUsers,
I've been trying to read some values from the DepthBuffer and I don't seem
to get what I would expect. Here is a cut down version of my code (should be
able to run):
class CTestDrawCallback : public osg::Camera::DrawCallback
{
public:
void operator()( const osg::Camera cam ) const
{
osg::Image* pTest = new osg::Image;
pTest-readPixels( 256,256,1,1, GL_DEPTH_COMPONENT, GL_FLOAT );
float f = (*(float*)pTest-data());
osg::notify(osg::ALWAYS)
f = f
std::endl;
}
};
osg::Node* CreateScene()
{
osg::Group* pGroup = new osg::Group;
osg::Geode* pGeode = new osg::Geode();
pGeode-addDrawable( new osg::ShapeDrawable( new
osg::Box(osg::Vec3(0.0f,0.0f,0.0f),2.0f) ) );
pGroup-addChild( pGeode );
return pGroup;
}
int _tmain(int argc, _TCHAR* argv[])
{
osg::ref_ptrosgViewer::Viewer rViewer;
// construct the viewer
rViewer = new osgViewer::Viewer;
// make the viewer create a 512x512 window and position it at 32, 32
rViewer-setUpViewInWindow( 32, 32, 512, 512 );
// set the scene-graph data the viewer will render
rViewer-setSceneData( CreateScene() );
rViewer-getCamera()-setPostDrawCallback( new CTestDrawCallback );
// execute main loop
return rViewer-run();
}
I get a value of 0.0642448 and this is not what I expect.
I would expect that the near and far plane are automatically computed to fit
the box, which should mean the near plane is collinear with front of the
box.. which should result with a value of 0
can someone explain to me what I'm doing wrong?
regards,
Peter Wraae Marino
--
Bellinge Gymnasterne: http://www.bellingegymnasterne.dk
Power Tumbling: http://www.powertumbling.dk
OSG-Help: http://osghelp.com
Personal Site: http://www.marino.dk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGaph 2.9.9 dev release tagged :-)
Hi All, I have now tagged the 2.9.9 release. http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases From a quick scan of the ChangeLog since 2.9.8 I've noted the highest profile changes, but I might have missed a few... full changes as usual will be ChangeLog: * OpenSceneGraph-2.9.9, released on 21st September June 2010, key deliverables in this dev release are: o New osgText::TexNode that enables far more flexible text management, and includes support for user definable bevels in 3D Text. o New support for crease angles in osgUtil::SmoothingVisitor. o osgText::Text and Text3D visual quality improvements. o osgText::Font and Font3D have been combined into single Font class. o New order independent transparency example, osgiot. o New pov plugin for exporting a scene to POV-Ray format, enabling use of POV-Ray to do photo-realistic ray tracing o Revamp of osgParticle added support for shader based particle effects. o Initial steps towards shader composition with introduction of ShaderComposer and ShaderComponent classes. o Improvements to support of a wider range OpenGL ES platforms. o Improvements to osgQt::!QGraphicsViewAdapter. o Improvements to Cocoa support in osgViewer. o Improvements to ffmpeg plugin. o Improvements to fbx plugin. o Fix to TerraPage(txp) plugin's handling of !PageLOD child expiry, and a memory leak fix. o Many general bug fixes and minor feature improvements/optimizations. source package : OpenSceneGraph-2.9.9.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.9 OpenSceneGraph Thanks for your help in writing code, testing and fixes for 2.9.9. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with view-computeIntersections(x, y, intersections)
Hi all,
after reading the osgpick example picking seemed to be really easy.
Unfortunately in my application it doesn't work as expected.
I exactly coppied the example code.
osgUtil::LineSegmentIntersector::Intersections intersections;
if (view-computeIntersections(_x, _y, intersections)) {
osgUtil::LineSegmentIntersector::Intersections::iterator hitr =
intersections.begin();
for(; hitr != intersections.end(); ++hitr) {
if (!hitr-nodePath.empty()
!(hitr-nodePath.back()getName().empty())) {
. do something here
Some times the detected node is correct,
sometimes nothing is detected
and sometimes objects on a completely different place are listed
Any hints what I'm doing wrong? Actually there is not much that can be wrong
...
Thanks for any help
Werner
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] depthbuffer question
Hi Peter, On 21/09/10 21:52 , Peter Wraae Marino wrote: I've been trying to read some values from the DepthBuffer and I don't seem to get what I would expect. Here is a cut down version of my code (should be able to run): ... I get a value of 0.0642448 and this is not what I expect. I would expect that the near and far plane are automatically computed to fit the box, which should mean the near plane is collinear with front of the box.. which should result with a value of 0 can someone explain to me what I'm doing wrong? The auto-computed near/far planes would fit the bounding sphere around the box, which is larger than the box itself. Would that fit? Maybe you're assumptions are off? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] depthbuffer question
Hi Ulrich, on an earlier test of the near and far plane we saw a difference of the far and near plane values to be the size of the box.. so I assumed that the near and far is computed to fit the objects in the scene. or is this wrong? Peter On Tue, Sep 21, 2010 at 2:12 PM, Ulrich Hertlein u.hertl...@sandbox.dewrote: Hi Peter, On 21/09/10 21:52 , Peter Wraae Marino wrote: I've been trying to read some values from the DepthBuffer and I don't seem to get what I would expect. Here is a cut down version of my code (should be able to run): ... I get a value of 0.0642448 and this is not what I expect. I would expect that the near and far plane are automatically computed to fit the box, which should mean the near plane is collinear with front of the box.. which should result with a value of 0 can someone explain to me what I'm doing wrong? The auto-computed near/far planes would fit the bounding sphere around the box, which is larger than the box itself. Would that fit? Maybe you're assumptions are off? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Bellinge Gymnasterne: http://www.bellingegymnasterne.dk Power Tumbling: http://www.powertumbling.dk OSG-Help: http://osghelp.com Personal Site: http://www.marino.dk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGaph 2.9.9 dev release tagged :-)
Hi Robert, thanks for 2.9.91 Im out of office for a week now, but I'll test it afterwards. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31894#31894 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_R32F (and others) float textures are being normalized
Hi, we're using unclamped textures just fine. Also have a look at the difference between glFragColor and glFragData. cheers jp On 21/09/10 11:01, Juan Hernando wrote: Hi Werner and Robert Thanks for the answers. Clamping to 0.0 to 1.0 range is standard for OpenGL texturing. I believe this now a new GL extension for a float format that isn't clamped to the 0.0 to 1.0 range, so have a look on OpenGL .org and other places online for further info. In ARB_texture_float (http://www.opengl.org/registry/specs/ARB/texture_float.txt) the overview says: Floating-point components are clamped to the limits of the range representable by their format. And issue 7: Are floating-point values clamped for the fixed-function GL? [...] For the programmable pipelines, no clamping occurs. If it has been changed, I understand from the revision log that user-controlled clamping was added in 2004, but only for fragment operations (which I don't care because I'm reading the texture, not writing to it). The only transformation should be for fixed point formats (like the typical GL_RGBA, not integer texture formats) that are normalized to [0..1]. As I understand, the current osg::Texture class is already aware of the differences between fixed point, integer and float formats. However, I have found neither code inside Texture.cpp nor specific wording in the spec for user control of color component clamping/normalization during texturing. It seems that there isn't such a thing and the GL implementation just chooses the correct behaviour depending on the texture format. GL_R32F comes from ARB_texture_rg for GL 2.1 and it's in GL 3.0 core. I've used these and GL_RG32F formats before as target formats for FBOs, and by default the results are written and read by the shaders without clamping as expected. My best guess is that the driver is clamping GL_R32F when glTexImage1D is called, hence I'd dare to say it's a driver bug. That osg::Texture doesn't compute the correct InternalFormatType for these relatively new formats is inconsistent but should be harmless. By the way, I'm using the NVIDIA linux driver version 256.44 with a 2.0 context in case someone is curious enough to try other setups. Nevertheless, I've realized my problem is easily solved using GL_LUMINANCE32F_ARB instead of the more bizarre GL_R32F. Regards, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] shadows and custom shaders
Hi, So I have been experimenting with shadows in OSG using the ShadowMap shadow technique. With the default OSG implementation and every custom shader in my scene graph disabled the shadows work correctly. Once I turn my shaders on they stop working. This is understandable as he OSG shadow shader will be overridden. I then reimplemented the shadow projection code in my pixel shaders, but then still no shadows. I am not too familiar with the OpenGL fixed-function shadow pipeline. If you do not provide a vertex shader does OpenGL generate the proper texture coordinates by default. I saw that OSG was creating a TexGen attribute and applying that after shadow map creation. If I am implementing custom vertex shaders should I be overriding the ShadowMap and not allowing that TexGen to be created and then generate the proper texture coordinates in my vertex shader? At this point I think all that is missing is the proper texture coordinates for shadows to be working for me. Any help woul d be appreciated. Thanks in advance! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31896#31896 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_R32F (and others) float textures are being normalized
Hi J.P., we're using unclamped textures just fine. Also have a look at the difference between glFragColor and glFragData. I think you misunderstood the actual problem. The texture is not written by a fragment shader. I'm filling the texture from the client side and it is inside the vertex shader where clamped values are returned by the texture sampler. And this happens for GL_R32F but not for GL_RGBA32F or GL_LUMINANCE32F. Anyways, as I stated in my previous mail I'll just use GL_LUMINANCE32F instead of GL_32F. Thanks and cheers, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadows and custom shaders
Hello Michael, If I am implementing custom vertex shaders should I be overriding the ShadowMap and not allowing that TexGen to be created and then generate the proper texture coordinates in my vertex shader? At this point I think all that is missing is the proper texture coordinates for shadows to be working for me. Your intuition is correct, but you just need to calculate the shadow texture coordinates for the shadow texture unit. No need to disable the osg::TexGen because since it's fixed-function state, it will just be ignored when using a vertex shader. As has been said before, once you start using shaders for a given stage you need to do everything the fixed pipeline would have done for you in your shader for that stage yourself (at least, what you need). That includes fog, texgen, etc. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??
Hi Frank, My problem is a bit different. I'm running VS2010 as Administrator, but it still doesn't work. When I look at the above folder path, all it has are PDBs. In my case, that is not the correct path. The correct path is: C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/ All of my DLLs, etc., are in that path. They are not in the folder that the cmake install step is looking in. I don't know how to get them to build into the path that the cmake install step is looking for them in (aside from manually editing each project file by hand). Does anyone have any advice? IIRC, this was caused by a bug in CMake when generating VS2010 projects. People on the list found two possible solutions: 1. Upgrade to a more recent version of CMake, I think the bug is resolved now. 2. Generate for VS2008 instead of VS2010. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Application Verifier failure (on Windows) with getSampleOpenGLContext(...)
Hi all, I've just updated our OSG usage from 2.6.1 to 2.8.3 in the hopes of getting application verifier to accept our OSG usage. We previously had a problem with Application Verifier and OpenThreads in 2.6.1 but this has been fixed in 2.8.3, but we now experience a new problem. Luckily it seems to happen with all OSG examples and not just our own application. The setup: I'm using Application Verifier (which we need our application to pass) on Windows Vista 64 SP2, Dell M6500 workstation with Quadro FX2700M graphics and driver revision 258.96. OSG has been built from source with Visual studio 2005 SP1. I'm testing osgviewerd.exe with Application Verifier default basic settings. Observed problem: Application Verifier breaks into the debugger during the call of CreateGraphicsContext() with last function call in OSG being int pixelFormatIndex = ::ChoosePixelFormat(hdc, pixelFormat); in osgViewer::Win32WindowingSystem::getSampleOpenGLContext(). All the OSG applications I have tested with Application Verifier breaks in ChoosePixelFormat, but I don't know if this could be an OSG problem, a hdc usage problem or an Nvidia driver problem. I have also tried Application Verifier with osgviewerd.exe in OSG 2.9.8 with the same behavior. The complete callstack for the breakpoint is: ntdll.dll!773a0004() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!77407c5c() vfbasics.dll!AVrfpVectoredExceptionHandler(_EXCEPTION_POINTERS * ExceptionPointers=0x00dad994) Line 460 ntdll.dll!773ea4df() ntdll.dll!773d4461() ntdll.dll!773d4505() ntdll.dll!773ae49f() nvoglv32.dll!69d786c1() nvoglv32.dll!69d786c1() ntdll.dll!773ba957() ntdll.dll!773baaad() ntdll.dll!774319fe() osgviewerd.exe!mainCRTStartup() Line 414 C ntdll.dll!7741c1da() ntdll.dll!7741c20b() ntdll.dll!7741c20b() ntdll.dll!7741c449() vfbasics.dll!AVrfLogInTracker(_AVRF_TRACKER * Tracker=0x, unsigned short EntryType=1, void * EntryParam1=0x04ba6d40, void * EntryParam2=0x0080, void * EntryParam3=0x04ba, void * EntryParam4=0x6935bd2e, void * ReturnAddress=0x69351556) Line 300 + 0x10 bytes vfbasics.dll!AVrfpRtlAllocateHeap(void * Heap=0x69351137, unsigned long Flags=1765138528, unsigned long Size=769) Line 256 00dadf98() vfbasics.dll!AVrfpTlsGetValue(unsigned long dwTlsIndex=4294967295) Line 426 nvoglv32.dll!69b2561d() nvoglv32.dll!69b2a5e0() nvoglv32.dll!69d42336() verifier.dll!6bd559c9() vrfcore.dll!VfCoreStandardDllEntryPointRoutine(void * DllHandle=0x6950, unsigned long Reason=1, _CONTEXT * Context=0x) Line 558 + 0xc bytes vfbasics.dll!AVrfpStandardDllEntryPointRoutine(void * DllHandle=0x6950, unsigned long Reason=1, _CONTEXT * Context=0x) Line 787 + 0xa bytes ntdll.dll!773d919c() ntdll.dll!773c48e7() ntdll.dll!773ef7eb() ntdll.dll!773c446d() ntdll.dll!773c3f00() ntdll.dll!773c48c6() ntdll.dll!773c4553() ntdll.dll!773c436d() ntdll.dll!773c24be() ntdll.dll!773c2757() ntdll.dll!773c27be() ntdll.dll!773baeca() vfbasics.dll!AVrfpLeakLogResource(void * Resource=0x7741c449, _RESOURCE_RECORD_TYPE ResourceType=37459248, void * ReturnAddress=0x0023, void * Context=0x00db) Line 1316 + 0xd bytes ntdll.dll!7741c20b() vfbasics.dll!AVrfLogInTracker(_AVRF_TRACKER * Tracker=0x, unsigned short EntryType=3, void * EntryParam1=0x00194ac8, void * EntryParam2=0x092e, void * EntryParam3=0x0014, void * EntryParam4=0x1018, void * ReturnAddress=0x69351668) Line 300 + 0x10 bytes vfbasics.dll!AVrfpRtlFreeHeap(void * Heap=0x0014, unsigned long Flags=0, void * Address=0x00194ac8) Line 354 kernel32.dll!75634132()
Re: [osg-users] StateSet setAttribute(Material) question
Hi Robert, I agree with your assessment of possible places to look. This occurs even with creating a single new Material, and I always use ref_ptrs, so that isn't the source of it. I'll look into drivers etc. and post anything I find here in case others come across the same issue. Anybody out there have suggestions of a Windows process memory usage tracker that would be good to use? Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31901#31901 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??
Oh yes, that would explain it. I'll try using VS2008 when I get home (I just downloaded CMake yesterday so I think I have the latest version, but I'll double check that as well). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31902#31902 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_R32F (and others) float textures are being normalized
Hi, On 21/09/10 15:41, Juan Hernando wrote: Hi J.P., we're using unclamped textures just fine. Also have a look at the difference between glFragColor and glFragData. I think you misunderstood the actual problem. The texture is not written by a fragment shader. I'm filling the texture from the client side and it is inside the vertex shader where clamped values are returned by the texture sampler. And this happens for GL_R32F but not for GL_RGBA32F or GL_LUMINANCE32F. ah, OK. Sorry for the noise. jp Anyways, as I stated in my previous mail I'll just use GL_LUMINANCE32F instead of GL_32F. Thanks and cheers, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadows and custom shaders
Hi J-S, Thanks for the swift reply, good to know I was on the correct path. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31904#31904 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet setAttribute(Material) question
Hi Tom, Anybody out there have suggestions of a Windows process memory usage tracker that would be good to use? Try Process Explorer. In the process list, right-click on your app and select Properties, and you'll be able to see detailed CPU and memory usage graphs and stats specific to that process (so it isn't drowned in info from all processes on your machine). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadows and custom shaders
Hi Michael,
You are right. There can only be one shader program loaded which has to do all
the work.
If you overload the default shader from osgShadow, it has to do that work
together with your new stuff.
In my case I just created my own class Cl_SoftShadowMap, derived from
osgSoftShadowmap. I reimplemented two methods:
// If our shader needs additional uniforms, they may be set here
void Cl_SoftShadowMap::createUniforms() {
_uniformList.clear();
SoftShadowMap::createUniforms();
// This Variable will be set by any node using textures
_uniformList.push_back(new osg::Uniform(USE_TEXTURE_UNIFORM, false));
// Shadow creation can be switched on an off (we still need our shaders)
useShadowUniform = new osg::Uniform(USE_SHADOW_MAP_UNIFORM, useShadow);
_uniformList.push_back(useShadowUniform.get());
// Toggle between soft and hard shadows
useSoftShadowUniform = new osg::Uniform(USE_SOFT_SHADOW_UNIFORM,
useSoftShadow);
_uniformList.push_back(useSoftShadowUniform.get());
// Uniforms used for bump mapping
_uniformList.push_back(new osg::Uniform(USE_BUMP_MAP_UNIFORM, false));
_uniformList.push_back(new osg::Uniform(bumpMap, BUMP_TEXTURE_UNIT));
}
// We create our own shaders
void Cl_SoftShadowMap::createShaders(bool _enableShadow,
bool _enableBumpMapping,
bool _enableDisplacementMapping) {
if( _shaderList.empty() ) {
osg::ref_ptrosg::Shader vertexShader;
vertexShader = Cl_ShaderGen::getShader(osg::Shader::VERTEX,
_enableShadow,
_enableBumpMapping,
_enableDisplacementMapping);
_shaderList.push_back(vertexShader);
osg::ref_ptrosg::Shader fragmentShader;
fragmentShader = Cl_ShaderGen::getShader(osg::Shader::FRAGMENT,
_enableShadow,
_enableBumpMapping,
_enableDisplacementMapping);
_shaderList.push_back(fragmentShader);
}
}
By this way your own shaders get loaded an you can create any uniform youneed.
You can use it by calling shadowScene-setShadowTechnique(...);
I hope this helps.
- Werner -
On Tuesday 21 September 2010 15:25:23 Michael Irby II wrote:
Hi,
So I have been experimenting with shadows in OSG using the ShadowMap shadow
technique. With the default OSG implementation and every custom shader in
my scene graph disabled the shadows work correctly. Once I turn my shaders
on they stop working. This is understandable as he OSG shadow shader will
be overridden. I then reimplemented the shadow projection code in my pixel
shaders, but then still no shadows. I am not too familiar with the OpenGL
fixed-function shadow pipeline. If you do not provide a vertex shader does
OpenGL generate the proper texture coordinates by default. I saw that OSG
was creating a TexGen attribute and applying that after shadow map
creation. If I am implementing custom vertex shaders should I be
overriding the ShadowMap and not allowing that TexGen to be created and
then generate the proper texture coordinates in my vertex shader? At this
point I think all that is missing is the proper texture coordinates for
shadows to be working for me. Any help woul d be appreciated. Thanks in
advance!
Cheers,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31896#31896
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
TEXION Software Solutions
TEXION GmbH - Rotter Bruch 26a - D 52068 Aachen - HRB 14999 Aachen
Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu
Geschäftsführer/Managing Director: Werner Modenbach
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] error loading an ive file with OSG 2.8.3
Hi all, after several tests it seems the osgdb_ived.dll contained in the openscenegraph-all-2.8.3-win32-x86-vc80sp1-Debug.zip archive is not working. I recompiled it starting from the OpenSceneGraph-2.8.3.zip archive and using cmake to generate the VS2005 solution and it seems working fine. Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31909#31909 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] error loading an ive file with OSG 2.8.3
One more strange behaviour ... Running the exe from VS it works fine and the ive file is loaded correctly. In addition I added the OSG bin dir to the PATH env var before starting VS. On the other hand if I run my app from the windows command prompt I see the message: Warning: Could not find plugin to read objects from file afvg.ive. I can't understand that since I put the required osg dll, including the ive.dll, in the same dir of the exe file and moreover I added that dir to the PATH env. variable. What else should I do to make my app find the ive plugin dll? Regards Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31911#31911 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] error loading an ive file with OSG 2.8.3
Hi Gianni, I can't understand that since I put the required osg dll, including the ive.dll, in the same dir of the exe file and moreover I added that dir to the PATH env. variable. What else should I do to make my app find the ive plugin dll? set OSG_NOTIFY_LEVEL=DEBUG and then run your app. You will see lots of debugging messages, and OSG will tell you where it looked for the ive plugin... In general, either putting the plugin in your app's directory or a directory in the PATH is enough. But make sure if you're running the app in debug, that the debug plugin is in the right place... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSX Install Locations
Hi All, I'm wondering if someone can help me out with an OSX Install Question: (1) Working from the OSG Trunk, I build the OpenSceneGraph using frameworks. I have the CMAKE install directory set to ~/work/OpenSceneGraph-trunk-inst Everything builds cleanly and installs into the specified install directory. (2) I copy the contents of ~/work/OpenSceneGraph-trunk-inst/lib (e.g. all the frameworks + osgPlugins-2.9.9) to /Library/Frameworks (3) I run ~/work/OpenSceneGraph-trunk-inst/share/OpenSceneGraph/bin/osglogo.app Runs fine, but doesn't seem to use the freetype plugin. I looked at the plugins dir, and I find that all the plugins have a .so extension, I presume this doesn't matter. Within the osgPlugins-2.9.9 directory there exists the file: osgdb_freetyperd.so I've also tried putting the plugins in the directory: /Library/ApplicationSupport/OpenSceneGraph/Plugins/osgdb_freetype.so No luck there either. Thoughts? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] examples_osgviewerCocoa build error on OS X
Hello, When building OpenSceneGraph on OS X 10.6.4 and creating application bundles, I have the following error on examples_osgviewerCocoa. It happened on OSG 2.9.8 and it's still happening on 2.9.9. This only happens when I set cmake to build application bundles, and only on examples_osgviewerCocoa. A Copy Files step is set up with a path of ../., which Xcode doesn't like. I think recreating the examples_osgviewerCocoa target should fix it for me, but there must be a way to fix it in the cmake configuration files... or is no one else getting this? Thanks Eduardo -- PBXCp /Users/epoyart/OpenSceneGraph-2.9.9-build/bin/Debug/osgviewerCocoad.app/Contents/MacOS/.././Info.plist examples/osgviewerCocoa/Info.plist cd /Users/epoyart/OpenSceneGraph-2.9.9 /Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/pbxcp -exclude .DS_Store -exclude CVS -exclude .svn -strip-debug-symbols -resolve-src-symlinks /Users/epoyart/OpenSceneGraph-2.9.9/examples/osgviewerCocoa/Info.plist /Users/epoyart/OpenSceneGraph-2.9.9-build/bin/Debug/osgviewerCocoad.app/Contents/MacOS/../. pbxcp: error: open(): /Users/epoyart/OpenSceneGraph-2.9.9-build/bin/Debug/osgviewerCocoad.app/Contents/MacOS/.././Info.plist [/SourceCache/pbx_tools/pbx_tools-1706/pbxcp/file_utils.m:420]: No such file or directory Command /Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/pbxcp failed with exit code 1 - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] Qt, Collada OSG
Hi, STILL having issues with this. I can get OSG w/Collada to compile under MingGW under MSYS with no issues. However, I still get the mangled names when trying to compile my app under QT w/MinGW... Any thoughts on fixing this? I have tried compiling OSG Collada as Release and Debug, but still have issues. Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31916#31916 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Manage single window, single view and multi cameras scene.
Hi, I am writting an application wich need to use differents view to show the scene. Operator cas switch from one view to another typing a keyboard key... For example we start in top view, and when the operator press the c key, whe change to subjective (first person) view. I saw 3 differents approach, I can't make work any of them (for now), and I would like to understant difference between these approach, and wich approach I must focus on. 1. Use The osgProducer libraries. It seems to be an add on to OSG... If I well understand, I must downlad, compile and install the libProducer, and then download compile and install the osgProducer plugin... For now I can't compile libProducer due to some errors, but with some hours of work, i Will be able to compile and install it. But can I do what I want without using Producer ? 2. Use two CameraView objects and the osgWidget::CameraSwitchHandler. 3. Create two Camera Objetct's, the first one is attached somewhere on the top of my vehicle for the top view, and the other one is attached on the driver seat for the subjective view. To switch from one camera to the other, I suppose that using the method Viewer::setCamera will be correct. What is the best method ? Had I forgetten to speek about the best method ? Does one of these 3 methods is wrong ? Thank you very much! Cheers, BARRAL -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31879#31879 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer issues
Hello, I recently converted our osg based application over to use Composite Viewer because we need multiple Views on the same scene graph. I'm running in to a little snag which appears to be a bug in CompositeViewer. Simple way of explaining the manifestation of the issue is that I have two Windows and two Views (one view per window) and they both have event handlers attached to the views which react to the osgGA::GUIEventAdapter::RESIZE event. Resizing works hunky dory for view 0 but it does not work correctly for view 1. I believe the culprit is related to these lines of code found in CompositeViewer::eventTraversal(). osgViewer::View* masterView = getViewWithFocus() ? getViewWithFocus() : _views[0].get(); . . . viewEventsMap[masterView].insert( viewEventsMap[masterView].end(), gw_events.begin(), gw_events.end() ); The problem is that when resizing, apparently getViewWithFocus() returns NULL (I guess because the mouse is over the window frame and not the view within the window. Therefore a resize event is taken out of the graphics window queue for the 2nd window and stuck into the event queue for the 0 view (a mismatch). The effect for me is that the when I resize one window the HUD I have set up in the other window receives the resize event and changes which obviously isn't what I want J. This does seem to be somewhat intermittent and may be related to whether your mouse tends to fall off the window frame towards the view or away from the view. PS I don't have a solution in hand yet. I thought I would throw this out there in case it's a known issue or something. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Manage single window, single view and multi cameras scene.
Greetings BARRAL! Well, I'm not sure if this would be the best way, but I would do one of two ways. 1) You can use a composite viewer to have all your views in one window and have a camera for each view. 2) Set up matrix points around your object and set the camera home to the matrix point using a key press -look at the 'osgpick' example in OSG or you can some other methodology. In either case, you can use the bounding box of the object your viewing to help set the starting distance of the views. Hope that helps! ... D Glenn D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31918#31918 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] Qt, Collada OSG
On Sep 21, 2010, at 4:21 PM, Samuel Grant wrote: Hi, STILL having issues with this. I can get OSG w/Collada to compile under MingGW under MSYS with no issues. However, I still get the mangled names when trying to compile my app under QT w/MinGW... Any thoughts on fixing this? I have tried compiling OSG Collada as Release and Debug, but still have issues. Compile all from Source ... HTH___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Particle in shader get/set geometry [SEC=UNCLASSIFIED]
Hi -just a quick one - Im delving into osg::Particle at the moment and I wish to do some glsl processing on the geometry or whatever particle template is used. Is this trivial ? and is there a way to set/get the drawables in an osg Particle system? Regards IMPORTANT: This email remains the property of the Department of Defence 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] Manage single window, single view and multi cameras scene.
Tom, I manage to do that with a CameraViewSwitchManipulator, and two CameraView object (one for each view), and that works well... Thank you for your help Cheers, BARRAL -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31923#31923 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] (no subject)
Hi,do not send mail. I am very busy. -- Vivek Dwivedi, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
