Re: [osg-users] [vpb] Problems using SSI Cluster Example
Hi again, This time, when I execute my example with vpbmaster, every tasks submitted to another node fails and the console show this message: Warning: Task tasks/build_root_L0_X0_Y0.task has failed, blacklisting machine node02 and resubmitting task. Finally, every failed task is submitted to rootnode, but that's I haven't a cluster. Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22862#22862 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HW swap synching with swap groups/barriers
Hi Roland, thanks for the info, in this case we'll also go with our own implementation. Do you use Linux? I'd like to know whether HW/Drivers really support this feature cleanly under Linux. regards, tugkan Hi Tugkan the submission was indeed not accepted. We are working with a custom OSG version that includes this modification. kind regards, Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22800#22800 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org . -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463641 fax +49.8031.463645 emailtug...@vires.com internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HW swap synching with swap groups/barriers
Hi Tugkan, Yes, we are using Linux. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22864#22864 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Problems using SSI Cluster Example
Hi, have a look at the command in the task file. I think it's there, but double check. Somewhere the osgdem command line that would be executed on the child can be found. Execute this manually on the child node (or through ssh) to see what is happening. HTH jp Samuel Jarque wrote: Hi again, This time, when I execute my example with vpbmaster, every tasks submitted to another node fails and the console show this message: Warning: Task tasks/build_root_L0_X0_Y0.task has failed, blacklisting machine node02 and resubmitting task. Finally, every failed task is submitted to rootnode, but that's I haven't a cluster. Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22862#22862 ___ 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] Faster build with precompiled headers (PCH)?
IMHO precompiled headers are only useful if used on headers that do not or at most rarely change. That leaves little options for which headers to include: Including the standard C/C++ headers in a precompiled header is useful. These should not change anyways. The question if other headers change _rarely_ boils down to your usage pattern. If you are a OSG library developer you would probably not like it if you have to compile all of the osg libraries if you change just any one header in the core osg library. This is one of the consequences though if one takes the precompiled headers a step to far, because all .cpp files will depend on the precompiled header, which in its turn depends on the headers it includes. On the other hand, people who just compile the whole of OSG from source once in a while will probably experience a significant speedup if using precompiled headers. This is one reason it is very important to make precompiled headers optional using cmake, probably defaulting to off. Erik den Dekker On 19-01-2010, at 06:37, Ulrich Hertlein wrote: On 19/01/10 15:21 , Martin Beckett wrote: This causes an issue with ShadowVolumeOccluder which defines a std::pair named Point, but the precompiled header already includes an osg::Point. ShadowVolumeOccluder has a using namespace osg which leads to a clash. ... Would it be a good idea to avoid using namespace osg in the headers? Absolutely! In which OSG include file do you find this? My version of ShadowVolumeOccluder hasn't it and a grep on svn trunk doesn't show anything too... /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN 10968 freetype plugin broken on OS X / MacPorts
Hi Ulrich, Sorry about this. I made changes to try and fix Mingw build. Could you have a look to see if you can get CMakeLists.txt configuration that adds in the path to where the headers are. If we can get it working then we may just have to revert the changes for Mingw and force Mingw users to fix there local install of Freetype. Robert. On Tue, Jan 19, 2010 at 2:13 AM, Ulrich Hertlein u.hertl...@sandbox.de wrote: The SVN is currently giving me a compile error: g++ -Dosgdb_freetype_EXPORTS -DOSG_DEBUG_POSTFIX=d -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -mmacosx-version-min=10.5 -ftree-vectorize -fvisibility-inlines-hidden -fPIC -I/Users/uli/Projects/osg/OpenSceneGraph/build/include -I/Users/uli/Projects/osg/OpenSceneGraph/include -I/Library/Frameworks/FreeType.framework/Headers -I/Library/Frameworks/freetype.framework/freetype -F/Library/Frameworks -o CMakeFiles/osgdb_freetype.dir/FreeTypeFont.cpp.o -c /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/freetype/FreeTypeFont.cpp cc1plus: error: /Library/Frameworks/freetype.framework/freetype: not a directory make[2]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/FreeTypeFont.cpp.o] Error 1 make[1]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/all] Error 2 make: *** [all] Error 2 As the error indicates /Library/Frameworks/FreeType.framework/FreeType isn't a directory but a framework, so the code in freetype/CMakeLists.txt is wrong. This was last modified in r10964. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT and QOSGWidget issues
Many thanks guys it looks like that's fixed the problem Cheers, Ant -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22866#22866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Porting problem. 2.2 to 2.8.2 - simple HUD overlay
Hi Mark, I can't think of a specific reason for the difference, perhaps a bug fix has changed the behavior that you were once relying upon. Does the osghud example work for you? My best guess right now would be that geometry is outwith the near or far clipping planes and the OSG 2.2 and 2.8.2 have changed the way they are maintained. This is just clutching at straws though. The best strategy for you might be to have a look at osghud and then try and mimic what it's doing in your own code. Robert. On Tue, Jan 19, 2010 at 6:25 AM, Mark Hurry m...@dwork.com wrote: Hi I have been working for a few days on 2.8.2 to port my display system from 2.2. The 3D is displayed as I would expect, but unfortunately my HUD overlay that worked in 2.2 is no longer being displayed. Anyone got any ideas? Below is how I setup my HUD (just a series of lines that I update each frame) // set the projection matrix pHUDCamera-setProjectionMatrix(osg::Matrix::ortho2D(HUD_screen_min_x,HUD_screen_max_x,HUD_screen_min_y,HUD_screen_max_y)); // set the view matrix pHUDCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); pHUDCamera-setViewMatrix(osg::Matrix::identity()); // only clear the depth buffer pHUDCamera-setClearMask(GL_DEPTH_BUFFER_BIT); // Make sure HUD is last thing to be render; we want it always on top pHUDCamera-setRenderOrder(osg::CameraNode::POST_RENDER); pHUDCamera-addChild( pHUDGeode ); root-addChild( pHUDCamera ) ; The line data is setup using pHUDGeometry-setVertexArray(pHUDVertices); pHUDGeometry-addPrimitiveSet(new osg::DrawArrays(GL_LINES,0,number_of_HUD_vertices)); I have looked through the archive but have not found a solution. So I have obviously missed something. Any suggestions would be much appreciated. I’m using XP Pro, VS2005 v8 Thanks MarkH ___ 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] Draggers in custom size viewport problem
Hi Mika, On Tue, Jan 19, 2010 at 7:05 AM, Mika Hakkarainen mika.p.hakkarai...@gmail.com wrote: Doesn't anyone can help me with this one? I am totally stuck in this problem. I really would appreciate any help with this. Should I do something differently or is the problem somewhere else. I would guess the lack of response if that most people like myself don't really have any ideas what might be amiss as it's a combination we've not tried before. The best I can suggest is try experimenting with viewport sizes which are only a small size different to what you've set, or even the same value, see what happens, try to change one thing at a time and dig into the code with a debugger to see what's happening. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewport inheritance and RTT
Hi, I am using version 2.9.5. I haven't had a chance to try 2.9.6 yet but I am using a fairly recent version. As I said in a previous message, the RenderStage for the RTT camera has the correct viewport setup (in both its camera and in its member variable) after the cull traversal. After establishing this I wasn't sure what else to try. I am happy with my work around for now though. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, 15 January 2010 4:55 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Viewport inheritance and RTT Hi Brad, I've read this thread and a bit suprised that the RTT Camera's Viewport wasn't being used. Which version of the OSG are you working with? I wonder if this is a bug in a older version of the OSG or something still lurking in the OSG. The way that the viewports are intended to be inherited is from above such that if the RTT Camera doesn't have it's own viewport then it should inherit this from it's the nearest camera in it's parental chain. If the RTT Camera does define it's own viewport then this should be used and there shouldn't be a need to provide one via a StateSet. This is working from memory though... this is how it should work, hopefully the code should be doing this as well ;-) Cheers, Robert. On Fri, Jan 15, 2010 at 6:11 AM, Christiansen, Brad brad.christian...@thalesgroup.com.au wrote: Hi, For the record, I have found a workaround for the issue. To fix the problem, I did the following the RTT Camera: ss = rttCamera-getOrCreateStateSet(); osg::Viewport* vp = new osg::Viewport(0,0,textureSize,textureSize); ss-setAttributeAndModes(vp, osg::StateAttribute::OVERRIDE osg::StateAttribute::ON); It was my understanding that this would have the same effect as just setting on the viewport on the camera. However, this works, but just setting the viewport doesn't. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: Friday, 15 January 2010 8:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Viewport inheritance and RTT Hi, Thanks for your answer. In relation to your comment: I'm still not sure why you want to use a slave? I remember something you said about shadows, but don't understand why shadows should differ between slave/not slave. Pre-render should work fine with just an RTT camera placed somewhere in the graph and in this case you can set everything manually. I am using an RTT camera placed somewhere in the graph and I am setting everything manually. As far as I can tell I am using a very simple, basic case for RTT (it doesn't actually involve shadows). This is why I am so stuck on what can be going wrong. I will modify one of the examples to match what I am doing so I can examine the issue in a very simple setup and go from there. I am really stuck on what to do to try and fix this. Thanks again for your help. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P. Delport Sent: Thursday, 14 January 2010 4:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Viewport inheritance and RTT Hi, Christiansen, Brad wrote: Hi, Just 'resubmitting' my issue with a more simple question to see if anyone has any ideas. What are the rules with viewport inheritance? - My understanding is: If a camera has a viewport set, this is used when rendering the cameras sub-graph. If it is not set, it uses the parent cameras viewport. - What I am seeing: My pre-render camera (rendering to a texture) has a viewport set but its sub-graph is being rendered using its parent cameras viewport. I have double checked that the viewport is set during the cull traversal. The pre-render cameras viewport is placed on the stack, and set on the RenderStage used to render the camera, yet it is still rendered using the parents viewport. - My question/s: What could cause this to occur? i.e. when is a local viewport ignored and 'overridden' by a parents viewport. What should I look at to debug this? I am not sure what to check after seeing the Renderstage apparently setup correctly. sorry, I can't answer all your questions. I don't think this goes as deep as renderstage. Have a look at View and Viewer and check the handling of slaves. Check where addSlave adds the View and then check where the list of views is used. I am completely stumped now and this is proving a bit of a show-stopper for me. Any suggestions on what to look at would be greatly appreciated. I'm still not sure why you want to use a slave? I remember something you said about shadows, but don't understand why shadows should differ between slave/not
Re: [osg-users] Draggers in custom size viewport problem
Hi Robert,
My guess was similar.
But since my last post I found couple of issues.
1:
const osg::Camera* View::getCameraContainingPosition(float x, float y, float
local_x, float local_y) const
There is used getXmin() when calculating new Y-values in if(!gw){...
Bug? However, changing this didn't solve the problem.
2:
My real app is wxWidgets based and I have graphics context available. I
noticed, that event state's (GUIEventAdapter) graphics context was always null
in my case (in previous method). By setting the graphics content to the viewer
solved my problem in my app.
viewer-getEventQueue()-setGraphicsContext(graphicsWindow.get());
After this, the picking and draggers worked as expected/wanted.
Cheers,
Mika
robertosfield wrote:
Hi Mika,
On Tue, Jan 19, 2010 at 7:05 AM, Mika Hakkarainen
wrote:
Doesn't anyone can help me with this one? I am totally stuck in this
problem. I really would appreciate any help with this. Should I do
something differently or is the problem somewhere else.
I would guess the lack of response if that most people like myself
don't really have any ideas what might be amiss as it's a combination
we've not tried before. The best I can suggest is try experimenting
with viewport sizes which are only a small size different to what
you've set, or even the same value, see what happens, try to change
one thing at a time and dig into the code with a debugger to see
what's happening.
Robert.
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=22872#22872
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Faster build with precompiled headers (PCH)?
Hi Erik, You're absolutely right. And what about three levels of PCHs? 1. Disable PCH 2. Enable PCH - Profile OSG dev (only standard includes) 3. Enable PCH - Profile OSG user (standard includes and base OSG ones, such as Node) It would require a few lines of CMake scripts. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Erik den Dekker e...@dendekker.com a écrit : IMHO precompiled headers are only useful if used on headers that do not or at most rarely change. That leaves little options for which headers to include: Including the standard C/C++ headers in a precompiled header is useful. These should not change anyways. The question if other headers change _rarely_ boils down to your usage pattern. If you are a OSG library developer you would probably not like it if you have to compile all of the osg libraries if you change just any one header in the core osg library. This is one of the consequences though if one takes the precompiled headers a step to far, because all .cpp files will depend on the precompiled header, which in its turn depends on the headers it includes. On the other hand, people who just compile the whole of OSG from source once in a while will probably experience a significant speedup if using precompiled headers. This is one reason it is very important to make precompiled headers optional using cmake, probably defaulting to off. Erik den Dekker On 19-01-2010, at 06:37, Ulrich Hertlein wrote: On 19/01/10 15:21 , Martin Beckett wrote: This causes an issue with ShadowVolumeOccluder which defines a std::pair named Point, but the precompiled header already includes an osg::Point. ShadowVolumeOccluder has a using namespace osg which leads to a clash. ... Would it be a good idea to avoid using namespace osg in the headers? Absolutely! In which OSG include file do you find this? My version of ShadowVolumeOccluder hasn't it and a grep on svn trunk doesn't show anything too... /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multichannel or multi display on three computers
Hi, I found that osgcluster (sample) support multichannel both in viewing and syncronization. But there are still some questions: 1. Number of channel 2. How to configure slaves? I run well with one master, one slave. But when I run with more than one slave, say 2, there is an error. I guess that the reason may be port number (must be different between slaves?). Osgcluster uses broadcasting, it means that not specify IP / computer name of slave. 2. Images from two channels seem smooth and continuos, with OFFSET parameter. But with the that wide image, we only can put display / monitor side by side IN A LINE. For a multi-channel system that arrange displays not in a line, say 3 displays -- one hafl of a hexagon. How does the angle between two displays effect the viewing. How to calculate the parameter. Hope to receive hints from everyone, Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22875#22875 Attachments: http://forum.openscenegraph.org//files/multi_channel_198.pdf ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Web 3D opensource solution by Google ?
Hi, I just released V0.4.0 of SceneJS, an open source JavaScript scene graph framework that allows you to program hardware-accellerated 3D scenes that run in the Web browser without plugins. SceneJS operates on top of the WebGL canvas, which is supported by at least Firefox, Opera, Chrome and Safari. For the demos and playroom, I recommend using Firefox nightly with WebGL enabled. Oops, since this is my first post here, the tiny wee feedback message at the top tells me I'm not allowed to post URLs!! So please go to: scenejs [DOT] com ... Thank you! Cheers, Lindsay -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22851#22851 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Faster build with precompiled headers (PCH)?
Different levels of PCH sounds like a good suggestion,... When I tried PCH on MSVC about a year ago I tried to take it to the max and included all used headers to the precompiled header; This gained the maximum performance for a single compile of the entire library,… The counter side being that changing a single core osg header means you have to compile the entire osg again,.. Still, this could be a valid usage model for people that want to compile a library from code, but never change a line. It could be the top level of PCH in your suggestion. There's one more thing to it though; precompiled headers should be kept in sync with the development of the rest of the osg. This may not be too grave a task. Missing a header in the PCH just means non-optimal compile performance, and including an extra header that is no longer available will pop up as a build error as soon as someone tries to compile with PCH. Erik den Dekker On 19-01-2010, at 11:33, Sukender wrote: Hi Erik, You're absolutely right. And what about three levels of PCHs? 1. Disable PCH 2. Enable PCH - Profile OSG dev (only standard includes) 3. Enable PCH - Profile OSG user (standard includes and base OSG ones, such as Node) It would require a few lines of CMake scripts. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Erik den Dekker e...@dendekker.com a écrit : IMHO precompiled headers are only useful if used on headers that do not or at most rarely change. That leaves little options for which headers to include: Including the standard C/C++ headers in a precompiled header is useful. These should not change anyways. The question if other headers change _rarely_ boils down to your usage pattern. If you are a OSG library developer you would probably not like it if you have to compile all of the osg libraries if you change just any one header in the core osg library. This is one of the consequences though if one takes the precompiled headers a step to far, because all .cpp files will depend on the precompiled header, which in its turn depends on the headers it includes. On the other hand, people who just compile the whole of OSG from source once in a while will probably experience a significant speedup if using precompiled headers. This is one reason it is very important to make precompiled headers optional using cmake, probably defaulting to off. Erik den Dekker On 19-01-2010, at 06:37, Ulrich Hertlein wrote: On 19/01/10 15:21 , Martin Beckett wrote: This causes an issue with ShadowVolumeOccluder which defines a std::pair named Point, but the precompiled header already includes an osg::Point. ShadowVolumeOccluder has a using namespace osg which leads to a clash. ... Would it be a good idea to avoid using namespace osg in the headers? Absolutely! In which OSG include file do you find this? My version of ShadowVolumeOccluder hasn't it and a grep on svn trunk doesn't show anything too... /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] Faster build with precompiled headers (PCH)?
I thing getting PCHs in sync would be very easy. Moreover, I suggest that even the highest level of PCH only include headers frequently added, such as Node, Drawable, NodeCallback, and such (=not too specific ones). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Erik den Dekker e...@dendekker.com a écrit : Different levels of PCH sounds like a good suggestion,... When I tried PCH on MSVC about a year ago I tried to take it to the max and included all used headers to the precompiled header; This gained the maximum performance for a single compile of the entire library,… The counter side being that changing a single core osg header means you have to compile the entire osg again,.. Still, this could be a valid usage model for people that want to compile a library from code, but never change a line. It could be the top level of PCH in your suggestion. There's one more thing to it though; precompiled headers should be kept in sync with the development of the rest of the osg. This may not be too grave a task. Missing a header in the PCH just means non-optimal compile performance, and including an extra header that is no longer available will pop up as a build error as soon as someone tries to compile with PCH. Erik den Dekker On 19-01-2010, at 11:33, Sukender wrote: Hi Erik, You're absolutely right. And what about three levels of PCHs? 1. Disable PCH 2. Enable PCH - Profile OSG dev (only standard includes) 3. Enable PCH - Profile OSG user (standard includes and base OSG ones, such as Node) It would require a few lines of CMake scripts. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Erik den Dekker e...@dendekker.com a écrit : IMHO precompiled headers are only useful if used on headers that do not or at most rarely change. That leaves little options for which headers to include: Including the standard C/C++ headers in a precompiled header is useful. These should not change anyways. The question if other headers change _rarely_ boils down to your usage pattern. If you are a OSG library developer you would probably not like it if you have to compile all of the osg libraries if you change just any one header in the core osg library. This is one of the consequences though if one takes the precompiled headers a step to far, because all .cpp files will depend on the precompiled header, which in its turn depends on the headers it includes. On the other hand, people who just compile the whole of OSG from source once in a while will probably experience a significant speedup if using precompiled headers. This is one reason it is very important to make precompiled headers optional using cmake, probably defaulting to off. Erik den Dekker On 19-01-2010, at 06:37, Ulrich Hertlein wrote: On 19/01/10 15:21 , Martin Beckett wrote: This causes an issue with ShadowVolumeOccluder which defines a std::pair named Point, but the precompiled header already includes an osg::Point. ShadowVolumeOccluder has a using namespace osg which leads to a clash. ... Would it be a good idea to avoid using namespace osg in the headers? Absolutely! In which OSG include file do you find this? My version of ShadowVolumeOccluder hasn't it and a grep on svn trunk doesn't show anything too... /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] [vpb] Problems using SSI Cluster Example
Hi, I had a look at the command in the task file and I found this: osgdem --run-path /gis -s build_master.source --record-subtile-on-leaf-tiles -l 1 --task tasks/build_root_L0_X0_Y0.task --log logs/build_root_L0_X0_Y0.log I have executed it through ssh and seems to work fine because console doesn' show error messages but if I execute this command on that computer, console shows a segmentation fault message. I think this happens because on that computer doesn't exist build_master.source file. But when before I execute vpbmaster, this file doesn't exist, so I don't understand why this happens. Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22879#22879 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Problems using SSI Cluster Example
Hi Samuel, what OS/version are you using? Do all your nodes have access to the complete data set, i.e. can all see /gis? jp Samuel Jarque wrote: Hi, I had a look at the command in the task file and I found this: osgdem --run-path /gis -s build_master.source --record-subtile-on-leaf-tiles -l 1 --task tasks/build_root_L0_X0_Y0.task --log logs/build_root_L0_X0_Y0.log I have executed it through ssh and seems to work fine because console doesn' show error messages but if I execute this command on that computer, console shows a segmentation fault message. I think this happens because on that computer doesn't exist build_master.source file. But when before I execute vpbmaster, this file doesn't exist, so I don't understand why this happens. Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22879#22879 ___ 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] [vpb] Problems using SSI Cluster Example
Hi, what OS/version are you using? Do all your nodes have access to the complete data set, i.e. can all see /gis? I'm using 2 computers with ubuntu 9.10, osg 2.8.0 and vpb 0.9.10. /gis have all permissions, so the 2 nodes can see it. Like the example, I have the same files on 2 nodes. node01:/gis$ ssh node02 ls /gis machinepool.txt ps_height_16k.tif ps_texture_16k.tif node01:/gis$ ls /gis machinepool.txt ps_height_16k.tif ps_texture_16k.tif Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22883#22883 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Problems using SSI Cluster Example
Hi Samuel, Have a look at the logs/ directory that the build generated. In particular look for the logs for the task that failed this might give you an indicated why the task failed and the machine was black listed. The black listing scheme is used to handle cases where a large cluster is running but one of two machines go down during the build, or perhaps they simply don't work in the first place. The black listing allows the build to re-submit the failed tasks to machines that are still working. Robert. On Tue, Jan 19, 2010 at 12:34 PM, Samuel Jarque osgfo...@tevs.eu wrote: Hi, what OS/version are you using? Do all your nodes have access to the complete data set, i.e. can all see /gis? I'm using 2 computers with ubuntu 9.10, osg 2.8.0 and vpb 0.9.10. /gis have all permissions, so the 2 nodes can see it. Like the example, I have the same files on 2 nodes. node01:/gis$ ssh node02 ls /gis machinepool.txt ps_height_16k.tif ps_texture_16k.tif node01:/gis$ ls /gis machinepool.txt ps_height_16k.tif ps_texture_16k.tif Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22883#22883 ___ 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] [vpb] Problems using SSI Cluster Example
Hi Robert, I've had a look at the /gis/logs/ directory and I don't see any interesting informations to solve my problem. I have to log files, this is one of them: 0.005: Adding terrainTile 0.392: DataSet::_run() 0 0 0.394: DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system 0.395: started DataSet::createDestination(2) 0.395: Time for after_reproject 0.03 0.395: DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system 0.395: AR=1.00 C1=1 R1=1 0.395: createNewDestinationGraph 0.395: Time for _destinationGraph-computeMaximumSourceResolution() = 0.13 0.395: Time for createDestinationGraph 0.91 0.395: Time for after_computeNeighbours 0.10 0.395: completed DataSet::createDestination(2) 0.395: There are 2 contributing source files: 0.395: /gis/ps_height_16k.tif 0.395: /gis/ps_texture_16k.tif 0.427: Realized window 0.427:Base Directory already created 0.427: Need to create output task directory = /gis/puget_root_L0_X0_Y0 0.427:Directory already created 0.427: We have to record ../task/name 0.427: Task output directory = /gis/puget_root_L0_X0_Y0/ 0.427: started DataSet::writeDestination(/gis/puget.ive) 0.427: _readRow 1 0.427:reading tile level=0 X=0 Y=0 0.427: imageName = puget_L0_X0_Y0.dds 0.427: DestinationTile::readFrom(SetName=, FileName=/gis/ps_texture_16k.tif) 0.470: DestinationTile::readFrom(SetName=, FileName=/gis/ps_height_16k.tif) 0.478: _equalizeRow 1 0.478:equalizing tile level=0 X=0 Y=0 0.478: _writeRow 1 0.482: DestinationTile::createStateSet() - DataSet::MIP_MAPPING_IMAGERY 0.482: Compressed image 1.276:getDirectory()= /gis/ 1.276:writeNodeFile = 0 X=0 Y=0 filename=/gis/puget.ive 1.276: _writeNodeFile(/gis/puget.ive) 1.276: vpb::access(/gis/puget.ive, W_OK)=-1 1.276: vpb::access(/gis, W_OK)=0 1.279: completed DataSet::writeDestination(/gis/puget.ive) 1.281: Elapsed time = 1.281352 The other log file is like this, without many changes. Do you know if there are another log directory that can be more useful? Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22887#22887 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Problems using SSI Cluster Example
Hi Samuel, You need to find which tasks failed on the machine which was black listed then look a their logs. Looking at logs of tasks that completed successfully won't help you at all. Robert. On Tue, Jan 19, 2010 at 12:59 PM, Samuel Jarque osgfo...@tevs.eu wrote: Hi Robert, I've had a look at the /gis/logs/ directory and I don't see any interesting informations to solve my problem. I have to log files, this is one of them: 0.005 : Adding terrainTile 0.392 : DataSet::_run() 0 0 0.394 : DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system 0.395 : started DataSet::createDestination(2) 0.395 : Time for after_reproject 0.03 0.395 : DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system 0.395 : AR=1.00 C1=1 R1=1 0.395 : createNewDestinationGraph 0.395 : Time for _destinationGraph-computeMaximumSourceResolution() = 0.13 0.395 : Time for createDestinationGraph 0.91 0.395 : Time for after_computeNeighbours 0.10 0.395 : completed DataSet::createDestination(2) 0.395 : There are 2 contributing source files: 0.395 : /gis/ps_height_16k.tif 0.395 : /gis/ps_texture_16k.tif 0.427 : Realized window 0.427 : Base Directory already created 0.427 : Need to create output task directory = /gis/puget_root_L0_X0_Y0 0.427 : Directory already created 0.427 : We have to record ../task/name 0.427 : Task output directory = /gis/puget_root_L0_X0_Y0/ 0.427 : started DataSet::writeDestination(/gis/puget.ive) 0.427 : _readRow 1 0.427 : reading tile level=0 X=0 Y=0 0.427 : imageName = puget_L0_X0_Y0.dds 0.427 : DestinationTile::readFrom(SetName=, FileName=/gis/ps_texture_16k.tif) 0.470 : DestinationTile::readFrom(SetName=, FileName=/gis/ps_height_16k.tif) 0.478 : _equalizeRow 1 0.478 : equalizing tile level=0 X=0 Y=0 0.478 : _writeRow 1 0.482 : DestinationTile::createStateSet() - DataSet::MIP_MAPPING_IMAGERY 0.482 : Compressed image 1.276 : getDirectory()= /gis/ 1.276 : writeNodeFile = 0 X=0 Y=0 filename=/gis/puget.ive 1.276 : _writeNodeFile(/gis/puget.ive) 1.276 : vpb::access(/gis/puget.ive, W_OK)=-1 1.276 : vpb::access(/gis, W_OK)=0 1.279 : completed DataSet::writeDestination(/gis/puget.ive) 1.281 : Elapsed time = 1.281352 The other log file is like this, without many changes. Do you know if there are another log directory that can be more useful? Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22887#22887 ___ 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] [vpb] Problems using SSI Cluster Example
Hi, Samuel Jarque wrote: Hi, what OS/version are you using? Do all your nodes have access to the complete data set, i.e. can all see /gis? I'm using 2 computers with ubuntu 9.10, osg 2.8.0 and vpb 0.9.10. /gis have all permissions, so the 2 nodes can see it. Like the example, I have the same files on 2 nodes. node01:/gis$ ssh node02 ls /gis machinepool.txt ps_height_16k.tif ps_texture_16k.tif node01:/gis$ ls /gis machinepool.txt ps_height_16k.tif ps_texture_16k.tif OK, then first thing would be to figure out why osgdem segfaults. Let vpbmaster create the tasks and then try to manually run one of the osgdem commands through gdb/strace. Does osgviewer run on node2? To let a segfault dump core on ubuntu do this: ulimit -c unlimited then run osgdem jp Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22883#22883 ___ 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] SVN 10968 freetype plugin broken on OS X / MacPorts
Hi Robert, Could you have a look to see if you can get CMakeLists.txt configuration that adds in the path to where the headers are. If we can get it working then we may just have to revert the changes for Mingw and force Mingw users to fix there local install of Freetype. Another solution could be to add the necessary path for MinGW to the list of already existing paths (which seem to work for everyone) instead of modifying the existing paths. Additional include paths (that don't resolve to existing directories on your machine) are just ignored by the compiler anyways... But as I said when we started this, I'm perfectly fine with requiring a symlink for MinGW... We've pretty much established that MinGW's paths for freetype are broken at a more basic level anyways. 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] SVN 10968 freetype plugin broken on OS X / MacPorts
Hi JS, On Tue, Jan 19, 2010 at 2:11 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Could you have a look to see if you can get CMakeLists.txt configuration that adds in the path to where the headers are. If we can get it working then we may just have to revert the changes for Mingw and force Mingw users to fix there local install of Freetype. Another solution could be to add the necessary path for MinGW to the list of already existing paths (which seem to work for everyone) instead of modifying the existing paths. Additional include paths (that don't resolve to existing directories on your machine) are just ignored by the compiler anyways... Adding the path wouldn't resolve the problem. It's the removal of the freetype/ from the includes in the source files which is forcing the addition of the freetype/ and freetype2/ in the CMakeLists.txt. The only solution I can think of work right now would be to have #includefreetype2/h for Mingw and #includefreetype/h in the source files. However, such an approach would break if the Mingw include set up was fixed so is not something to go for. But as I said when we started this, I'm perfectly fine with requiring a symlink for MinGW... We've pretty much established that MinGW's paths for freetype are broken at a more basic level anyways. I think we might just have to go with this solution. I'll wait for feedback from Ulrich to see if the CMakeLists.txt can be amended for OSX to work once more. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] When and how to release an osg::Image
Hello, I am not sure if this has been asked before I tried a search on this forum but I think it is too specific so the search didn't come up with anything remotely close. Anyway my question is is there a safeway to release osg::Image after it has been uploaded to the card or better say into it's memory space. Deconstructors of osg::Image are all protected so I don't know how you could actually tell it unless I write my own memory manager for it, which is possible (but I would rather like to avoid that). The reason I ask is I've got quite a big volume stored in an osg::Image and I am running rather low on system resource memory the reason for that is it is actually kept twice in memory (the first time in osg::Image and the second time around due to OpenGL's / OS internal texture memory context mapping). So I rather would like to get rid of at least of one of them. But I don't know when and how since I just recently restarted using OSG. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22893#22893 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] When and how to release an osg::Image
Hello: the osg::Image object is referenced object and will be automatically deleted once the final ref count goes to 0. On the osg::Texture object you can specify if you want OSG to unref the image object after the image has been applied by using the method: setUnRefImageDataAfterApply I think that should be it. Take care Garrett On Jan 19, 2010, at 9:30 AM, Joachim Diepstraten wrote: Hello, I am not sure if this has been asked before I tried a search on this forum but I think it is too specific so the search didn't come up with anything remotely close. Anyway my question is is there a safeway to release osg::Image after it has been uploaded to the card or better say into it's memory space. Deconstructors of osg::Image are all protected so I don't know how you could actually tell it unless I write my own memory manager for it, which is possible (but I would rather like to avoid that). The reason I ask is I've got quite a big volume stored in an osg::Image and I am running rather low on system resource memory the reason for that is it is actually kept twice in memory (the first time in osg::Image and the second time around due to OpenGL's / OS internal texture memory context mapping). So I rather would like to get rid of at least of one of them. But I don't know when and how since I just recently restarted using OSG. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22893#22893 ___ 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] inactivate the camera manipulator
Thank you I resolve the problem using: m_Viewer-getCamera()-setViewMatrixAsLookAt(eye, centre, up); -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22896#22896 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Problems loading ac3d model
Hi, Recently we have upgraded from an ancient version of OSG to version 2.8.2. We are using an MFC application and everything seems to work fine with the upgrade except for the loading of AC3d models. The model shows up but it is unrecognizable. The only issues I have read about the AC3d reader is the texture clamping/repeating issue but none with the model not loading correctly at all. Even when I just use the osgviewerMFC example with a sample model from AC3d it shows up unrecognizable, the same as in our application. Has anyone encountered this issue before. Any help would be appreciated. I am new to the Openscene graph forums so maybe this issue has been addressed or the answer is obvious so I appologize before hand if that is the case. ... Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22897#22897 Attachments: http://forum.openscenegraph.org//files/modelloadingissue_113.bmp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Problems loading ac3d model
Hi, On Tuesday 19 January 2010, Steven D'Angelo wrote: Recently we have upgraded from an ancient version of OSG to version 2.8.2. We are using an MFC application and everything seems to work fine with the upgrade except for the loading of AC3d models. The model shows up but it is unrecognizable. The only issues I have read about the AC3d reader is the texture clamping/repeating issue but none with the model not loading correctly at all. Even when I just use the osgviewerMFC example with a sample model from AC3d it shows up unrecognizable, the same as in our application. Has anyone encountered this issue before. Any help would be appreciated. I am new to the Openscene graph forums so maybe this issue has been addressed or the answer is obvious so I appologize before hand if that is the case. ... I don't know of any issue. What I can tell is that flightgear uses magnitudes of correct displayed ac3d models in the scenery and for the aircraft models. So, what you encounter seems to be a corner case. So, either please provide the file you have problems with or a fix that makes that load well ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] When and how to release an osg::Image
Thank you for your reply Garret, That is very handy to know. Unfortunately it seems that none of the members in the osgVolume namespace expose this function (at least I couldn't find it), have something similar or are somehow related through inheritance to the osg::Texture class. So I guess I have to look at the osgVolume code itself and find where it actually generates the 3D texture and add this line? I am just slightly worried that this might cause unknown side effects! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22900#22900 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX plugin and previous OSG releases...
Unfortunately I still haven't solved my problem, but I found out something interesting: crashes happen when I execute osgviewer like this: osgviewer model.FBX but osgviewer doesn't crash when executed like this: osgviewer .\model.FBX i.e. no crashes when I provide an absolute or relative path for the FBX model. The model.FBX file is in the same dir of osgviewer and contains embedded textures. I noticed that trying to open FBX files with embedded textures implies the creation of a new directory with the same name of the FBX file but with the extension .fbm...in that directory the FBX plugin extracts the actual textures files (.jpg, and so on...). Since the crash is present only when using textured models, I wonder if there could be a bug in the way those textures are tried to load, maybe simply using the file name (instead of a relative\absolute path) yelds some strange behaviours and let osgviewer (or the plugin itself) to crash. Regards. Alessandro On Mon, Jan 18, 2010 at 10:15 PM, Ümit Uzun umituzu...@gmail.com wrote: I have had same problem on different plugin while loading my model on runtime. After that I reliazed that version inconsistent with target plugin with my OSG. After recompilation problem disapperead. Ümit Uzun 2010/1/18 alessandro terenzi a.tere...@gmail.com I will try your suggestion Ümit...by the way, did you have exactly the same problem o mine? I mean no crashes if the FBX model contains no textures whereas crashes if the model contains some textures? Thanks. Alessandro On Mon, Jan 18, 2010 at 8:29 PM, Ümit Uzun umituzu...@gmail.com wrote: Hi Alessandro, Maybe problem in osg plugin interfere. So you can't see from dependency walker. As you see osg plugins aren,t named with their version like osg61 So they can be used which doen,t belong your exiting osg core version. Most probably plugin inteference is your problem. Delete all plugin's on your system(all plugins which you can reach from your Path Environment Variables) and rebuild with your existing OSG version again. This would solve your problem. Regards. Ümit Uzun 2010/1/18 Sukender suky0...@free.fr Arg! Please avoid sending email addresses in clear (because of harvesters)... Anyway, I'll mmerge your changes ASAP and give you feedback. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 18 Jan 2010 19:19:09 +0100, Michael Platings mplati...@pixelpower.com a écrit: I sent you a few emails (suky0...@free.fr) but it seems you don't receive them if I email you directly! Let me know if there are any further changes you'd like to make on top of my alterations. Cheers -Michael -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender Sent: 18 January 2010 16:30 To: OpenSceneGraph Users Subject: Re: [osg-users] FBX plugin and previous OSG releases... Forget about my message, I just got my answer on osg-submissions! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Michael, Did you include the sources I sent to you recently? It seems you haven't answered my mails... Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - alessandro terenzi a.tere...@gmail.com a écrit : Thank you, I tried both the zip file got from the osg-submission forum and the zip of previous mail but osgviewer still crashes if the FBX model has textures. I just can think only about sending you my zip and model and let you see if the problem is there also for you. Regards. Alessandro On Mon, Jan 18, 2010 at 5:16 PM, Michael Platings mplati...@pixelpower.comwrote: Hi Alessandro, here's the latest version of the plugin for you. Cheers -Michael -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *alessandro terenzi *Sent:* 18 January 2010 15:34 *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] FBX plugin and previous OSG releases... Ok, I'm going to try...but I've never downloaded code from osg-submissions, actually I don't know if I need an account...I've looked at the archive but could not find source code, just messages. Maybe you could zip and send me the latest submission of the plugin? Thank you. Kind Regards. Alessandro On Mon, Jan 18, 2010 at 4:09 PM, Sukender suky0...@free.fr wrote: I think it's maybe because of a problem in the code. You really should try the FBX plugin posted on osg-submissions to check if it behaves the same or not. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - alessandro terenzi
Re: [osg-users] [osgPlugins] Problems loading ac3d model
Hi Steven, Could you try osgviewer with one of the problem models. Could you also post a problem model online so that others may test it. Cheers, Robert. On Tue, Jan 19, 2010 at 3:49 PM, Steven D'Angelo sdang...@dhpconsultants.com wrote: Hi, Recently we have upgraded from an ancient version of OSG to version 2.8.2. We are using an MFC application and everything seems to work fine with the upgrade except for the loading of AC3d models. The model shows up but it is unrecognizable. The only issues I have read about the AC3d reader is the texture clamping/repeating issue but none with the model not loading correctly at all. Even when I just use the osgviewerMFC example with a sample model from AC3d it shows up unrecognizable, the same as in our application. Has anyone encountered this issue before. Any help would be appreciated. I am new to the Openscene graph forums so maybe this issue has been addressed or the answer is obvious so I appologize before hand if that is the case. ... Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22897#22897 Attachments: http://forum.openscenegraph.org//files/modelloadingissue_113.bmp ___ 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] [osgPlugins] Problems loading ac3d model
Hi, It seems as though the issue is a graphics card issue. My coworker ran both our project and the osgViewerMFC example and they ran perfectly with all models. Our machines are identical except for the graphics card. Mine is an NVidea 8600GT and his is an ATI card.I am going to download the latest drivers for my card and see if that fixes the issue. ... Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22906#22906 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fwd: DrawPixels Cull settings
Anyone have any thoughts as to why switching from COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES to COMPUTE_NEAR_FAR_USING_PRIMITIVES would stop DrawPixels from working. My initial thought was that the near far culling distance were causing the problem but I can get the same near far distances from both approaches. My next thought was that the object was not being drawn for some other reason but it would appear that the drawImplementation is being called in both situations. Any thoughts as to where I might look would be appreciated. Matt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Problems loading ac3d model
Hi, Just as a report, updating the drivers did infact fix the issue. Before I updated the driver I realized that the other differance between my non working machine and my co-workers was the fact that I was running with 2 monitors. I turned off the dual view mode and the models displayed correctly. I then turned it back on and the models again showed disfigured. After updating the driver however the models load in dual monitor mode or any other mode. I appreciate the quick responses. ;) Thanks again, Steve D'Angelo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22908#22908 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FFmpeg and sound
Robert Osfield wrote: OpenAL and other dedicated audio libs would certainly be a better bet for handling multiple videos. We just need to code up such a solution. Hi, Robert, If I were to implement an OpenAL AudioSink, I'd imagine you'd want it to be a plugin (so the OSG can still be compiled without OpenAL). How would you envision this plugin being tied in to the core?I started on an OpenAL plugin last week, but I hit a wall when trying to figure out how to do this. The ReaderWriter interface works great for file-based plugins, but the AudioSink seems like it's different enough that a new kind of interface is needed. Do you agree? If so, would this interface also live in osgDB? Would it be part of Registry, like ReaderWriter, DotOsgWrapper, etc.? Any other thoughts? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Separating draw and swapbuffers
Hello, Robert, I noticed that when using the osgviewer, the draw and swapbuffers operations take place within the same function call, ViewerBase::renderingTraversals(). Before, with Producer, I can call Producer::Camera::frame(false) to perform draw operation without swapping the buffers, and do swapbuffers later explicitly. This way I can insert my own vertical sync code or some other process between draw and swapbuffers. Is there already something similar provided for doing this with osgviewer? The only sample code that calls swapbuffers explicitly is osgSlice but that program doesn't use osgviewer, rather it creates sceneView and graphicsContext directly. I'm hesitant to break up ViewerBase::renderingTraversals() on my own since there are thread sync related code around the loop that calls GraphicsContext::runOperations() and the loop that calls GraphicsContext::swapBuffers(), and I'm worried about any implications of interrupting it. Thanks, Yefei ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OT joining line segments to polyline
I have a bunch of line segments (generated by cutting a mesh) that I need to join together into a polyline. Defining the optimal polyline as the shortest ordering of the points. Is there any better algorithm (or library) for stitching the line segments - other than niavely searching all other segments for the end point nearest the current line. Naturally in the real world there might be gaps and there is rounding error. At least in 2d it seems that this must be a common contour line problem? Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22912#22912 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: DrawPixels Cull settings
Matt Franklin wrote: Anyone have any thoughts as to why switching from COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES to COMPUTE_NEAR_FAR_USING_PRIMITIVES would stop DrawPixels from working. My initial thought was that the near far culling distance were causing the problem but I can get the same near far distances from both approaches. My next thought was that the object was not being drawn for some other reason but it would appear that the drawImplementation is being called in both situations. Any thoughts as to where I might look would be appreciated. Check your glRasterPos. I believe there's an OpenGL query to test for a valid raster position. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Separating draw and swapbuffers
Hi, I think there was a suibmission years ago, but it wasn't included into mainstream code. I would be interested too in such an interface. :) Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22914#22914 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Separating draw and swapbuffers
Hi, He, Yefei wrote: Hello, Robert, I noticed that when using the osgviewer, the draw and swapbuffers operations take place within the same function call, ViewerBase::renderingTraversals(). Before, with Producer, I can call Producer::Camera::frame(false) to perform draw operation without swapping the buffers, and do swapbuffers later explicitly. This way I can insert my own vertical sync code or some other process between draw and swapbuffers. Is there already something similar provided for doing this with osgviewer? The only sample code that calls swapbuffers explicitly is osgSlice but that program doesn't use osgviewer, rather it creates sceneView and graphicsContext directly. I'm hesitant to break up ViewerBase::renderingTraversals() on my own since there are thread sync related code around the loop that calls GraphicsContext::runOperations() and the loop that calls GraphicsContext::swapBuffers(), and I'm worried about any implications of interrupting it. I'm not sure, but doesn't swapBuffers just call some other windowing implementation swapbuffersimplementation function? Maybe you can override that? jp Thanks, Yefei ___ 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
