Re: [osg-users] OSG within firebreath?
On 13/03/2012 19.04, Chris Hanson wrote: Anyone have any code to share for browsers internet explorer, firefox and any others on other systems other than windows? If not ill get my head down, pretty good at this sort of stuff. I would think the osg4web work is the best place to start as it claims: Our latest work can be viewed here: http://www.aquaepatavinae.lettere.unipd.it/portale/?page_id=2174 unfortunately is just italian and german, you should get the plugin for widows http://147.162.44.41/portale/wp-content/extra/osg4web-setup.exe or mac http://147.162.44.41/portale/wp-content/extra/OSG4Web.pkg this is not using Firebreath, but we would really like here is a tentative project of Firebreath + OSG under Linux https://code.launchpad.net/~osg4web/osg4weblinux/main It is not really up to date... it runs OSG within a separate process, using gtk_drawing_area to draw inside the plugin window browser The window code, more complex and, unfortunately, not based on firebreath, use similar idea: OSG run in a separate process This tecnique can not be used on OSX If someone is intersted, we can give more detail Currently the supported browsers are Firefox and IE and the OS platform is Windows XP-Vista. Nevertheless, most part of the code is OS neutral. Yes, it isusing Firebreath should enhance prortability by going also cross-browser HTH Luigi -- Luigi Calori SuperComputing Applications and Innovation Department CINECA - via Magnanelli, 6/3, 40033 Casalecchio di Reno (Bologna) - ITALY Tel: +39 051 6171509 Fax: +39 051 6132198 hpc.cineca.it ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD for shared nodes
On 05/07/2011 20.32, Sebastian Messerschmidt wrote: Am 05.07.2011 17:42, schrieb Chris 'Xenon' Hanson: On 7/5/2011 5:50 AM, Sebastian Messerschmidt wrote: Hi, It seems like referencing e.g. tree1 multiple times in the graph creates multiple render instances instead of sharing the node. So loading the master.ive almost certainly consumes all available memory. Is there an error in my thinking, that the nodes for tree1 ... treeN can be shared whilst being under a pagedLOD? For some reason I thought there was already some sort of object-loader sharing cache. Okay, sorry for the noise. I've found a topic which already covers this topic. For sharing nodes you'll have to setup the viewer to explicitly use shared nodes. This way I've managed to display a huge database with some hotspots Interesting... do you mind sharing the option / setup needed? we could have similar problems Thanks -- Luigi Calori SuperComputing Applications and Innovation Department CINECA - via Magnanelli, 6/3, 40033 Casalecchio di Reno (Bologna) - ITALY Tel: +39 051 6171509 Fax: +39 051 6132198 hpc.cineca.it ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG plugin for browsers
On 04/09/2011 10:42 AM, Thibault Genessay wrote: Hi all, First, thanks Chris, Peter, Luigi and Leo for the replies. I now have a better overview of the problem. I had not noticed that FireBreath was cross-platform, and will give your source code links a shot as soon as I have time. In the meantime, I am trying FireBreath, and will post my progress here. If you are trying Firebreath on Linux, my code on Launchpad needs some patching on the FireBreath side, at least the 1.4.2 release, As soon as I have time, I' ll do a clone on Firebreath GitHub site, let me knowif you need info Regards Luigi Thanks again for your input Cheers Thibault ___ 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] How to get a working 64 bit build on Snow Leopard?
Hi everybody, I' m trying to build OSG under Mac OS X 10.6.4 using 64 bit Xcode based build (cmake generated) The compilation goes well apart from QT problems. when running osgviewer I got the same error reported in this thread: View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows I set up cmake as suggested: OSG_WINDOWING_SYSTEM to Cocoa and OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX to imageio Someone has succeeded in this? I am really a complete newbie on OSX ... sigh I had some system reporting: System Version:Mac OS X 10.6.4 (10F569) Kernel Version:Darwin 10.4.0 Boot Volume: Macintosh HD 106 Boot Mode: Normal Computer Name: Luigi Calori’s MacBook User Name: OSGVPlugin Devel (osgvplugin) Secure Virtual Memory: Enabled 64-bit Kernel and Extensions: No can the last line have something to do with the error? I thought snow leopard was ready for 64 development, do I need to set something to allow running 64 bits app? Really thanks a lot in advance On 03/02/2010 17.38, Stephan Maximilian Huber wrote: Am 03.02.10 16:13, schrieb Butler, Lee Mr CIV USA USAMC: I'm trying to get a good 64bit build on Snow Leopard. What I've done so far: Per some other forum comments, I've commented out the build of quicktime components in CMakeLists.txt. No need for that, see below. When running ccmake, I've set the architecture to x86_64. This resulted in a clean compile, but osgviewer could not run. It complained it couldn't find any windowing system to use. Can anyone tell me what steps are necessary? I've got an application I really need to get running 64bit on the Mac. It builds and works fine elsewhere or in 32bit mode on the Mac. Make sure you have set OSG_WINDOWING_SYSTEM to Cocoa and OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX to imageio in cmake, this should take care of everything. Generate your project and rebuild. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Osg with 64Bit (dependency)
Hi Anders much better late than never Thanks I' ll look at your solution and try to use your CMakeLists I see you provide the sources as an integrated stuff... does it mean you did not had to patch the original source? If not, I' ll try to extract patches from your sources against original sources to uniform them in my ExternalPackage based cmake packages available at http://3d.cineca.it/storage/bazaar_repo/CmakeDeps/lib/wt/ I see you have used selected boost 1_35_0 while there is a 1.41 ... Is this a requirement of collada? In that case, is it the unpatched version available at http://sourceforge.net/projects/boost/files/boost/1.35.0/ ? Thanks again Luigi Anders Backman wrote: Late late late. But here is my prebuilt 64/32bit dependency package. Including the source/cmakelists.txt files for building it. Boost included, however only system and filesystem is built. Same version as required by Collada 2.1. http://www.vrlab.umu.se/public/ Cheers, Anders On Thu, Feb 25, 2010 at 7:48 PM, D.J. Caldwell dlcaldwel...@gmail.com mailto:dlcaldwel...@gmail.com wrote: Sorry; what I meant was, boost is experimenting using cmake to build boost, as an alternative to their boost build system. Hope this helps... D.J. On Thu, Feb 25, 2010 at 1:46 PM, D.J. Caldwell dlcaldwel...@gmail.com mailto:dlcaldwel...@gmail.com wrote: Maybe slightly off topic, but somewhat related: boost is currently experimenting/working on a cmake build alternative for their system. Perhaps this could help (confirm) your setup(s)? Keep us all posted on the 64bit front... Thanks... D.J. On Thu, Feb 25, 2010 at 4:19 AM, Morné Pistorius mpistorius@googlemail.com mailto:mpistorius@googlemail.com wrote: Excellent news! Thank you, that will be really helpful! Regards, Morne On Wed, Feb 24, 2010 at 7:49 PM, Anders Backman ande...@cs.umu.se mailto:ande...@cs.umu.se wrote: I managed to build what I need in 64bit. My take on it was to cmakeify them all. Collada, boost (only libsystem, libfilesystem), (jpeg, png and zlib was alredy cmakified.) There are a few which Im not interested in, including jasper, tiff and a few more. I can certainly pack this into a zip including the bin/lib/include content. I'll see if I get it done tomorrow. Took a while though to get everything to build, which everyone (including the Collada team would open their eyes and spot CMake. /A On Wed, Feb 24, 2010 at 6:41 PM, Luigi Calori l.cal...@cineca.it mailto:l.cal...@cineca.it wrote: Hi, I ' m building a somehow cmaked, static version of the (currently basic) osg dependencies. I' m trying also to make it extensible by keeping patch and compiler options in separate folders. I attach a zip of my current repo: try to build the Assemblies/test2 folder with latest 2.8 cmake. It should work also for win64 i tested with msvc9 32 Hope it helps Luigi Morné Pistorius wrote: Hi Anders, How did you get on with this? Were you able to build the third party dependencies for Win64? A third party package, even with just the basic dependencies to build most of OSG, would really be helpful. I was about to start building my own when I found this thread, and hoped you had beat me to it! :) Cheers, Morne On Wed, Feb 10, 2010 at 8:45 AM, Anders Backman ande...@cs.umu.se mailto:ande...@cs.umu.se wrote: Hi all. Looong time no see. Im currently trying to build OSG on 64bit under windows (VS2009). Getting all the dependencies over to 64bit is apain. I did a quick search through forum/mail, and it seems that not many does this. Is there ANYONE with a prebuilt package including Collada (with boost, pcre, libxml), jpeg, png, zlib for 64bit windows? The Cmake:d versions of jpeg, zlib, png was certainly a big help. But before I dig into this, perhaps someone has a prebuilt package? -- /Anders ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users
Re: [osg-users] [build] How do I successfully deploy a OSG app?
Gordon Tomlinson wrote:
You don't need static builds to use OSG on another machine
You say it does not work ...HOW does NOT work ?,
how are you installing on another machine ?
Yes you do need the correctly MSVC re-distributable to be installed as part
of your applications installation process
you can also deploy all in the same folder: your exec + all the bin
folder resulted from OSG install step + the neede MSVC stuff:
you can obtain it by adding this patch to the main OSG CMakeLists.txt:
@@ -243,14 +238,6 @@
SET(CMAKE_EXE_LINKER_FLAGS_DEBUG /debug /INCREMENTAL:NO)
ENDIF(NOT OSG_MSVC_DEBUG_INCREMENTAL_LINK)
ENDIF()
-IF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
-OPTION(OSG_MSVC_INSTALL_MFC_LIBRARIES Set to ON to include
system libraries in install dir OFF)
-MARK_AS_ADVANCED(OSG_MSVC_INSTALL_MFC_LIBRARIES)
-IF(OSG_MSVC_INSTALL_MFC_LIBRARIES)
-SET(CMAKE_INSTALL_MFC_LIBRARIES 1)
-INCLUDE(InstallRequiredSystemLibraries)
-ENDIF(OSG_MSVC_INSTALL_MFC_LIBRARIES)
- ENDIF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
ENDIF(MSVC)
ENDIF(WIN32)
then build osg with
cd osg_build
cmake -DCMAKE_INSTALL_PREFIX:PATH=your OSG install folder
-DOSG_MSVC_INSTALL_MFC_LIBRARIES:BOOL=ON osg source folder
cmake --build . --config Release
then you should have in your OSG install folder/bin all you need to
add to your exe to make it deployable
HTH
Luigi
You need to ensure that the MSVC re-distributable's and the OSG bin\dlls are
in your path and that your install all the OSG dlls including the plugin-in
directory etc
__
Gordon Tomlinson
gor...@gordontomlinson.com
www.photographybyGordon.com
www.vis-sim.com
www.gordontomlinson.com
IM: gordon3db...@3dscenegraph.com
__
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mas Oug
Sent: Friday, March 12, 2010 3:48 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] [build] How do I successfully deploy a OSG app?
How do we deploy an OSG app that we compiled in VC++ 2008?
Because simply the .exe will not work on other computers (naturally).
I've tried using VC redist. and friends, but with no avail...
I have heard of static linking, but how would that work?
I would greatly appreciate any helpful response!
Thanks!
-Masoug
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25595#25595
___
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] Could not find plugin on Mac OS X 10.6.2
Hi Tobias, I do not know at all OSG, the Cmake build is structured to search at configure time (cmake-gui or ccmake or cmake-Dpreset variable) the needed plugin dependencies and include plugin code if the dependencies is found. The search code for dependencies are either in CMakeModules/Findxxx.cmake or in the cmake root/Modules folder It seem to me that the user is not currently able to configure at config time which plugin to build. Probably the easiest thing in your case would be to edit the CMakeModules/FindQuickTime.cmake to make it fail in your situation (adding an exception for OSX and 64 bit) This patch has probably some chances to be accepted. Otherwise, a more general solution, would be to insert some form of user CMake configurability. One of the simplest think would be to allow to override the CMAKE_MODULE_PATH. So you do exactly the same change to FindQuickTime.cmake but not need to change the svn copy, just put it in your module override folder and configure with cmake -DCMAKE_MODULE_PATH:PATH=your override module folder I have tested module overriding in windows and Linux and it seem to work. in order to activate module override, a simple patch to master CMakeLists.txt is needed If I am not alone in asking for module override, I' ll send a submission request HTH Luigi Tobias Duckworth wrote Hello again, Thanks for your prompt response. Yes disabling Quicktime is fine for my purposes - However, from what I can work out the cleanest way to achieve this will be to get generated XCode projects, then I can pick and choose what gets built - I don't really want to hack the Makefiles and there doesn't appear to be a way to disable the Quicktime build from CMake. I look forward to hearing from 'the OSX guys', and hope that in the future I can provide similar support to others. I'd be happy to update the OSX build instructions for example, once I have managed to build. Cheers, Tobias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25332#25332 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Scriptable Plugin for Firefox
Rafa Gaitan wrote: Hi Luigi, On Thu, Mar 4, 2010 at 1:26 AM, Luigi Calori l.cal...@cineca.it wrote: Great to hear there is someone else who is going along this (tiring) path... I had the impression that web apps was a topic with little appealing in this community: maybe after Google Earth plugin,O3D, Unity and WebGL web 3d will be considered even here Is your project going to be released on open source license? Yes, we are planning to made it public with the OSGPL license. We also want to submit it as an OSG example, so others could improve it and make the port to other platforms, or even do a kind of NodeKit for web thoughts?. Well... i have no idea of how you have arranged the build system, I have used cmake for almost all the step: configuring: (finding needed deps ), building, some testing and the packing (xpi building). So my setup is more a kind of an external project, using OSG.. I am not sure such a project could be packed as an OSG example In that case, I' ll be glad to cooperate. Nice! :) We have worked on ffox plugin since quite a long time, mainly on windows, as this platform is by far the most attractive for web browser app,: both for number of users as well as for ease of deployment (building cross distrib linux binaries was quite difficult sic) did not found an easy way of building distribution neutral linux binaries and it seem even you got some problems, at least on my amd64 kububtu 9, it does not seem to work... sic We only tested on ubuntu 32 bits, not a 64 bits build yet. Yes, deploy a firefox plugin on linux is a crazy task, we deployed the linux version with OSG(2.9.7) compiled in static, and it gave us lots of problems (OSG files are not able to load, and so on), but at least we have a first version working. In my tests I used standard .so deployment, as in windows... I have an old version deployed at http://3d.cineca.it/storage/OSG4Web_test/Linux/test.html Being it old, it has set up the max version in the install set up to 3.0.x, I' ll let you know as soon as I have a newer one. Did you used npruntime for javascript wrapping? When we started our www,virtualrome.it effort, npruntime was not available, but now it seem the right way to go. Leo could answer you better to this question! :). I'm waiting... I see your plugin is running in the same process as FFox, this means that a crash on the plugin crashes also FFx itself. For this reason we are experimenting with separate process (a la Google Earth plugin ) mmh interesting, I'll tell Leo study this too. You can see example here: http://muvi.cineca.it/3d/sites/muvi/3d.html?Plug=simple_runprocessExe=osg_embed_viewer_2Core=FunCoreURL=http://muvi.cineca.it/3d/sites/muvi/model_30_new/top_ti_eo.ive click on Mostra 3d click on Install osg4web_t...@cineca.it http://3d.cineca.it/storage/OSG4Web_test/downloads/Windows/update_osg4web_t...@cineca.it_0.0.1.3_.xpi click on Allow in upper right tab click on install now in the extension popup it should download the extension OSG Viewer Firefox Plugin 0.0.1.3 I think it would really be good to join effort on this topic. On my side, I keep my work in a bazaar repo: if interested, check it out doing bzr checkout http://3d.cineca.it/storage/bazaar_repo/BrowserEmbed/test_merge/ Thank you very much, I also think joining efforts will be a good path, but I also think if we upload a version to OSG repository then comunity will also help us, of course if Robert agree with us. I think we could try to leverage some Distrributed Code Revision Tools (Git, Mercurial, Bazaar) for this stage of this project: It seem to me that the current policy for OSG submission are too much cumbersome, and i do not think we need to change anything in OSG, just use it In the next days we will prepare a osgfirefox example to submit as a basis, then we can think in a more generic nodekit for web, so other browser could be included. In this regard I have found really interesting the FireBreath project ( http://code.google.com/p/firebreath/ ) I have not really used it yet, just did some early testing, and it seem able to provide good framework for building cross-browser support under windows And it is CMake based too ;-) Best regards Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Scriptable Plugin for Firefox
Leonardo Salom Muñoz wrote: Hi all, I am glad to announce that we have published a preliminary version of our scriptable plugin for Firefox[1]. We are currently developing a Firefox plugin which shows 3D objects in a web. It uses OpenSceneGraph to set up the render canvas. Moreover the plugin also features scripting capacities based on NPAPI technology that allow access to the plugin functions and variables from web application itself. Great to hear there is someone else who is going along this (tiring) path... I had the impression that web apps was a topic with little appealing in this community: maybe after Google Earth plugin,O3D, Unity and WebGL web 3d will be considered even here Is your project going to be released on open source license? In that case, I' ll be glad to cooperate. We have worked on ffox plugin since quite a long time, mainly on windows, as this platform is by far the most attractive for web browser app,: both for number of users as well as for ease of deployment (building cross distrib linux binaries was quite difficult sic) did not found an easy way of building distribution neutral linux binaries and it seem even you got some problems, at least on my amd64 kububtu 9, it does not seem to work... sic Did you used npruntime for javascript wrapping? When we started our www,virtualrome.it effort, npruntime was not available, but now it seem the right way to go. We run some experiment on Linux porting but not done scripting yet. I see your plugin is running in the same process as FFox, this means that a crash on the plugin crashes also FFx itself. For this reason we are experimenting with separate process (a la Google Earth plugin ) You can see example here: http://muvi.cineca.it/3d/sites/muvi/3d.html?Plug=simple_runprocessExe=osg_embed_viewer_2Core=FunCoreURL=http://muvi.cineca.it/3d/sites/muvi/model_30_new/top_ti_eo.ive click on Mostra 3d click on Install osg4web_t...@cineca.it http://3d.cineca.it/storage/OSG4Web_test/downloads/Windows/update_osg4web_t...@cineca.it_0.0.1.3_.xpi click on Allow in upper right tab click on install now in the extension popup it should download the extension OSG Viewer Firefox Plugin 0.0.1.3 I think it would really be good to join effort on this topic. On my side, I keep my work in a bazaar repo: if interested, check it out doing bzr checkout http://3d.cineca.it/storage/bazaar_repo/BrowserEmbed/test_merge/ Regards Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Easiest way to bundle an OSG app
Torben Dannhauer wrote: Hi, to deliver my software, I use MS Visual Studio setup projekt. I add my complete osg binary folder (of course only release build) to my project as well as my application binary to the project. The dependencies regarding the compiler etc. are solved by VS. If you are building your application project with CMake, you could probably just add SET(CMAKE_INSTALL_MFC_LIBRARIES 1) INCLUDE(InstallRequiredSystemLibraries) Then you should get required MSxx dll installed side your app, so you do not require runtime pachage to be installed (a thing that I really hate to be forced to do) For my Firefox extension, As Torben do, I bundle all osg dll + plugins + deps + system libs as a bin folder. Not know how it goes with wxwidgets, if you can build it statically, then you do not need to include it. For this reason I build jpeg,png,zip,curl,freetype statically, so I do not have to include them. I have a CMake project to build that stuff based on external project. The only problem I got, (on some win32 setups) are related to OSG plugins residing in a separate folder. Sometimes has happened that plugins were not able to load as they searched MSVC dll's in their folder, even if they were already loaded (real mystery .). I worked around by putting all the plugin dll in the same bin folder Why do I add my complete large binary folder? Well, I can't foresee which models my clients will use, so I deliver all plugins. Maybe this is'nt the best solution, but it's fast to build, easy to use and thanks to broadband, the transfer of the installer is fast enough. Completely agreed Hope it helps Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Easiest way to bundle an OSG app
Tomlinson, Gordon wrote: One caveat not all the 3rdparty plugins and possible dependencies are LGPL and thus don't allow static linking Not sure about legal issues, but it seem to me that linking restrictions apply only to closed source projects: if you distribute the source you can use the linking you want, or am i wrong? Regards Luigi Gordon Tomlinson Product Manager 3d Technology Project Wyvern Overwatch(r) An Operating Unit of Textron Systems -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Beckett Sent: Monday, March 01, 2010 12:29 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Easiest way to bundle an OSG app Not know how it goes with wxwidgets, if you can build it statically, then you do not need to include it. You can do either, it's LGPL + static allowed. If you use dll's you have the option of only shipping the parts you use - so leaving out say database or webbrowser components. The other advantage of using dynmaic libs is you can update your app more easily - you only have to send a new, relatively small, .exe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25015#25015 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ 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] Improving the OpenSceneGraph project efficiency and balance
Robert Osfield wrote: Hi Mathieu et. al, On Fri, Feb 26, 2010 at 12:34 PM, Mathieu Marache mathieu.mara...@gmail.com mailto:mathieu.mara...@gmail.com wrote: Mercurial had a head start but now things are even in terms of tools, both command line and graphical. Windows : - command line with msysgit : http://msysgit.googlecode.com/files/Git-1.6.5.1-preview20091022.exe - explorer integration with TortoiseGit : http://code.google.com/p/tortoisegit/downloads/list Mac : - git : http://code.google.com/p/git-osx-installer/downloads/list - gitk : comes in with git and is a graphical local repository browser - GitX (my fav app) : http://gitx.frim.nl/ Could Windows and Mac users have a play with these tools. It'd be good to get feedback on how you get on with the various tools for Git, Mercurial and Subversion and how they all compare with each other. Here is a (long) Wikipedia review http://en.wikipedia.org/wiki/Comparison_of_revision_control_software I personally have use Bazaar on Windows and Linux, I mainly choose it for simplicity and because it allows providing repo over http with really minimal infrastructure (plain http). Obviously even Bazaar claim to be the better : http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html It seem it can interoperate well with other and work also as a subversion client. http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html just my 0.1 cents Luigi Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Osg with 64Bit (dependency)
Anders Backman wrote: I managed to build what I need in 64bit. My take on it was to cmakeify them all. Collada, boost (only libsystem, libfilesystem), (jpeg, png and zlib was alredy cmakified.) There are a few which Im not interested in, including jasper, tiff and a few more. I can certainly pack this into a zip including the bin/lib/include content. I'll see if I get it done tomorrow. Took a while though to get everything to build, which everyone (including the Collada team would open their eyes and spot CMake. WOW nice to hear you managed to build also Collada with CMake! that was my next step if you have alrady done,less work!! I think this stuff should be pubblished somewhere to help other and to share effort, did you build static or shared? If the build id cross platform, we could also send the patches upstream: I ' ve got to do some patching to build... as you can see from the zip content. Let us know when you are ready to shre your work and if you agree to set up a repo for that. Thanks Luigi /A On Wed, Feb 24, 2010 at 6:41 PM, Luigi Calori l.cal...@cineca.it mailto:l.cal...@cineca.it wrote: Hi, I ' m building a somehow cmaked, static version of the (currently basic) osg dependencies. I' m trying also to make it extensible by keeping patch and compiler options in separate folders. I attach a zip of my current repo: try to build the Assemblies/test2 folder with latest 2.8 cmake. It should work also for win64 i tested with msvc9 32 Hope it helps Luigi Morné Pistorius wrote: Hi Anders, How did you get on with this? Were you able to build the third party dependencies for Win64? A third party package, even with just the basic dependencies to build most of OSG, would really be helpful. I was about to start building my own when I found this thread, and hoped you had beat me to it! :) Cheers, Morne On Wed, Feb 10, 2010 at 8:45 AM, Anders Backman ande...@cs.umu.se mailto:ande...@cs.umu.se wrote: Hi all. Looong time no see. Im currently trying to build OSG on 64bit under windows (VS2009). Getting all the dependencies over to 64bit is apain. I did a quick search through forum/mail, and it seems that not many does this. Is there ANYONE with a prebuilt package including Collada (with boost, pcre, libxml), jpeg, png, zlib for 64bit windows? The Cmake:d versions of jpeg, zlib, png was certainly a big help. But before I dig into this, perhaps someone has a prebuilt package? -- /Anders ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- ___ osg-users mailing list osg-users@lists.openscenegraph.org 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] Improving the OpenSceneGraph project efficiency andbalance
Luc Frauciel wrote:
How would you go about setting up automatic testing of the examples?
What could you test here and how would you do it?
--
Philip Lowman
Hi,
An idea could be to mimic the way VTK handle that question (
http://www.vtk.org)
They generate a bunch of reference automatic screenshots through CTest and
then do image comparisons.
I admit that the initial setup seems quite high but I don't see any other
way to do automatic testing of a graphic library.
Luc
That was also what I would like to suggest.
I remember there was once a way to force osgviewer to run for a
predefined number of frames and also to snapshot the image.
If that behaviour would be available at viewer level, all the examples
based on osgviewer could be turned into test.
The common testing parts could be wrapped in the common setup_example
cmake macro,
all testing specific stuff such as command line params, reference
snapshot images could be set up in a subfolder of the example (that
could be tested on several data)
This should be put in separate targets and, probably better, a separate
dependent project
Regarding CMake system:
1) macro could be easily be made user configurable (user could redefine
any file in CMakeModules) by changing line 63 of main CMakeLists.txt to:
SET(CMAKE_MODULE_PATH
${CMAKE_MODULE_PATH};${OpenSceneGraph_SOURCE_DIR}/CMakeModules)
I think it should not harm anyone, but not tested on all platforms and
on all (old) version of CMake
2) Today CMake project has offically switched to Git
http://cmake.org/Wiki/CMake/Git#Resources I had a look at progit book
and it could be a useful start to make up ideas for set up a better
hierarchical dev workflow http://progit.org/book/ch5-1.html
I did not personally used Git, just had some experience with Bazaar
https://launchpad.net/bzr , that integrates with subversion
http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion?highlight=%28subversion%29
as Git does http://progit.org/book/ch8-1.html
Philip Lowman phi...@yhbt.com
Envoyé par : osg-users-boun...@lists.openscenegraph.org
23/02/2010 12:17
Veuillez répondre à
OpenSceneGraph Users osg-users@lists.openscenegraph.org
A
OpenSceneGraph Users osg-users@lists.openscenegraph.org
cc
Objet
Re: [osg-users] Improving the OpenSceneGraph project efficiency and
balance
On Tue, Feb 23, 2010 at 4:32 AM, Tim Moore timoor...@gmail.com wrote:
Is there a critical mass of power users willing to use an experimental
tree?
I'm not sure. Even if not, automated testing of the examples would help
verify any OSG tree.
How would you go about setting up automatic testing of the examples?
What could you test here and how would you do it?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 9 2008 3rd Party
Jean-Sébastien Guay wrote: Maintaining a package with recent and known working dependencies for all plugins is probably more than anyone is willing to do, especially considering that some plugins are probably not used by many people... What about having a repo of working recipes where people who have the itch and have successfully scratched can share the recipe in a somehow formalized way. In my previous mail, I' m suggesting use of Cmake external projects as a way to formalize download,unpack,patch,configure,make and install we could also think for simple plugins, some high level read-write testing based on osgconv. In some cases, you can't redistribute binaries of dependencies (the QuickTime SDK comes to mind, each person (or company) needs to download it from Apple's site). Keep that in mind if you don't want to get unpleasant e-mails... What about automating the download+install process? would it be still illegal? Thanks in advance for any comments-thougts-suggestions Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How do I compile an OSG app, so that it can be run without the OSG installed?
Hi Agos. Using static linking is one option, another one is just put your app and the osg dll in the same folder. I think the default for win app is to search dll in the same folder of the main app. If you do not want to mess with MS redistributable package, You should also put the runtime dlls in the same folder as well. (I 'm compiling with VS9 so the names are mfc90.dll,msvcr90.dll ) If you are using CMake for your project, just add INCLUDE(InstallRequiredSystemLibraries) and then run the install target, all the needed ms libraries should get copied in your install bin dir I found some problems on VS9 with current layout of plugins that stay in a separate folder, they were not finding the runtime, so I resorted to just put all the plugins in the same application folder I am using this way to distribute osg based Firefox extension. Hope it helps P.S. If you or someone else can point me to better solution for non-static windows distribution, it will be rally welcome. Thanks Luigi Agos Silva wrote: Hi there. How do I compile an OSG app, so that it can be run, on another computer, without the OSG installed (dlls and libs)? I just want to be able to send my app, for instance, via email, so that someone may run or test it on another pc, even without having OSG installed on it. I remember doing it, under unix, some 15 years ago, with C, with my own libraries, but I've never tried it under Windows. Thank you in advance. Agos -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22660#22660 ___ 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] How to integrate OSG with java (to make an applet)
If you are interested in just Firefox windows plugin, I' m currently reworking the plugin used in VirtualRome project (www.virtualrome.it). An example of current development can be found at www.tinyurl.com/muvi3d If you want to test, suggest to use a separate empty profile, by running your Firefox with --profile your empty dir The problem with the old style plugin, was that it had instability and problem running on low end machines. I' m currently experimenting with an architecture that keep OSG related stuff in a separate process, like Google Earth plugin does. It seems more stable and able to work on smaller machines, still lacks javascript access. The code is currently not in good shape, but I was planning to releasing under LGPL Anyway, if someone is interested, I can share the repo (Bazaar based). Manuel Garea wrote: Ok, i'll try installing OSGVirtualPlanets Manuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21781#21781 ___ 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] Python users
I have used swig generated Python bindings from osgSwig http://code.google.com/p/osgswig/ I have used it with 2.9.5, not knowing weather recent SVN big changes have broken the build Rizzen wrote: Hi, What is the best OSG python library/wrapper to use? I see there are various versions: pyOSG, PyOSG and osgPython. Some project showed no activity since 2003. Some projects showed activity in the news yet files are a lot older. PyOSG does not seem to have a SVN on SourceForge, just old tarballs. I am planning to use Boost:python in my project too. Thanx, Rizzen ___ 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] Freetype and JPG plugins problems
Not sure if this is the same problem: I had a somehow similar problem of deployment (plugin not loading in deployed machine WITHOUT redist) It has happened both on vs8 and vs9. I somehow solved the problem of osgdb_osg and ive plugins not loading by copying the needed msoft dlls and manifests in osgPlugins-2.9.6 (awful hack to be solved) For other plugins, I compile my version of jpeg,curl and freetype into static lib from source using cmake via the cmakeports project http://code.google.com/p/cmakeports/ So I do not need to use external dll that could have been built with a different build chain. I do not think the USE_3RDPARTY_BIN is related, If I remeber well, it is just a hint on Cmake to search external libs in a side library... Nevertheless, you should be able to see which external libs have been got by using advanced view in the cmake gui Hope it helps Luigi Alessandro Terenzi wrote: Thank you for your help, I already tryed to set the notify level to debug and, as far as I understand, plugins are always discovered but the only error message I see is DynamicLibrary::fail loading ... no further detail is provided. I just had to try to install the redistributables for Visual c++ 2005 SP1 on the deployment machine (even though I was providing my application with a manifest and corrensponding CRT), so I tried it but again this not solved the problem...actually on every deployment machine the installation of the redistributable looks not so 'polite' because it strarts but doesn't display a completion message, so I'm not so sure about a successful installation... Tried also the dependency walker tool on the target machine, and some DLL are not found but they are the same as the RGB plugin that works. The missing DLL is DWMAPI.DLL, don't know what it is for... Don't know if this could relate to this problem, but in CMake I see the USE_3RDPARTY_BIN set to ON by default...what does it mean? Thank you again... Kind regards, Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18329#18329 ___ 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] Freetype and JPG plugins problems
The freetype support should be in svn, there is probably a problem in cmake downloading from the freetype link... I had problem and put a wget exe in the path, so cmake find it and use it to download, get it from: wget: html: http://gnuwin32.sourceforge.net/packages/wget.htm bin: http://downloads.sourceforge.net/gnuwin32/wget-1.11.4-1-bin.zip dep: http://downloads.sourceforge.net/gnuwin32/wget-1.11.4-1-dep.zip regarding curl, the latest distribution include cmake support, unfortunately it lacks install ... i made myself If you are interested, I can send you a readme to document my layout and the needed step to build deps and osg, It would be useful also for myself. If anyone else would be interested we could put it on the wiki once tested Regards. Luigi alessandro terenzi wrote: I managed to let the jpg plugin work as suggested by Luigi, really thanks. By the way, Luigi you talked about also cmakeports for curl and freetype, but they are not public available yet, am I wrong? Can you share the freetype port? Thanks again for your help! Regards. Alessandro On Fri, Oct 16, 2009 at 5:24 PM, Luigi Calori l.cal...@cineca.it mailto:l.cal...@cineca.it wrote: Not sure if this is the same problem: I had a somehow similar problem of deployment (plugin not loading in deployed machine WITHOUT redist) It has happened both on vs8 and vs9. I somehow solved the problem of osgdb_osg and ive plugins not loading by copying the needed msoft dlls and manifests in osgPlugins-2.9.6 (awful hack to be solved) For other plugins, I compile my version of jpeg,curl and freetype into static lib from source using cmake via the cmakeports project http://code.google.com/p/cmakeports/ So I do not need to use external dll that could have been built with a different build chain. I do not think the USE_3RDPARTY_BIN is related, If I remeber well, it is just a hint on Cmake to search external libs in a side library... Nevertheless, you should be able to see which external libs have been got by using advanced view in the cmake gui Hope it helps Luigi Alessandro Terenzi wrote: Thank you for your help, I already tryed to set the notify level to debug and, as far as I understand, plugins are always discovered but the only error message I see is DynamicLibrary::fail loading ... no further detail is provided. I just had to try to install the redistributables for Visual c++ 2005 SP1 on the deployment machine (even though I was providing my application with a manifest and corrensponding CRT), so I tried it but again this not solved the problem...actually on every deployment machine the installation of the redistributable looks not so 'polite' because it strarts but doesn't display a completion message, so I'm not so sure about a successful installation... Tried also the dependency walker tool on the target machine, and some DLL are not found but they are the same as the RGB plugin that works. The missing DLL is DWMAPI.DLL, don't know what it is for... Don't know if this could relate to this problem, but in CMake I see the USE_3RDPARTY_BIN set to ON by default...what does it mean? Thank you again... Kind regards, Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18329#18329 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] Visualizing Terrain DB on web page
Hi Akilan My deployment scheme is based on extension under Firefox. Do you need javascript interaction with the application (like virtualrome site) or are you ok with just embedding in the page? In the latter case, look at test examples in the link http://3d.cineca.it/storage/OSG4Web_test/Windows/test.html Test it if it suit your need I can send you the address to get the source. I' ll be off line for next two weeks, so either today or in september Regards Luigi Akilan ha scritto: Hi, Yeah, I did in the same way as u said. Wrapped OSG functions into ActiveX control and deployed with IE. It s working fine. But it is not happening so with Firefox. Yes, I need help to deploy using Firefox. Thank you! Cheers, Akilan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16320#16320 ___ 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] Visualizing Terrain DB on web page
I had an earlier version for IE, wrapped as an ActiveX. We had it working with old OSG so possibly 2.2 The main problem for deployment was the fact that ActivaX tech require Admin privilege to be installed not a good thing in my opinion Furthermore Firefox extension provide off the shelf signed update framework to maintain your stuff. The current implementation does not work on Explorer. If you need explorer I can dig my old stuff to see if find somethiong working Future plan is to layer on third party cross browser framework. Let me know if you are interested or need help to try out firefox stuff Regards Luigi Akilan ha scritto: Hi, I am using Internet Explorer 6.0. And one more thing I have OSG2.2. Is it mandatory to have 2.9.x version to do this. Once the plug-in is added, could we directly see the .ive file on explorer? Thank you! Cheers, Akilan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16223#16223 ___ 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] Visualizing Terrain DB on web page
Hi Akilan You can have a look at http://3d.cineca.it/storage/OSG4Web_test/Windows/test.html this is my test page for osg4web firefox extension development. on first acess the js code should check for extension and ask for installation. It is an firefox extension wrapping osg 2.9.x It is not fully stable. It also include code for the virtualrome application ( www.virtualrome.it) Is not still stable, unfortunately, can crash firefox, use with firefox devel account (use a shortcut like firefox.exe -no-remote --profile your new devel profile folder ) http://3d.cineca.it/storage/OSG4Web_test/Linux/test.html ... (32 bit only) The project is on development and open, let me know if you are interested, a preliminary linux version on Cheers Luigi Akilan ha scritto: Hi, I would like to visualize my terrain DB constructed using osgdem on web page? Could it be possible? Is there any plug-in to do so? Thank you! Cheers, Akilan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16008#16008 ___ 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] Feature request for 2.9: please include swig bindings in main release
Hi John and Gerwin, I' m also using osgswig... and really would like it kept up with the osg development. Using good python IDE such as SPE, developing osg is much easier (for me) than in C++ . really thanks to all osgswig developers Currently I' m stuck with an svn OSG version (2.9.5) that I' ve been able to wrap with minimal mods to osgswig (if someone is intrested, I could send the mods) last time I tried (2.9.6) there were issues in osgManipulator wrapping I'm unwilling to update as each time I update osg... there are some problems with swig wrapping. One of the worst issues has been the MixinVector that has broken all the vecArrays wrapping thus preventing python construction of geometry. I do not know weather Robert is aware of the hassle this mod has caused to osgswig users. I understand that the wrapping code is not fully automated, but, as far as I know, this is the only python wrapper used. I agree that the stability of osgswig is currently not high enough to be included in the standard build, but I do not think is so bad. It would be nice to have a fully automated wrapper generation process, but, as far as I know, there are no available good automated python wrapper for OSG, even other projects, such as OGRE, that use other technology for wrappers, need some manual twiddling. So I fear that the problem of getting good python (or other lang) wrappers could not be currently solved without the involvement of core C++ developers. On osgswig side we could try to set up a dashboard WITH TESTING to help osg developers to be early aware of mods that hurt the wrapping process: If we have a minimum of platform where osgswig get compiled nightly, each time doing an svn update of the OSG trunk, a rebuild and some test runs, osgswig developers could be early warned by osg new commits that breaks the wrapping. At this point, if there is a critical mass of osg python users, osgswig and osg developers could be more willing to devote some time to resolve the inconsistency. I' m currently using osgswig mainly under windows, both VC8 and VC9, as VC7 is not able to compile the HUGE osgPYTHON_wrap.cxx This are my 2 cents. Luigi Calori Gerwin de Haan ha scritto: Hoi John, I appreciate your enthusiasm for osgswig, we hear you! Including osgswig in the main repo would certainly increase its exposure and use. However, I'm not really sure if the Including them would ensure that they are kept up to date-argument would hold just yet. There are also quite some issues that still need to be resolved (especially for alternative languages other than Python), and not too many developers helping out at this point. The bindings currently involve quite some manual work, and it is hard to keep up with all the changes. I would instead encourage you and other developers/users to help out by posting issues,requests and questions here and on the osgswig issue tracker at http://code.google.com/p/osgswig/ . In due time, we may get in sync with the osg releases. cheers, Gerwin On Sun, Aug 2, 2009 at 11:36 PM, john casu j...@chiraldynamics.com mailto:j...@chiraldynamics.com wrote: Hi, the SWIG bindings are so useful, that it seems like a good idea to include them with the main release, predicated with -DBUILD_SWIG_BINDINGS -DBUILD_PYTHON_SWIG_BINDINGS or -DBUILD_RUBY_SWIG_BINDINGS (etc..) flags. Including them would ensure that they are kept up to date, and that any bindings are correct for the installed release of OSG. Moreover, it would encourage the building of those bindings for other languages, other than python or ruby. ... Thank you! Cheers, john -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15708#15708 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org 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] Image file PagedLOD...
I have a similar problem, some models with too heavvy texture to put on the web... The models were not so many so , for the ones with little geometry I just used a chain of PagedLOD with the same geometry but with texture of incresing resolution. I did the conversion by hand but I' m currently trying to do it in an automatic way. This approach has the problem of replicating geometry. I have also tried to putt al the geometry into ProxyNodes and then refernce them in the PageLOD structure... but this seem result in multiple loading of the same proxy... I thought all files were cached, as images do... Your approach seem interesting, but how you decide when the ImagePagedLOD switch? the PagedLOD inherit the switching from LOD Sorry for the long post.. but it is an interesting argument for me now... Thanks Luigi neil.hug...@tesco.net ha scritto: Hi All, Has anyone come across a scenario where they wished to have PagedLOD that instead of handling Nodes, handle images ? Essentially I find myself in a position where I have a model that references a texture, but that texture is quite large, and even with reducing the texture size with little compromise in quality, the time to stream over the web is too large. So, what I'm considering is replacing the image load call, with a similar concept to that of PagedLOD's whereby I could give the PagedImageLOD object a list of ordered image file names that I want it to progressively load - in much the same way that apps like google map appears to work. The first image file could be a 2x2 pixel image, whilst the nth image file would be the full-on image. I would want the PagedImageLOD to return a valid Image node immediately - perhaps a hard coded small default image - whilst in the background the specified image filesnames are being downloaded, and replace the content of the created image node. The reason for this sort of functionality would be that I could then intercept all image load requests via my own callback handler, replace with a PagedImageLOD request, and still permit most plugins to work happily on the assumption that a model plugin that loads an image is probably only trying to reference that image in some stateset context. Sorry for the thought dump, but has anyone tried/needed to do a similar thing, and if so is there an example available ? Alternatively, if you can think of a better way that would be good as well. Most obvious alternative - that of have an LOD node on the model - would be fine if I only had one or two models. However, I have thousands of different models, so can't really ask our modellers to redo all these. Many thanks for any help/thoughts. Kind regards Neil. .to whose content was progressively replaced by the downloaded images. In this way I could ___ 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] Dynamically generating smooth camera rides?
Not sure exactly what you want: look at http://3d.cineca.it/storage/demo_vrome_ajax/virtualrome_3d.htm (need windows + firefox+install the plugin) then either double click with the central button on some point on the scene or select some viewpoints on the left. If the motion effect is what you like, the code behind is open source. If you like, let me know, I' ll try to direct you to the code snippet. Hope it helps Christian Buchner ha scritto: Forgive my laziness - are there any utility classes within OSG that let the camera go on a smooth ride to a specific location and eyepoint vector from the current location? I mean smooth in the sense of the camera accelerating and braking, instead of making a simple constant linear movement and rotation. If there is no ready made solution for camera paths - how difficult would it be to dynamically create a key frame animation for the camera for abitrary start and stop locations? Ideally I'd like the user to be able to quickly observe some points of interests within in my 3D simulation, without instantaneously zapping the camera to the new position. There should be some kind of whoosh effect where the camera travels from the current location to the destination quickly, within about second. This may have the advantage that the user will be able to maintain a sense of orientation in space which would be lost by switching to the destination camera position instantly. Christian ___ 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] [build] how do i generate project.exe file and .pdb file in specified folder
Hey Abhinav did you tried my early suggestion? put ../ in front of your name or prefix property as I' ve already suggested. the ../ hack is also used in osg CMake files, look at OsgMacroUtils.cmake, in particular line 263 Luigi Abhinav Dubey ha scritto: Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum hey dear it works but the only problem is that it creates a subfolder DEBUG under BIN which i dont want ..i want the files to directly come under BIN. Any solution for this??? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10770#10770 ___ 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] [build] how do i generate project.exe file and .pdb file in specified folder
Try this
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${your_exe_dir} )
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
LIBRARY_OUTPUT_DIRECTORY ${your_lib_dir} )
IF(MSVC_IDE)
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES PREFIX ../)
or
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
RELEASE_OUTPUT_NAME ../${TARGET_NAME})
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
DEBUG_OUTPUT_NAME ../${TARGET_NAME}D)
ENDIF(MSVC_IDE)
Not sure where the pdb will be put though I' m using the latest (
2.6.3) cmake
Hope it helps
Luigi
Abhinav Dubey ha scritto:
i know that way it can be done..but i am using Qt+VS+Cmake and need to do this
cia CMakeLists.txt. right now what i am doing is that i copy these file from
the repective folders as a post build even. the code i am using is:
if(WIN32)
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND md ARGS
$ENV{N3DBINARY_PATH}\\bin
COMMAND copy ARGS
$ENV{N3DBINARY_PATH}\\${CMAKE_CFG_INTDIR}\\${PROJECT_NAME}*.exe
$ENV{N3DBINARY_PATH}\\bin
COMMAND if $(ConfigurationName) == Debug copy ARGS
$ENV{N3DBINARY_PATH}\\${CMAKE_CFG_INTDIR}\\${PROJECT_NAME}*.pdb
$ENV{N3DBINARY_PATH}\\bin
)
endif(WIN32)
but i want to directly get these files in bin instead of copying them. can yoyu
uggest the code for it!!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10697#10697
___
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] [build] how do i generate project.exe file and .pdb file in specified folder
It depends if you want them put there at INSTALL time or at BUILD time. CMAKE_INSTALL_PREFIX set the installation path If you want the dll and ex in bin at BUILD time, as I' ve already suggested, set RUNTIME_OUTPUT_DIRECTORY in bin AND put ../ in front of your name or prefix property as I' ve already suggested. the ../ hack is also used in osg CMake files, look at OsgMacroUtils.cmake, in particular line 263 of macro SETUP_EXE This is the way the target are currently put into bin subfolder of the build dir. Regards Luigi Abhinav Dubey ha scritto: Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum ok..will try this out..i tried the other way i.s setting the RUNTIME_OUTPUT_DIRECTORY but what its doing is that it creates a debug folder containing the executable files in the bin bolder. I want the files directly to come under the bin folder..hope yor solution works. will let you know tomorrow when i try it out at my office. Thx a lot.. :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10731#10731 ___ 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] vertex data in byte precision
Probably a newbie question:
Is it possible to store vertex data in byte array like Vec3bArray ?
I' ve tried but it seem not allowed: I obtain crash when call setVertexArray
Is it something dependent on driver?
I attach two sample files, short working, byte hanging
Thanks
Luigi
Group {
UniqueID Group_0
nodeMask 0x
cullingActive TRUE
num_children 2
ClearNode {
nodeMask 0x
cullingActive FALSE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber -1
binName RenderBin
}
requiresClear TRUE
clearColor 0 0 0 1
clearMask 16640
}
Geode {
nodeMask 0x
cullingActive TRUE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHTING OFF
GL_DEPTH_TEST OFF
GL_BLEND ON
0x8861 ON
Point {
size 20
fade_threshold_size 1
distance_attenuation 1 0 0
}
BlendFunc {
source SRC_ALPHA
destination DST_ALPHA
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
file Images/particle.rgb
wrap_s CLAMP
wrap_t CLAMP
wrap_r CLAMP
min_filter LINEAR_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
PointSprite {
coordOriginMode UPPER_LEFT
}
}
}
num_drawables 1
Geometry {
DataVariance STATIC
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays POINTS 0 128
}
VertexArray Vec3sArray 128
{
0 11 2 3 16 0
7 18 -8 15 14 9
16 10 -10 4 0 -3
5 4 -8 16 8 -11
3 9 2 7 9 2
7 15 -8 4 4 2
20 19 7 5 2 4
24 22 0 5 -1 -4
22 9 8 10 11 8
17 14 5 0 0 -7
12 10 -7 8 -7 6
10 14 4 6 4 3
14 14 0 10 -1 6
18 14 3 8 -4 1
14 20 0 0 -8 3
11 34 -4 13 -7 1
9 16 -4 13 -5 5
1 34 0 15 -10 -4
15 30 3 6 0 0
-1 21 -3 21 -8 0
7 26 1 13 -6 2
4 27 3 12 -10 -4
-1 31 4 20 -15 4
-3 24 3 23 -9 -1
-7 22 2 36 -10 0
-15 30 0 35 -7 3
-20 34 0 32 -13 -2
-6 25 2 36 -8 -3
-23 25 -1 31 8 -1
-24 22 0 43 5 1
-23 8 2 28 -4 2
-26 5 -2 41 -2 0
-16 13 0 42 1 -2
-18 2 0 40 7 0
-20 -3 1 42 25 2
-29 -3 0 36 29 3
-30 -1 2 34 22 -2
-14 -11 0 36 32 -1
-18 -8 0 40 30 0
-12 -7 0 42 38 0
-24 -13 -1 38 45 -1
-13 -17 0 37 38 -2
-8 -22 1 35 48 -2
-8 -19 1 38 49 -2
-3 -20 -1 22 51 -1
-10 -24 -1 29 57 0
-7 -42 0 21 60 0
3 -39 -1 13 55 0
14 -40 1 16 66 1
10 -28 1 -2 49 0
21 -29 0 -8 65 0
16 -37 2 -9 53 0
32 -44 0 -9 54 1
34 -38 0 -10 56 0
29 -29 1 -27 56 0
49 -31 0 -26 57 0
57 -26 -1 -35 46 1
62 -23 -2 -42 42 0
49 -14 0 -30 43 1
51 -24 -1 -36 39 -1
57 -10 0 -47 28 0
73 -1 1 -46 29 1
62 0 -1 -51 16 1
62 2 0 -50 12 -1
}
ColorBinding PER_VERTEX
ColorArray Vec4Array 128
{
1 1 0 0.5
1 1 0 0.5
0.984375 0.984375 0.015625 0.507813
0.984375 0.984375 0.015625 0.507813
0.96875 0.96875 0.03125 0.515625
0.96875 0.96875 0.03125 0.515625
0.953125 0.953125 0.046875 0.523438
0.953125 0.953125 0.046875 0.523438
0.9375 0.9375 0.0625 0.53125
0.9375 0.9375 0.0625 0.53125
0.921875 0.921875 0.078125 0.539063
0.921875 0.921875 0.078125 0.539063
0.90625 0.90625 0.09375 0.546875
0.90625 0.90625 0.09375 0.546875
0.890625 0.890625 0.109375 0.554688
0.890625 0.890625 0.109375 0.554688
0.875 0.875 0.125 0.5625
0.875 0.875 0.125 0.5625
0.859375 0.859375 0.140625 0.570313
0.859375 0.859375 0.140625 0.570313
0.84375 0.84375 0.15625 0.578125
0.84375 0.84375 0.15625 0.578125
0.828125 0.828125 0.171875 0.585938
0.828125 0.828125 0.171875 0.585938
0.8125 0.8125 0.1875 0.59375
0.8125 0.8125 0.1875 0.59375
0.796875 0.796875 0.203125 0.601563
0.796875 0.796875 0.203125 0.601563
0.78125 0.78125 0.21875 0.609375
0.78125 0.78125 0.21875 0.609375
0.765625 0.765625 0.234375 0.617188
0.765625 0.765625 0.234375 0.617188
0.75 0.75 0.25 0.625
0.75 0.75 0.25 0.625
0.734375 0.734375 0.265625 0.632813
0.734375 0.734375 0.265625
Re: [osg-users] Compressed texture
As I' m also interested in texture compression my question is: when using .osg files or ive files without texture inside (those obtained by osgconv -O noTexturesInIVEFile useOriginalExternalReferences foo.osg soo.ive) if there is a chain of pagedlod files that refer to the same texture (for example the same material texture is used for different files at different lods) does it get readed or loaded in txture memory several times? I though it does not happen... but willing to be sure. Instead, if it is embedded in ive, it is replicated. Am I wrong? Another question: could be feasible to store jpeg as S3TC_DXT* instead of uncompressed? I know it is not happening now... would it be hard to implement? are there technical limitations? it seem to me that other web enabled sw like Google Earth are transmitting jpeg texture I experimented once trying to call the same compression code in osgconv inside the jpeg plugin after the read... but the code got unstable and slow. Has anyone tried this and/or would it be of some interest? Thanks in advance Robert Osfield ha scritto: Hi Yefei, On Wed, Apr 1, 2009 at 4:24 PM, Yefei He y...@nads-sc.uiowa.edu mailto:y...@nads-sc.uiowa.edu wrote: Thanks for your reply. Yes, I agree it will take quite some effort and possibly format change to implement texture sharing between ive files with built-in textures. That's why I would like a quicker way out:) -- using ive files without built-in texture but refer to compressed texture in dds format. Is my assumption correct that compressed texture in dds format remains compressed when loaded into memory and passed on to the osg core and GL layer without being decompressed, as opposed to say jpeg images which are decompressed during loading and then passed on to osg core in uncompressed bitmap format? Yes this is correct, the OSG loads the S3TC_DXT* compressed formats from the .dds file and keeps them in that format in the osg::Image and the final downloaded texture. You can compress the textures for a file using osgconv: osgconv --compressed myfile.flt myfile.ive It won't solve the problem of sharing textures though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Unreckognized Commands
I did not used express, a similar problem happend to me when I had an osgviewer of one version using a dll from another. Check if you have other osg dll in your path and check if your dll and your exe are all debug or all release. You can also use depends to check the dll loaded at runtime. If you are using svn head, try to switch to 2.8 release and rebuild from scratch to see if the problem persist. Hope it helps Adam Wise ha scritto: Good and bad news: The good: I can access osgviewer. The bad: It crashes every time I try to use it. The message I receive is: osgviewer.exe has encountered a problem and needs to close, We are sorry for the inconvenience. That message is oddly ambiguous...and it happens every time. What should I do? GordonTomlinson wrote: The D on the end of the name of an EXE or DLL in OSG means you're using the debug version of the code, rather than the release version which does not typically have a D at the end You need to set the environment variable OSGDATA to the location where you installed the Osg data package I would recommend you change the environment variable in your system settings, as opposed to the autoexec.bat , you can change that through control panel-system-advanced-environment variables and edit the PATH entries Note when you change environment variables you will have to close all instance of Visual studio or other programs that use them as they will not pick up any changes until you do, __ Gordon Tomlinson IM: www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [mailto:] On Behalf Of Adam Wise Sent: Sunday, March 15, 2009 7:16 PM To: Subject: Re: [build] Unreckognized Commands I went to the directory where everything was built, and indeed I found the executables and ran them in command line. But here's the new problem: it cannot find the OpenSceneGraph-Data-2.8.0 folder. I'm trying to run the osgviewer cow.osg example...but that doesn't seem like a possibility right now. I want to set everything up where my data can be easily found. Also, Osgviewer...is actually Osgviewerd. What's the difference between the two? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=8505#8505 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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=8508#8508 ___ 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] Troubles building osg_Freetype plugin
I' m using vs7.1 static lib with 2.6 and 2.8, get it at http://3d.cineca.it/storage/packages/osgdep_vs71.zip or get the cmake project that I use to build them at http://3d.cineca.it/storage/packages/3rdPartySrc_pack.zip Recently Philip Lowman has started a project to provide CMake builds for basic libraries http://code.google.com/p/cmakeports/ Hope it helps Luigi Jean-Sébastien Guay ha scritto: Hello Dieter, I find the freetype219.lib, but I thought I need the never version of the freetype (freetype235.lib?) libs. Oops, you're right, looks like the 3rdParty repo was not updated for VS 7.1. Does anyone have 3rdParty binaries they could contribute that work for compiling OSG 2.6/2.8? We could put them on the download site like the VC9 3rdparty binaries. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Packaging distribution under Windows
Sukender ha scritto: [I reply a to a direct mail on the mailing list - See copy of the mail below] Hi Thomas, Thank you for the info and inno link. Has someone compared inno to nullsoft installer ( http://nsis.sourceforge.net )? I guess I'll have to go and script everything (this is not the case at the moment); so copying only needed DLLs seems the way to do it. I think that cpack support one windows installer (do not rimember which as I really hate installers: the best one is zip: install=unzip uninstall=remove) I agree that including dll is the bet way to go, in that case, I wouls suggest to include alsoMSVC runtime with the app, in order to NOT require any administrator access. I adopted this strategy to assemble the firefox estension I' m working on. If you are interested, try : http://3d.cineca.it/storage/OSG4Web_test/Windows/test.html and install the extension to see the libs included Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Tue, 24 Feb 2009 02:57:01 +0100, Thomas Hogarth thomas.hoga...@googlemail.com a écrit: Hi Sukender I would reply on the mail list but it's not letting me (not sure if I set it up right). I've been distributing downloadable osg apps for a little while now, and have basically come to the conclusion that including the dlls in an installer and installing them into the apps directory is the easiest way to go. It does create multiple copies, but with multiple version of osg floating around, coping to system folder can be risky. The few tricks I have picked up are Think about what plugins you need, if it's an app loading fixed content then you only need the dlls for that content. Use a good setup compiler, the one in visual studio is ok but ultimately it's messy. I use inno script ( http://www.innosetup.com/isinfo.php ) it's great and has a fantastic help file I've gotten pretty content heavy apps in at about 20 to 50 MB. This is pretty huge compared to without the dlls, but is acceptable for a polished app I think. (this is one I did at work using openscenegraph 1.4 and artoolkit http://www.bbc.co.uk/merlin/#/games/magiceye/ comes in at about 36 MB I'd enjoy hearing more on this, as in the end, the smaller the better :) Cheers Thomas Hogarth PS Once I get the user list sorted I'll be posting in there ___ 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] [build] Can't build libraries under windows
The fact that cmake try to compile osgdb_jpeg means Your FindJPEG does nopt return NOTFOUND, try to set Advanced view in cmake-gui and look what library/include it has found. If It point to lib that have been built with MSVC, it is very likely it does not work. So either you remove them or try to build jpeg lib from source with your mingw tool chain. Or try to find a pre-built one with mingw. If you dare to try the first solution, I have some cmakified sources that I use with VS71, get them from http://3d.cineca.it/storage/packages/3rdPartySrc_pack.zip and try to see if they compile with mingw (if you manage, send me patches, thanks), unzip the required files in -place as jpeg Regarding pre-build libs, You probably know better how to get pre-built libraries with mingw, Otherwise, you can try to use the ebuild tool from winkde project: http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/emerge I see they have quite a lot of package read for emerge, and mingw is probably better supported than msvc Hope it helps Jonatan ha scritto: I am trying to compile the binaries myself, and if I succeed I do want to make them available for others. The problem is, that I get compilation errors for mingw_osgdb_jpeg.dll . Does anybody know the solution to these errors? (see my previous post/mail for the exact error messages) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7227#7227 ___ 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] problem with Windows debug binaries?
Cory Riddell ha scritto: Do end users download and install OSG? What on earth do they do with it? I believe the intent of the binary packages is to provide a shortcut for developers on Windows to get OSG and the dependencies. If that's the case, then it wouldn't make any sense to include the MSVC. The official distribution is the source tarball, no? If you are a developer and want to test OSG on different hardware platforms, then you need something that run with minimum hassle: Think of build an usb pen and ask some colleague of yours to run that specific OSG example and see if it works ok on his (possibly old) pc I have been in this situation quite often. I came up with a folder that include the OSG install + osg data + a run.bat that set up OSG_FILE_PATH (it woul really be nice if there was a way to define a default path) It seems to me that, for testing purposes, the inclusion of system dll would be good, at least as a default off option. I silently had to patch osg CMakeFile to do exactly what Philip suggested but did not dare to ask for inclusion ...I know windows only hack are not exactly welcome. If you have to build apps that deploy as binaries in platform that you do not control (as it happen to me), it could be handy to have a reference osg installation to test the deployed platform against, as it happens that there are bugs related to bad OpenGL drivers. So the need to test with official OSG examples (test) I also think that OSG could benefit from extensive run time testing, on different HW platform and drivers, possibly published as a dashboard, as CDash already support an other sw like VTK do. In that usage pattern, asking for a runtime installation that requires Admin privilege to just save some bytes seems incorrect. Just my 0.2 Euros Luigi cory Philip Lowman wrote: . Original Message ... On Tue, 17 Feb 2009 09:31:37 -0500 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Yeah, those ZIP releases of the OSG 2.8.0 prebuilts should really have the following files placed in the bin folder so they work out-of-the-box on Windows 2000, Windows XP, or Windows Vista without anyone having to install the MSVC runtime crap. IMHO, installing the MSVC runtime crap is preferable to copying the same DLLs in every release zip for every version of OSG (and potentially every other project we work on...) and therefore having potentially tens if not hundreds of copies of the same files on your system. Installing the redist ensures you have one copy (the right one) and it's accessible to all programs. Personally I would trade the whopping 1.6 MB this would take up for the assurance that the binaries will work on all machines. Of course if you want an end-user's first experience running osgviewer to view some model they found online to be a cryptic error message, then by all means leave things the way they are. Unfortunately, not every first time user of OSG is going to have MSVC installed or the runtime libraries installed. Yes I agree this sucks. Unfortunately the SxS runtime libraries do not come with Windows. There is no disadvantage to including the runtime DLLs aside from an extra 4 files and 1.6MB of space used. I think this is really a no brainer. ___ 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] -2.8 branch, testing-- vs71
Robert Osfield ha scritto: Hi Luigi, Thanks for the testing. Curious how each different version of VS is generating a different sets of warnings. The new warnings are down to a combination of pruning #prgrama warning disables from include/osg/Export and upping the default warning level. At this late in the game the we can either suppress the warning or lower the warning level. In this case I've gone from suppressing the specific warnings that were causing your problems, changes now checked into the OSG-2.8 branch. I ' ve updated and started a rebuild. Is currently running, Most warnings seems gone, one still remain. Ill' send the output when finished or do I try to submit experimental CDash build? The compile error with the tiff plugin only occurred for the debug build, the release build ran fine so it does suggest a mis-match in the build of the tiff library. Are you able to recompile this from source? Sorry... The debug was run with unpatched source, the release with my old patch. I had it submitted long ago but never checked in. I currently compile tiff library and all the other basic dep (tiff, jpeg , png, zlib, freetype, curl) with a cmake script. I tried co compile them statically as so I do not need other .dll around. I do not know if is my way of build or if is the static build, but I get link error in tiff plugin if I do not link also with jpeg and zip lib. I understand that you do not want to add unnecessary extra linking. Is feasable to add a specific VS7.1 case, Another way could be to add special case to the Find3rdPartyDependencies. I' m setting ACTUAL_3DPARTY_DIR to specify my dependency install path Other MSVC builds are using this way to find dep or the linux Findxxx stuff? It is hard to tell from the dashboards. Thanks Luigi Robert. On Fri, Feb 6, 2009 at 9:42 AM, Luigi Calori l.cal...@cineca.it wrote: I'm currently building 2.8 trunk under Windows XP Visual Studio 7.1 I'm getting quite a lot of warning, I know this has been discussed before, just want to make sure it is an expected result and not something due to my build setup: I attach the debug and release output zipped Looking at the dasboard entries of other VC builds on VC 8 and VC Express it seems they have much few warnings: it is a compiler issue or there is a better way to build? expecially the c:\programmi\microsoft visual studio .net 2003\vc7\include\xtree(1121) : warning C4702: unreachable code is really noisy and seem VC related If there is interest in supporting VC 71, I can try to arrange for a nigthly test platform. I had also an error in building tiff plugin, probably related to my libtiff lib that is built as static. Thanks in advance Luigi ___ 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 Index: src/osgPlugins/tiff/CMakeLists.txt === --- src/osgPlugins/tiff/CMakeLists.txt (revision 9682) +++ src/osgPlugins/tiff/CMakeLists.txt (working copy) @@ -2,7 +2,7 @@ SET(TARGET_SRC ReaderWriterTIFF.cpp ) -SET(TARGET_LIBRARIES_VARS TIFF_LIBRARIES) - +#SET(TARGET_LIBRARIES_VARS TIFF_LIBRARIES) +SET(TARGET_LIBRARIES_VARS TIFF_LIBRARY ZLIB_LIBRARY JPEG_LIBRARY) end var setup ### SETUP_PLUGIN(tiff) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] -2.8 branch, testing-- vs71
Robert Osfield ha scritto: Hi Luigi, Home come you need to compile in the jpeg and zlip libraries into libtiff? Does you build of libtiff use these but not link them in itself? It seems a problem in libtiff build, as forcing linking to jpeg and zlib seem solve the problem Thanks a lot Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Philip: I did not know you has access to the CMake CVS, good to know,.
I had to change my FindOSG as I need to find also .dll and .so on
windows and linux.
So I needed both version as well soversion, so I decided to run the
osgversion utility
Furthermore, it seem to me that osgversion provide other flags to check
for defines that have been specified in the build process of the osg
found. like OSG_USE_FLOAT_MATRIX, OSG_USE_FLOAT_PLANE or
OSG_USE_FLOAT_BOUNDINGSPHERE, are those still required to be defined
when compiling against osg or they are not used anymore?
I decided to grab VPB version of FindOSG as really do not fully
understand the nedd of a separate Findosgcomponent .
I see that other Find modules that have multiple components such as
ImageMagick are implemented as single file.
In my opinion, having a single file is more handy if you do not use cvs
CMake and also help in keeping the distributed CMake Modules directory
cleaned,
I think we could just find all the components available in the
standard place and test the requirements against them.
If some of the macro I use for copying lib and plugins dll could be
useful to someone else, let me know, I can try to assemble them better.
Luigi
Philip Lowman ha scritto:
On Thu, Jan 29, 2009 at 10:39 AM, Luigi Calori l.cal...@cineca.it
mailto:l.cal...@cineca.it wrote:
This is my FindOSG file I use for getting dll to copy , it get the
version also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number
OUTPUT_VARIABLE OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number
OUTPUT_VARIABLE OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS
--openthreads-soversion-number OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a
packaged distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
A lot of work has been done recently in CVS CMake to improve the Find
modules shipped with CMake (originally written by Eric Wing) to better
work with the OSG. I believe most of the features Luigi has added to
his FindOSG.cmake should be present there with a couple of improvements:
1. Component support
2. It should be trivial to add find modules for new nodekits (bundled
with OSG or not) without modifying the core FindOpenSceneGraph.cmake file
3. Version support and enforcement (by header file parsing)
4. Backwards compatibility with older versions of OSG that lack newer
node kits. It will not search for nodekits until told to do so.
I left out exposing the SO version figuring that users that need this
level of detail can just include osg/Version (or osg/Config in the
case of double/float issues) and write their own configure tests.
Also SO versioning isn't available on all versions of the OSG anyways.
Here's a brief synopsis of how to use it. As you can see, it is very
easy for the end user. It should work anywhere from 2.0.0 to 2.7.9
and might even work with 1.2.0 although I don't have binaries around
to test this. =) Please see the documentation for more details.
find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgGA osgViewer osgUtil)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
If you feel anything is missing or if you try it and it doesn't work
please file a bug in the CMake bug tracker. I and others in the CMake
community will support these modules with your patches (especially now
that I have commit access =) ). All of the above should be included
in the upcoming CMake 2.6.3 release. If you prefer not to muck with
CVS I will post when an RC that includes the modules is available.
One minor downside to it is that if you can't set
cmake_minimum_required(VERSION 2.6.3) for your project, you'll have to
include more than one file in your CMAKE_MODULE_PATH. This is also a
bit of a good thing, however, as developers should be able to simply
distribute a 5 line FindosgFoo.cmake for their new nodekits and there
will be no need to continuously patch a FindOpenSceneGraph.cmake over
the long term as it will be distributed with CMake. Also if your
project doesn't need the osgFoo nodekit you would never need to
download the FindosgFoo.cmake file.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/?root=CMake
See:
FindOpenSceneGraph.cmake
Findosg_functions.cmake
Findosg.cmake (depends on Findosg_functions.cmake)
FindosgDB.cmake (depends on Findosg_functions.cmake)
Findosg*.cmake (depends on Findosg_functions.cmake)
FindOpenThreads.cmake
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori l.cal...@cineca.it
mailto:l.cal...@cineca.it wrote:
Hi Philip: I did not know you has access to the CMake CVS, good to
know,.
I had to change my FindOSG as I need to find also .dll and .so on
windows and linux.
So I needed both version as well soversion, so I decided to run
the osgversion utility
Furthermore, it seem to me that osgversion provide other flags to
check for defines that have been specified in the build process of
the osg found. like OSG_USE_FLOAT_MATRIX, OSG_USE_FLOAT_PLANE or
OSG_USE_FLOAT_BOUNDINGSPHERE, are those still required to be
defined when compiling against osg or they are not used anymore?
That is a good question, I'm not sure when osg/Config was added to
the build in relation to those preprocessor definitions being added.
Robert should clarify it, and also if is more robust to look at headers
or to run osgversion to get version number
I decided to grab VPB version of FindOSG as really do not fully
understand the nedd of a separate Findosgcomponent .
I see that other Find modules that have multiple components such
as ImageMagick are implemented as single file.
In my opinion, having a single file is more handy if you do not
use cvs CMake and also help in keeping the distributed CMake
Modules directory cleaned,
I think we could just find all the components available in the
standard place and test the requirements against them.
We can't remove FindosgComponent.cmake from CMake for backwards
compatibility reasons so I've instead focused on making those files as
tiny as possible and clumping the function calls in
Findosg_functions.cmake.
Well, that's also a CMake policy: if any findable package define one
Findxxx file for his sub-package the Modules folder will probably grow a
lot.
I think eventually the extensibility of FindOpenSceneGraph.cmake will
pay off. In the long term it can be used by 3rd party nodekit
developers so they can write their own FindosgFoo.cmake to allow their
nodekits to be found alongside the OSG, without having to worry about
submitting code patches to allow their nodekit to be detected.
Obviously in the short term so long as you can't declare CMake minimum
version = 2.6.3 the only real annoyance (assuming you want to use
this at all) is needing to download CM 4+x files in your
CMAKE_MODULE_PATH (where x = the number of nodekits you use in your
project). Of these 4+x files only 2 will likely ever change,
Findosg_functions.cmake FindOpenSceneGraph.cmake. Findosg.cmake
FindOpenThreads.cmake are obviously always required for very good
reasons. =)
OpenThreads is a different package, so, even if it is most used in OSG,
it deserves his own separate Find,
instead, the difference between FindOpenSceneGraph and Findosg is not
clear to me.
If some of the macro I use for copying lib and plugins dll could
be useful to someone else, let me know, I can try to assemble them
better.
There is something new in CMake called GetPrerequisites.cmake you may
want to investigate. I assume it may still may have some bugs in it,
but it aims at determining the DLL dependencies of your LIB files at
which point you can do whatever you want with the list (copy to build
tree, INSTALL(), etc.)
I had looked at it but not used as It seems in CVS only and not seen
clear example usage,
It seems to me it try to infer dll requiremets by parsing output from
dumpin under windows or ldd under linux it is an interesting
approach, not know if it is already usable.
Have you an idea if it 'll go into cmake 2.6.3 or just 2.7?
Making it easier for new CMake users to copy files to either MSVC
build trees or standard build trees is something I'd like to see
supported within CMake/Modules with an easy to use API. Everybody
seems to have either come up with their own home-brewed solution for
this one or have cobbled together something from mailing list posts.
I found quite handy to use:
IF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
SET(CMAKE_INSTALL_MFC_LIBRARIES 1)
INCLUDE(InstallRequiredSystemLibraries)
ENDIF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
to tell CMake to add system library to bin install folder, this way the
bin folder is made auto consistent.
Regards
Luigi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori l.cal...@cineca.it
mailto:l.cal...@cineca.it wrote:
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori
l.cal...@cineca.it mailto:l.cal...@cineca.it
mailto:l.cal...@cineca.it mailto:l.cal...@cineca.it wrote:
Hi Philip: I did not know you has access to the CMake CVS,
good to
know,.
I had to change my FindOSG as I need to find also .dll and
.so on
windows and linux.
So I needed both version as well soversion, so I decided to run
the osgversion utility
Furthermore, it seem to me that osgversion provide other
flags to
check for defines that have been specified in the build
process of
the osg found. like OSG_USE_FLOAT_MATRIX,
OSG_USE_FLOAT_PLANE or
OSG_USE_FLOAT_BOUNDINGSPHERE, are those still required to be
defined when compiling against osg or they are not used
anymore?
That is a good question, I'm not sure when osg/Config was
added to the build in relation to those preprocessor
definitions being added.
Robert should clarify it, and also if is more robust to look at
headers or to run osgversion to get version number
Header file parsing has an advantage in that it doesn't rely on the
user having their LD_LIBRARY_PATH or ld.so.conf file configured
properly to run osgversion.
In fact I had to add
IF(UNIX)
SET(ENV{LD_LIBRARY_PATH}
${OSG_BINARY_DIR}:$ENV{LD_LIBRARY_PATH})
ENDIF(UNIX)
before calling osgVersion the osg application are not linked
consistently and need setup of LD_LIBRARY_PATH, unfortunately
Provided Robert doesn't add non-numerics to his version numbering
scheme I'm fairly certain the regex shouldn't break. By all means,
please have a look. Better to fix any possible issues now than later.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindOpenSceneGraph.cmake?root=CMakeview=markup
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindOpenSceneGraph.cmake?root=CMakeview=markup
We can't remove FindosgComponent.cmake from CMake for backwards
compatibility reasons so I've instead focused on making those
files as tiny as possible and clumping the function calls in
Findosg_functions.cmake.
Well, that's also a CMake policy: if any findable package define
one Findxxx file for his sub-package the Modules folder will
probably grow a lot.
I do agree with you that the FindosgComponent.cmake arrangement is
probably not the best idea for most projects. For the OSG with its
many external nodekits I don't think it was a bad choice at all.
I do not want to start a flame here, I just perceive OSG as being mad
of several components, that are built and packaged together and rarely
reside on different paths
Regarding the argument that there may be too many files in the Modules
folder, I've heard it. My response is that the more files in Modules,
the better. I'd like to see 1000 files in Modules. Provided the
package is somewhat popular, it should have a find module.
Completely agree, but 1000 packages * 10 files per package (like OSG) =
1 files probably better organizing as one folder per package...
I think eventually the extensibility of
FindOpenSceneGraph.cmake will pay off. In the long term it
can be used by 3rd party nodekit developers so they can write
their own FindosgFoo.cmake to allow their nodekits to be found
alongside the OSG, without having to worry about submitting
code patches to allow their nodekit to be detected.
Obviously in the short term so long as you can't declare CMake
minimum version = 2.6.3 the only real annoyance (assuming you
want to use this at all) is needing to download CM 4+x files
in your CMAKE_MODULE_PATH (where x = the number of nodekits
you use in your project). Of these 4+x files only 2 will
likely ever change, Findosg_functions.cmake
FindOpenSceneGraph.cmake. Findosg.cmake
FindOpenThreads.cmake are obviously always required for very
good reasons. =)
OpenThreads is a different package, so, even if it is most used in
OSG, it deserves his own separate Find,
instead, the difference between FindOpenSceneGraph and Findosg is
not clear to me.
Findosg just finds libosg.so and osg.lib. Similarly FindosgDB
just finds libosgDB.so and osgDB.lib. FindOpenSceneGraph
orchestrates calling all of these small find modules. And yes, I've
put a warning note in Findosg.cmake to steer the new user to
FindOpenSceneGraph.cmake. We can't dramatically change the behavior
of Findosg.cmake, again, for backwards compatibility reasons. CMake
aspires towards 0 user build regressions on version upgrades both in
Source
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
This is my FindOSG file I use for getting dll to copy , it get the
version also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number
OUTPUT_VARIABLE OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS
--openthreads-soversion-number OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a packaged
distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
Hope it helps
Luigi
Jason Beverage ha scritto:
Thanks Art and JS, I'll take a look at osgPPU and see what I can come
up with.
Jason
On Thu, Jan 29, 2009 at 10:28 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com
mailto:jean-sebastien.g...@cm-labs.com wrote:
Hi Jason,
We've had a couple of requests on osgEarth to install our
osgDB plugins directly to the osgPlugins-VERSION directory.
Is there a way in CMake that I can determine what that
directory would be?
I think Art does something for this in his CMake files for
osgPPU... You could grab osgPPU and see.
It would be nice to have a generalized FindOSG.cmake file that
would be distributed with OSG and which any nodekits / projects
would use to get this for free. Or maybe this already exists?
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
mailto:jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
# Locate gdal
# This module defines
# OSG_LIBRARY
# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
FIND_PATH(OSG_INCLUDE_DIR osg/Node
${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include
/usr/include
/sw/include # Fink
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
FIND_PROGRAM(OSG_VERSION_APP
NAMES osgversion osgversiond
PATHS
${OSG_DIR}/bin
$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
/usr/local/lib
/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
IF(OSG_VERSION_APP)
#define binary folder
IF(WIN32)
GET_FILENAME_COMPONENT(OSG_BINARY_DIR ${OSG_VERSION_APP} PATH)
ELSE(WIN32)
GET_FILENAME_COMPONENT(tmp ${OSG_VERSION_APP} PATH)
GET_FILENAME_COMPONENT(tmp ${tmp} PATH)
SET(OSG_BINARY_DIR ${tmp}/lib)
IF(UNIX)
SET(ENV{LD_LIBRARY_PATH}
${OSG_BINARY_DIR}:$ENV{LD_LIBRARY_PATH})
ENDIF(UNIX)
ENDIF(WIN32)
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number OUTPUT_VARIABLE
OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --openthreads-soversion-number
OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
# Automatically detected build options
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS Matrix::value_type OUTPUT_VARIABLE
OSG_USE_FLOAT_MATRIX)
IF(OSG_USE_FLOAT_MATRIX MATCHES float)
LIST(APPEND OSG_DEFINITIONS -DOSG_USE_FLOAT_MATRIX)
ENDIF(OSG_USE_FLOAT_MATRIX MATCHES float)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS Plane::value_type OUTPUT_VARIABLE
OSG_USE_FLOAT_PLANE)
IF(OSG_USE_FLOAT_PLANE MATCHES float)
LIST(APPEND OSG_DEFINITIONS -DOSG_USE_FLOAT_PLANE)
ENDIF(OSG_USE_FLOAT_PLANE MATCHES float)
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Robert Osfield ha scritto: Hi All, Following on from my earlier topic of discussion on OSG packaging granularity and naming, and picking up on Andreas experiments with a Firefox plugin, and Cedric's further dev of the Blender Python scripts for exporting to .osg, and the other community activity on various plugins for others tools, I feel it's worth discussing how we go about coordinating and making it more accessible to end users. Completely agree, integration with other sw like browser,scripting,modelling is important and one of the weakest point of OSG compared with other projects ( ie OGRE ) is the lack of coordinantion in add-ons and the sparceness of source. Right now we have various projects that use the developed out in the community that fit the role of plugins to other tools, like modelling applications to provide OSG exporters, and plugins to browsers. Most of the these projects will be maintained out in the community, may have their own project websites, may have a single contributors, or several, and may be dropped, then picked up by others further down the line, or just sit annexed out on the wiki. This situation isn't too much work for me as It means I don't need to spend time coordinating or maintaining these works, but... often it looks like such projects come and go in terms of support for latest versions of OSG, or latest versions of the 3rd party applications, so I'd guess for many OSG users/developers that aren't straight forward to pick up and use. Are you thinking of a sort of 'battery included' OSG, with dependency and addons? One possible solution might be to bring maintenance and distribution of these 3rd party plugins directly into the core OpenSceneGraph distribution in the form of a collection of src/3rdPartyPlugins projects. Some of these might be compilable C++ code such as a Firefox plugin, while others might be just a collection of scripts that just need to be installed in a place that a modeller such as Blender can pick up on. Custom Cmake installer might work well for taking these built libs/scripts into the appropriate places, as well as detecting dependencies and only building/installing what you have supported on your platform. Another other solution would be see if we can coordinate the management and software/build and distribution so that a similar pattern is used by all the various 3rd party plugin projects - to make it easier to OSG users to navigate to, use and contribute to them. The two could not be mutual exclusive: a project could first be mantained externally but adapted to the common layout and then, eventually integrated. I think providing tools and structure to help people to work on the same code would help, expcially during internediate state of development. As far as the repositories share a common layout and there is a simple script to grab the needed components and build, the user could not even perceive there are different repos behind. I have looked at distributed CVS like Bazaar or Mercurial and it seems to me they are more flexible in allowing different management patterns. Regarding CMake build, each project could have his own CMakefile, but could share with other all the macros nedeeded (custom Find etc..) For example the FindOSG and the macros used to detect build options, could be shared among all the projects using OSG. If we were to got the direct integration route, we'll have to be careful about how we manage the integration of the sources, testing and on-going development in such a way as not to increase my own workload. Strategies to mitigate this workload would be to prepare the bodies of work so that they fit seamlessly into the OSG build system/directories structure, so it's just a straight forward task of my pulling in the software, then once they are ready then integrate into core OSG, but not before this. One needn't have a perfected software before integration, but it would at least need to fit comfortably and non-intrusively into the OSG build. A way of doing this prep work would be for us to use the branches section of the OSG svn repository in similar way to how Jeremy and Cedric have been prepping osgWidget and osgAnimation. If you do have software that you feel is a candidate for being part of 3rdPartyPlugins collection then please outline what it is, what files go into it, how it's built, how it might fit into a CMake build system, what its portability and dependencies are. Currently I' m working on our VirtualRome osg4web Firefox and IE Plugin. We can for sure benefit from having more structured firefox example/support . I' m trying to clean up our CMake based build and, I' ll try to see if it can build also Andrea plugin I' m currently using my version of FindOSG. I'm also using CMake for build basic dependencies (tiff,jpeg,png,zip,curl) under windows as I still use VS7. I understand that under Linux the dependencies are found in the system but under windows this is not an
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Andreas Goebel ha scritto:
Try this:
#ifdef XP_WIN
char buf[MAX_PATH];
if ( ::GetModuleFileName(::GetModuleHandle(npOSG4Web.dll), buf,
sizeof(buf)) ) {
char* lastSlash = strrchr(buf, '\\');
if (lastSlash)
*(lastSlash + 1) = '\0';
mShellBase.setInitOption(INIT_OPTION_INSTALLDIR, std::string(buf));
This is tied to my npOSG4Web.dll , you have to substitute your dll
Are you trying to deploy as a Firefox extension?
I' ve managed to build, but did not already inserted in the CMake project.
I like that way of deployment, it gives you also an update mechanism
with signing features
You could easily grab the stuff if you just install my plugin into a new
folder like
D:\Programmi\Mozilla Firefox\firefox.exe -no-remote --profile
D:/Temp/prova1 http://3d.cineca.it/storage/models/gaiani/htdocs/index.html
your firefox -no-remote --profile a new folder
http://3d.cineca.it/storage/models/gaiani/htdocs/index.html
then look into a new folder[EMAIL PROTECTED] for the file
install.rdf
the important lines are updateKey and updateURL and em:id
Simon Hammett schrieb:
On windows you can call GetModuleFileName which retrieves the fully
qualified path to the dll/exe
in which the calling function resides.
Sadly no, it returns the path to firefox.exe, already tried that.
___
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] Reading a node file from http
Andreas Goebel ha scritto: Hi, I am just writing a firefox-plugin for osgViewer, which was surprisingly easy so far. I already have got old bessy in firefox, but it is loaded from a local file. How can I load files from http? I guess that I either have to interact somehow with the firefox plugin-api and stream it somehow to my plugin, or something else that I am not aware of. If someone has done something of the kind, please give me a pointer at where to look for. Not sure if I understood: you are putting osgviewer inside firefox like http://3d.cineca.it/storage/demo_vrome_ajax/virtualrome_3d.html (windows onlysic) or the other way around? If it is the first case, we used curl osg built in functionality to get ive and osg from the web, just pass url to ReadNodeFile I know that it should be possible to ask for firefox a url and get back like a stream, but we decided to go the easiest way. On which platform are you working on? There are several projects for putting osg inside browser and It would be really nice if we coud share efforts. If your release plan is open source (like our), please let we know, we are more than willing to cooperate. We found that most of the trouble comes when you scale both data as well as deploymentplatforms. Our stuff is relatively stable on NVidia recent HW but fails on old ATI and on some intel. Regards Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release -- missing files
It seems that BoundingBox.cpp BoundingSphere.cpp have been removed from the svn ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.7.6 dev release -- missing files
Robert Osfield ha scritto: On Sat, Nov 29, 2008 at 11:19 AM, Luigi Calori [EMAIL PROTECTED] wrote: It seems that BoundingBox.cpp BoundingSphere.cpp have been removed from the Very observant... 10 points. Not observant enough... -20 points. BoundingBox and BoundingSphere now have templated definition to allow double and float versions of bounding volumes to be used in the application. Do you have a build failure? Is so it suggests you need to re-run cmake to update your project files. I did an svn update and I' m pretty sure I did a cmake run and a build, not a re-build. I got linking error and wrongly assumed missing files. Either I did something wrong or VS7 does not recognize he has to rebuild the whole thing. Now cleaned everything and seems to build fine. Sorry for assuming a bug that was not there... Lesson learned: do a clean build before sending any bug. Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to compile OSG with Dev-C++ and 3rdParty source in Cmake!
I' m currently using CMake to build 3rdParty dependencies with VC7.1, if you want to see if it is working for mingw, get either http://3d.cineca.it/storage/packages/3rdPartySrc.zip ot http://3d.cineca.it/storage/packages/3rdPartySrc_packed.zip The latter require you unpack in place the original source zip. Hope it helps Luigi Wang Rui ha scritto: Hi YangXiao Maybe you should try to build required 3rd dependence with mingw (which is the default compiler of Dev-Cpp) first, and then build OSG with CMake. Wang Rui 2008/11/28 YangXiao [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi Everyone: I already setup QT and Dev-C++ on my computer and integrate in Eclipse,But when i compile osg and 3rdParty ,I found only a Visual c++ 8 sp1 binary lib. How to compile OSG with Dev-C++ and 3rdParty source in Cmake? Someone can give me advices! Best regards. YangXiao 好玩贺卡等你发，邮箱贺卡全新上线！ http://cn.rd.yahoo.com/mail_cn/tagline/card/*http://card.mail.cn.yahoo.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org 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] osgswig: the bigobj problem rears its head again
Hartmut Seichter ha scritto: I have a student working on this problem - to add the flag is good and fixes the problem temporarily but in general osgSWIG needs a more scalable approach. Nice to hear, are there any preview of the new wrapping layout? any hints on when this will be available? We are currently stuck with a OSG 2.4 VS7.1 version of osgSwig. I' ve tried suggestion on http://code.google.com/p/osgswig/issues/detail?id=13#c5 and it helps, but still compilation times takes ages. I could also try to switch to VS 2005 even if it seems a bit harder to distribute (needs runtime installation on XP) and also Python 2.5 binary distribution is built with VS7.1 . Any progress on the MixinVector (http://code.google.com/p/osgswig/issues/detail?id=12) issue? H Randolph Fritz wrote: I'm writing this up so that people who aren't cmake experts have a note about this workaround. For my next trick, I tried building this on Windows using Visual C++. After some blundering around, I found that adding /bigobj flag to CMAKE_CXX_FLAGS (edit the field in the cmake GUI--it is one of the advanced options) makes the build go, but only on Visual Studio 2005 and later. MS acknowledges the problem and recognizes that machine-generated code may trigger it in the page at http://msdn.microsoft.com/en-us/library/ms173499(VS.80).aspx. Reported at http://code.google.com/p/osgswig/issues/detail?id=13. Randolph Fritz design machine group architecture department university of washington [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue creating a stand alone DLL
We had somehow similar plroblem with VS 2005 and so are stuck on to 2003.
Try to patch toplevel OSG cmakelists with the patch included
then when you install, it should put release runtime libs in install/bin
(under vs7 are msvcr71.dll msvcp71.dll mfc71.dll)
hope it helps
Geoff ha scritto:
Ok, I am having a problem creating a stand alone DLL that wraps some
functionality of OpenSceneGraph so that I can use it via COM in my
CodeGear C++ Builder app.
I have created the dll, and have been successful in using it on my
development machine, but only in debug mode and only on that machine.
My question is, is there a proper way to create a DLL in Visual Studio
2005, using C++, and encapsulating it so that it can be deployed onto
other machines? Any help would be greatly appretiated as I have
exhausted my knowledge and the deadline is fast approaching.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 9070)
+++ CMakeLists.txt (working copy)
@@ -229,6 +229,11 @@
SET(CMAKE_EXE_LINKER_FLAGS_DEBUG /debug /INCREMENTAL:NO)
ENDIF(NOT OSG_MSVC_DEBUG_INCREMENTAL_LINK)
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL
4 AND ${CMAKE_PATCH_VERSION} LESS 7)
+IF(EXISTS ${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
+ SET(CMAKE_INSTALL_MFC_LIBRARIES 1)
+ INCLUDE(InstallRequiredSystemLibraries)
+ ENDIF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
+
ENDIF(MSVC)
ENDIF(WIN32)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig binary release?
Hartmut Seichter ha scritto: Luigi Calori wrote: Hi Gerwin, I subscribed to SWIG list and read that response too, I' ll try to do some test on that because I really want to be able to run my python app code on more recent OSG I' ll let you know if any success, I' m also applying some mod to make the latest svn compile under msvc 7.1. If you have any suggestion, please let me know. Is someone still working on osgSwig? Yes, still working on it :) - I am actually hiring somebody to work on a new build system Good to hear! The new build system will still be based on CMake? Do you have a preview? like a branch in svn or like? In that case,please let we know, I'm confident the number of people willing to help is 0 :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig binary release?
Phan, Linh H ha scritto:
Hi Luigi,
thanks for your osg.zip! However, whenever I run pickosg.py :
[EMAIL PROTECTED] ~...examples/python]$ ./pickosg.py
Warning: Could not find plugin to read objects from file cow.osg.
It seems that this line:
loadedModel = osgDB.readNodeFile(cow.osg)
always return None. I then explicitly include the osgPlugins-2.6.0 directory
in pickosg.py via:
#!c:/Python25/python.exe
import sys;
sys.path.append('c:\\cygwin-1.7\\usr\\local\\src\\osg\\osgPlugins-2.6.0');
but it still could not find plugin. Do you know what I'm doing wrong?
Not sure, but I have the osg in the PATH environment... like
import os
os.environ['PATH']='c:\\cygwin-1.7\\usr\\local\\src\\osg'+os.pathsep+os.environ['PATH']
if you have unzipped my stuff in c:\\cygwin-1.7\\usr\\local\\src
hope it helps
Luigi
Thank you Luigi,
Linh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luigi Calori
Sent: Friday, November 14, 2008 3:12 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgswig binary release?
Here
http://virtualrome.googlecode.com/svn/trunk/py_code/py25_apps/PyPackages/osg.zip
you can find an osgSwig (from some month ago, with some patches) I has
been built with Visual Stusio 7.1 against OSG 2.5 (included with the zip)
It has been tested with python 2.5 win32 binary, you can test by adding
the folder where you extract the zip to the PYTHONPATH env variable
I'm trying to build osgSwig svn with OSG 2.6 (Viual Studio
compiler)buth there is a still unsolved problem, reported in
http://code.google.com/p/osgswig/issues/detail?id=12#c3
due to substitution of std::vector with osg::MixinVectors (this low
level change prevents wrapper access to functions for building arrays)
I also had to make some changes to build as reported in
http://code.google.com/p/osgswig/issues/detail?id=13
If interested, let me know
Luigi
Phan, Linh H ha scritto:
Hi,
I'm having a real hard time compiling osgswig (gotten from osgswig
svn) for OpenSceneGraph 2.3.4 on Windows using MinGW or cygwin. The
README said that it has been tested with OpenSceneGraph 2.3.4. Does
anyone have a pre-built Windows binary for osgswig that they can make
available? I would really appreciate it.
Thank you,
Linh
___
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] osgswig binary release?
Here http://virtualrome.googlecode.com/svn/trunk/py_code/py25_apps/PyPackages/osg.zip you can find an osgSwig (from some month ago, with some patches) I has been built with Visual Stusio 7.1 against OSG 2.5 (included with the zip) It has been tested with python 2.5 win32 binary, you can test by adding the folder where you extract the zip to the PYTHONPATH env variable I'm trying to build osgSwig svn with OSG 2.6 (Viual Studio compiler)buth there is a still unsolved problem, reported in http://code.google.com/p/osgswig/issues/detail?id=12#c3 due to substitution of std::vector with osg::MixinVectors (this low level change prevents wrapper access to functions for building arrays) I also had to make some changes to build as reported in http://code.google.com/p/osgswig/issues/detail?id=13 If interested, let me know Luigi Phan, Linh H ha scritto: Hi, I'm having a real hard time compiling osgswig (gotten from osgswig svn) for OpenSceneGraph 2.3.4 on Windows using MinGW or cygwin. The README said that it has been tested with OpenSceneGraph 2.3.4. Does anyone have a pre-built Windows binary for osgswig that they can make available? I would really appreciate it. Thank you, Linh ___ 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] osgswig binary release?
Hi Gerwin, I subscribed to SWIG list and read that response too, I' ll try to do some test on that because I really want to be able to run my python app code on more recent OSG I' ll let you know if any success, I' m also applying some mod to make the latest svn compile under msvc 7.1. If you have any suggestion, please let me know. Is someone still working on osgSwig? Thanks Luigi Gerwin de Haan ha scritto: Luigi, As far as the wrapping of osg::MixinVectors goes to support osg 2.6 and on with osgswig, I did get a response from the swig maintainer William Fulton on how to go about on this: ... The easiest is probably to run SWIG -E on std_vector.i and copy paste and change std to osg and vector to MixinVector. You'll see that there is a lot of code developed for some of these target languages and you could provide a much simpler cut down api, something similar to the Java approach, see Lib/java/std_vector.i. I'm not sure I find a timeslot to do this anytime soon. Gerwin On Fri, Nov 14, 2008 at 12:12 PM, Luigi Calori [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Here http://virtualrome.googlecode.com/svn/trunk/py_code/py25_apps/PyPackages/osg.zip you can find an osgSwig (from some month ago, with some patches) I has been built with Visual Stusio 7.1 against OSG 2.5 (included with the zip) It has been tested with python 2.5 win32 binary, you can test by adding the folder where you extract the zip to the PYTHONPATH env variable I'm trying to build osgSwig svn with OSG 2.6 (Viual Studio compiler)buth there is a still unsolved problem, reported in http://code.google.com/p/osgswig/issues/detail?id=12#c3 due to substitution of std::vector with osg::MixinVectors (this low level change prevents wrapper access to functions for building arrays) I also had to make some changes to build as reported in http://code.google.com/p/osgswig/issues/detail?id=13 If interested, let me know Luigi Phan, Linh H ha scritto: Hi, I'm having a real hard time compiling osgswig (gotten from osgswig svn) for OpenSceneGraph 2.3.4 on Windows using MinGW or cygwin. The README said that it has been tested with OpenSceneGraph 2.3.4. http://2.3.4. Does anyone have a pre-built Windows binary for osgswig that they can make available? I would really appreciate it. Thank you, Linh ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] Siggraph Web3D and related technologies BOFs at a glance
Jean-Sébastien Guay wrote: Hi John, Open Scengraph is sort of the Open Inventor functional clone that has a totally free license and is a Web3D technology [hope this assessment is reasonably correct]. For that last part, I think I saw someone doing a web browser plugin that uses OSG to display objects/environments in a web page, streaming the content over the net. I can't remember who or find a link though. Perhaps someone else will be able to refresh my memory. There have been several attempt and think there is already at least one commercial product that use OSG inside a web browser plugin. We have also released our (alpha) release of osg4web that should do exactly that. The plugin is currently used for a virtual model of Rome city. see *http://www.virtualrome.itabc.cnr.it *os The website is still under devfelopment but following direction you should be able to get to the demo (a zip file with firefox, osg and the plugin all pre-packaged) as well as the CVS instruction to get the source code (in case someone is interested) But other than that, OSG can read some Web3D formats, and perhaps more in the future (if the new OpenVRML library is integrated). I do have a “pocket universe” with 29 hours per day for those that have to attend more BOF’s. If you do not run out of CTK (clone toolkit) license, you could send one of your Siggraph clone to look at our poster ;-) I like your sense of humor. :-) If only that were possible... When making my Siggraph schedule I had a massive 4-way conflict on Wednesday, and another smaller conflict on Thursday. It was a hard choice to make. So much to see, and I can't clone myself... J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extract an embedded texture from an .ive
Doug wrote: Hi, I have a model in .ive format with an embedded texture. I need to bring the model into 3dsMax to work on it. I can use osgconv to convert it to one of several different formats that Max can import (obj, dae, etc.), but I also need the texture that is embedded. Can anyone point me in the right direction as to how to extract a texture that is embedded in an .ive file? try osgconv -O OutputTextureFiles file.ive file.osg it should save texture embedded in file.ive Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osgswig
Nice to hear there is someone using osgSWIG! I' m using it along with wxpython mainly under Windows. As a devel environment we are using SPE If you like, I attach a wxosgviewer contributed by Silvano, a collegue of mine, our wxwindows expert. I' m using it also embedded into frames of a wxpython app. We have a Linux-python savvy, try to run under ubuntu, he managed to run after som twiddling of the swig - generated .py files. He was able to run the examples but he got performance problems with this wxosgviewer using wxpython-gtk. I' ve not an osg-python-swig linux env to test on, so not able to dig further Apart from that, I' m currrently using my patched osgSWIG under winxp with not many problems. Thanks in advance, hoping to help Luigi Hartmut Seichter wrote: Hi Luigi, thanks for the patch, I will skim through it ASAP. I was just catching up with all my local osgSWIG patches - I will add a cleaner wxWidgets example (the one in the example/python folder was outdated) - based on osgViewer rather than osgUtil::SceneView. I got everything working on Windows XP, Linux (Ubuntu 8.04 x86_64) and Leopard. Can you submit specific problems you have to the osgSWIG issue tracker? Cheers, Hartmut Luigi Calori wrote: Hi Harmut, I did not know you were still working on osgswig, If it can help, I attach some mods we have done to develop some code based on osgswig We have tried to add wrapping to write node visitor derived python I include all our mods, (we have also mod cmake to covert .dll to pyd) It is tested under win XP with osg 2.5 We have also tried it under Linux and it compiles correctly but has some runtime problems We have also integrated osg window with wxpython, it is working under windows but bad performance under linux I attach a patch built with tortoise patch Hope it helps Luigi Hartmut Seichter wrote: Nope we are around and kicking. Unfortunately nothing to show yet: I am working on getting most of the nested classes integrated. Hartmut Gerrick Bivins wrote: Hi all, Does anyone know if osgswig is being maintained anymore? Site on google code doesn’t seem like it’s being updated anymore. Has the project moved or is it just dead? biv ___ 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 ''' wxOsgViewer: osgViewer on a wxPanel this module also provide a simple wxOsgFrame / wxOsgApp useful for testing From Silvano Imboden --- CINECA ''' import wx import wx.py import wx.glcanvas import osg import osgDB import osgGA import osgViewer #-- class Canvas(wx.glcanvas.GLCanvas): def __init__(self,parent,id): style = wx.WANTS_CHARS | wx.FULL_REPAINT_ON_RESIZE wx.glcanvas.GLCanvas.__init__(self, parent, id, wx.DefaultPosition, wx.DefaultSize, style ) # --- Timer - self.timer = wx.Timer(self,-1) self.timer.Start(1) # --- Viewer - self.viewer = osgViewer.Viewer() self.viewer.addEventHandler(osgViewer.StatsHandler()) self.gw = None self.gw = self.viewer.setUpViewerAsEmbeddedInWindow(0,0,800,600) #print self.gw self.viewer.setThreadingModel(osgViewer.ViewerBase.SingleThreaded) self.viewer.setCameraManipulator(osgGA.TrackballManipulator()) ss = self.viewer.getCamera().getOrCreateStateSet() self.viewer.addEventHandler( osgGA.StateSetManipulator(ss) ) loadedModel = osgDB.readNodeFile(cow.osg) if not loadedModel: print could not find any cow --- please set the OSG_FILE_PATH env var self.viewer.setSceneData(loadedModel) # --- Bindings - self.Bind(wx.EVT_TIMER, self.onTimer, id=self.timer.GetId() ) self.Bind(wx.EVT_ERASE_BACKGROUND, self.onEraseBackground) self.Bind(wx.EVT_PAINT, self.onPaint) self.Bind(wx.EVT_SIZE, self.onSize) self.Bind(wx.EVT_KEY_DOWN, self.onKeyDown) self.Bind(wx.EVT_KEY_UP
Re: [osg-users] Osgswig
Hi Harmut, I did not know you were still working on osgswig, If it can
help, I attach some mods we have done to develop some code based on osgswig
We have tried to add wrapping to write node visitor derived python
I include all our mods, (we have also mod cmake to covert .dll to pyd)
It is tested under win XP with osg 2.5
We have also tried it under Linux and it compiles correctly but has some
runtime problems
We have also integrated osg window with wxpython, it is working under
windows but bad performance under linux
I attach a patch built with tortoise patch
Hope it helps
Luigi
Hartmut Seichter wrote:
Nope we are around and kicking. Unfortunately nothing to show yet: I
am working on getting most of the nested classes integrated.
Hartmut
Gerrick Bivins wrote:
Hi all,
Does anyone know if osgswig is being maintained anymore? Site on
google code doesn’t seem like it’s being updated anymore.
Has the project moved or is it just dead?
biv
___
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
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 117)
+++ CMakeLists.txt (working copy)
@@ -171,3 +171,11 @@
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+
+##to get all the variables of Cmake
+GET_CMAKE_PROPERTY(MYVARS VARIABLES)
+FOREACH(myvar ${MYVARS})
+ FILE(APPEND ${CMAKE_CURRENT_BINARY_DIR}/AllVariables.txt
+ ${myvar} --${${myvar}}-\n
+ )
+ENDFOREACH(myvar)
\ No newline at end of file
Index: CMakeModules/FindOSG.cmake
===
--- CMakeModules/FindOSG.cmake (revision 117)
+++ CMakeModules/FindOSG.cmake (working copy)
@@ -1,16 +1,17 @@
# Locate gdal
# This module defines
# OSG_LIBRARY
-# OSG_FOUND, if false, do not try to link to osg
+# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
-# Edited By R.C.Molenaar to include debug versions
+SET(OSG_DIR CACHE PATH set to base osg install path)
FIND_PATH(OSG_INCLUDE_DIR osg/Node
+${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
@@ -24,38 +25,40 @@
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
-/cygdrive/c/Program Files/OpenSceneGraph/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
-
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
-FIND_LIBRARY(${MYLIBRARY}
-NAMES ${MYLIBRARYNAME}
+FIND_LIBRARY(${MYLIBRARY}_DEBUG
+NAMES ${MYLIBRARYNAME}d
PATHS
+${OSG_DIR}/lib/Debug
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/debug
$ENV{OSG_DIR}/lib
-$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
-FIND_LIBRARY(${MYLIBRARY}_DEBUG
-NAMES ${MYLIBRARYNAME}d
+FIND_LIBRARY(${MYLIBRARY}
+NAMES ${MYLIBRARYNAME}
PATHS
+${OSG_DIR}/lib/Release
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
@@ -63,46 +66,84 @@
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
+#MESSAGE(--${${MYLIBRARY}}--${${MYLIBRARY}_DEBUG}--)
+IF( NOT
Re: [osg-users] Osgswig
well not from me... I do not know Java well... but adding a new
language wrapping in CMake should not be too difficult.
Gerrick Bivins wrote:
Any plans for building java binding with Cmake?
On 6/27/08 8:27 AM, Luigi Calori [EMAIL PROTECTED] wrote:
Hi Harmut, I did not know you were still working on osgswig, If it can
help, I attach some mods we have done to develop some code based on osgswig
We have tried to add wrapping to write node visitor derived python
I include all our mods, (we have also mod cmake to covert .dll to pyd)
It is tested under win XP with osg 2.5
We have also tried it under Linux and it compiles correctly but has some
runtime problems
We have also integrated osg window with wxpython, it is working under
windows but bad performance under linux
I attach a patch built with tortoise patch
Hope it helps
Luigi
Hartmut Seichter wrote:
Nope we are around and kicking. Unfortunately nothing to show yet: I
am working on getting most of the nested classes integrated.
Hartmut
Gerrick Bivins wrote:
Hi all,
Does anyone know if osgswig is being maintained anymore? Site on
google code doesn¹t seem like it¹s being updated anymore.
Has the project moved or is it just dead?
biv
___
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
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 117)
+++ CMakeLists.txt (working copy)
@@ -171,3 +171,11 @@
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+
+##to get all the variables of Cmake
+GET_CMAKE_PROPERTY(MYVARS VARIABLES)
+FOREACH(myvar ${MYVARS})
+ FILE(APPEND ${CMAKE_CURRENT_BINARY_DIR}/AllVariables.txt
+ ${myvar} --${${myvar}}-\n
+ )
+ENDFOREACH(myvar)
\ No newline at end of file
Index: CMakeModules/FindOSG.cmake
===
--- CMakeModules/FindOSG.cmake (revision 117)
+++ CMakeModules/FindOSG.cmake (working copy)
@@ -1,16 +1,17 @@
# Locate gdal
# This module defines
# OSG_LIBRARY
-# OSG_FOUND, if false, do not try to link to osg
+# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
-# Edited By R.C.Molenaar to include debug versions
+SET(OSG_DIR CACHE PATH set to base osg install path)
FIND_PATH(OSG_INCLUDE_DIR osg/Node
+${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
@@ -24,38 +25,40 @@
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
-/cygdrive/c/Program Files/OpenSceneGraph/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
-
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
-FIND_LIBRARY(${MYLIBRARY}
-NAMES ${MYLIBRARYNAME}
+FIND_LIBRARY(${MYLIBRARY}_DEBUG
+NAMES ${MYLIBRARYNAME}d
PATHS
+${OSG_DIR}/lib/Debug
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/debug
$ENV{OSG_DIR}/lib
-$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
-FIND_LIBRARY(${MYLIBRARY}_DEBUG
-NAMES ${MYLIBRARYNAME}d
+FIND_LIBRARY(${MYLIBRARY}
+NAMES ${MYLIBRARYNAME}
PATHS
+${OSG_DIR}/lib/Release
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
@@ -63,46 +66,84 @@
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM
Re: [osg-users] New versions of OSG and configuring CMake
I presume you are workng on Windows and change build folder.If you just update from svn you should not be forced to configure again. Anyway, if you want to keep your previous cmake setup, just keep the CmakeCache.txt file. Otherwise,you can force your defaul configuration by adding -Dvar=value tou your cmake command line. I usually store my default setup in a cmake command line then run cmakesetup to eventually change options afterwards Hope it helps Brian wrote: Hi, I must be doing something wrong when using CMakeSetup. Every time I download a new release of OSG, I have to go through the steps of reconfiguring CMake to point to all the directories for the various extras (GDAL, FLTK, etc.) I've tried setting up environment variables with names like FLTK_LIBRARY or FLTK_INCLUDE_DIR in the hopes that CMake will read those and use them to help make my life easier, but it's all in vain. Is there an easy way to automatically configure CMake? Thanks, Brian ___ 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] problem with multitexturing in latest svn?
Thanks Robert, an svn update fix the problem ... odd to find out there are so few platform where singlethread is selected as default mode ... time to buy another pc... Luigi Robert Osfield wrote: Hi Luigi, I have spotted an oddity in the osgViewer::Render::cull_draw() compile ordering, on fixing the ordering I can now run osgviewer --SingleThreaded on your model and get the correct output. Could you do an svn update and see how you get on. Robert. On Tue, May 20, 2008 at 9:09 AM, Robert Osfield [EMAIL PROTECTED] wrote: Good detective work, when I run osgviewer --SingleThreaded I get the black result, so it's certainly not a driver issues/platform issue. The only difference between 2.4. and 2.5. I can think that has an effect on initialization order is compile traversal, as I moved this to run during the draw of the first traversal. I will investigate at my end as at least I can reproduce the problem now. ___ 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] Unable to load plugins that use 3rd party libraries
I' m currently using vs7.1 and vs8 current svn using a cmkae based dependency build of zlib-1.2.3 tiff-3.7.4 libpng-1.2.24 jpeg-6b freetype-2.3.5 curl-7.18.1 They seem work for me, they should be used in osg build by setting ACTUAL_3DPARTY_DIR:FILEPATH=path where have been installed or mike dependencies If you are interested let me know, I can send the zip of my source dep tree, the build time of these dep is small compared with osg itself Luigi Colin Rayment wrote: Sorry for raising this old chesnut again - I've tried building and running the OSG 2.4.0 and have problems in loading some of the plugins when running some of the examples, specifically those related to freetype, jpeg and gif. I'm running on Windows XP using VS2005. I'm able to load all the other plugins and all the appropriate dlls have been successfully built and do exist. I'm linking in the latest prebuilt 3rd party binaries from osgToy. The problem seems to be related to 3rd party libraries as when I built the freetype libraries from the original source the freetype plugin worked ok. Has anyone else experienced this and if so how have they solved the problem - I don't really want to have to build all the 3rd party libraries from scratch. Colin Rayment This email has been scanned for all known viruses by the MessageLabs Email Security System. Systems Engineering Assessment Ltd - Beckington Castle, 17 Castle Corner, Beckington, Frome, Somerset, BA11 6TA, UK is registered in England and Wales with the company number 2430846. The contents of this email (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this email any disclosure, copying, distribution or use of its contents is strictly prohibited. You should notify the sender immediately and then delete it (including any attachments) from your system. Please help out the environment by only printing this e-mail if absolutely necessary - Thank You. ___ 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] [Blender and OSG]
I was aware of blender -osg export, see http://projects.blender.org/projects/osgexport/ not sure if it is the most up to date Jean-Baptiste Authesserre wrote: Hi, I would like to use blender to create my 3D models. Is that possible to use blender files .blend with osg? I compiled by myself osg by using Cmake for the configuration of the Visual studio project. I found no mention about blender during this configuration step. After the compilation, there exist in the generated plugin folder the file osgdb_3ds.dll, which I suppose allow me to use 3DSMAX file. But I don't find anything about blender. Could anybody help me? Best regards, Jean-Baptiste. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++ 2008: Missing .lib extension for internal dependencies causes linker error
Hi, I' ve been mostly offline for the last 3days, I did not personally test 2.6 yet (I' m willing to do soon) but do not think putting a .lib extension would harm windows builds. I personally do not remember having set up this ide special case, but probably 2.4 was more tolerant than 2.6 on not specifying extension in linking with library already built in the same solution. I' m not a cmake guru, so other (Bill) could explain. As far as I' m concerned, no problem in adding .lib, go ahead with the patch. Jean-Sébastien Guay wrote: Hello Robert, With the aim of tracking down the introduction of this workaround I've gone through the svn logs for OsgMacroUtils.cmake and it looks like the revision of importance is 7865 - this just so happens to be the latest update to OsgmacroUtils so is a pretty recent change: Hmm, interesting. But if you look at the TARGET_LINK_LIBRARIES line before the change, it still did not have the .lib extension (which is the problem here - it should have it). So that particular change is not the source of the problem. So essentially, we have: * before rev 7865 === libraries did not have .lib * after rev 7865 === libraries have .lib only when not building from the IDE (i.e. when building with nmake) * what we want (which fixes it for CMake 2.6 and does not adversely affect CMake 2.4) === libraries have .lib in all cases As far as I can see, this will a) fix the build for CMake 2.6 b) have no effect for CMake 2.4 (tested at work yesterday) c) have no effect for nmake (it's what was added to make it work on nmake) Of course, I'd like to know if it will break something else. But honestly, I think we cover pretty much 100% of the possible cases on Windows with MSVC here... And no one has stepped up to say it will break it for them. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++ 2008: Missing .lib extension for internal dependencies causes linker error
.
In the simple case, I just tested with 2.4.8 and 2.6.0 this works fine:
add_executable(bar foo.c)
target_link_libraries(bar foo)
foo.lib is linked for both vs IDE and makefiles.
Let's go back to the macro LINK_INTERNAL. I think the issue was
trying to get around a bug in 2.4.7. That should all be fixed in 2.4.8.
So, I think you don't need the macro at all for 2.4.8 and greater.
It should just be:
target_link_libraries(osgDB osg OpenThreads)
Are all the input libraries to LINK_INTERNAL things that CMake is
building?
Hi Bill, I think the LINK_INTERNAL macros is being used only for
internal libs.
The current cmake build is the result of several layers of mods though,
so some care has to be taken.
something that could complicate thinghs that you could not be aware of
is the use of non standard hack for placing libs and dll in bib and
lib instead of bin/Debug or bin/Release
as you can see from the lines like
IF(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME}
PROPERTIES PREFIX ../bin/${OSG_PLUGINS}/)
ELSE(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME}
PROPERTIES PREFIX ../../bin/${OSG_PLUGINS}/ IMPORT_PREFIX ../)
ENDIF(NOT MSVC_IDE)
Could this hack fool the automatic linkage inference of CMake in 2.4.8
or 2.4.6 ?
I' m not a cmake guru, just helped in the past to assemble the build by
infering from other code and the available CMake doc
The main reason to use Macros was to inserta a level of abstraction
hiding platform dependent CMake code as well as possible workaround for
CMake problems: LINK_INTERNAL should behave exactly as
target_link_libraries , over time the implementation has become more
complicated as some workaround has been implemented.
The CMakeLists remained mostly unchanged though.
I could try a windows ide build test making LINK_INTERNAL call
straight target_link_libraries and see waht happens but can not test
other windows build platforms.
Thanks for the help
Luigi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OS X / cmake-problems, was: Re: OpenSceneGraph-2.3.10 dev release tagged
I think the problem with recent changes not showing headers in
VisualStudio, is related to a typo:
the ELSEIF in this context is bad:
so, instead of reverting patches, at least under visualstudio, one can
substitute
ELSEIF(APPLE) with ELSE(APPLE)
so
IF(APPLE)
SET(ADD_LIBRARY_HEADERS )
ELSE(APPLE)
SET(ADD_LIBRARY_HEADERS ${LIB_PUBLIC_HEADERS} )
ENDIF(APPLE)
then the headers appers again
Hope it helps
Robert Osfield wrote:
Hi Eric,
Thanks for chiming in.
Looks like I'll have to revert the header change then... and leave
resolution of the problems that Stephan has seen to a later CMake
OSG revision.
Robert.
On Wed, Apr 23, 2008 at 11:06 PM, E. Wing [EMAIL PROTECTED] wrote:
Hi, sorry, I've been really busy with other work (day job) which happens to
have no OSG or CMake at the moment so it has been hard for me to finish
fixing everything up. I have some stuff written, but it is incomplete and am
still trying to get over various CMake bugs which requires me to write
additional unit tests for CMake to help the authors isolate things.
I'm thinking I could use some help, particularly in the area of testing. So
if there are any volunteers, please let me know. I've put up a quick/dirty
snapshot things on a Mercurial repo. I probably should have spent more time
making a proper bridge to Subversion so I can also refresh against the OSG
SVN head (so help is welcome there too).
I can fix these warnings when I comment out the line
${LIB_PUBLIC_HEADERS} from the CMakeLists.txt-files (here for osg):
ADD_LIBRARY(${LIB_NAME}
${OPENSCENEGRAPH_USER_DEFINED_DYNAMIC_OR_STATIC}
# ${LIB_PUBLIC_HEADERS}
AlphaFunc.cpp
.
.
.
I don't know if this change can break other platforms.
Ironically, this will break the the Mac framework support. The CMake proper
thing to do is include the headers as is. I'm not sure why you're seeing
those warnings. We might need to file a CMake bug. It could be the
extensionless headers are confusing things, but I haven't noticed the error
myself.
Anyway let me know if you can help out.
Thanks,
Eric
___
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] Windows src/osgPlugins/CMakeLists.txt entry
Hi Robert, I' m not sure to understand exactly what do you require.
I' m using a CMake based dependency build from source that mimic Mike layout
I have built curl statically using CMake under windows XP
Then, In order to use it from OSG I had to modify the curl
CMakeLists.txt (included) I also added an advanced option to set up the
static case.
It would be better to have the Find ... code to detect if the found curl
lib is static or dynamic but I do not know how to.
Hope it helps, let me know
Robert Osfield wrote:
Hi Guys,
The libcurl build in the 3rdParty binaries maintained by Mike and the
associated src/osg/Plugins/curl/CMakeLists.txt is something that
requires settling before 2.4. My expectation is that we'd need to
modify CMakeModules/Find3rdPartyDepdenencies.txt and
src/osg/Plugins/curl/CMakeLists.txt to set up the appropriate options
for build under Windows with the 3rd party binaries, yet still leave
the door open to people building libcurl outside of the 3rd party
dependencies.
If we don't have feedback on this very soon then this part of the OSG
build under Windows may have to go out broken. I can't fix this
myself I really do need guidance from Windows users on this.
Thanks in advance,
Robert.
On Wed, Apr 16, 2008 at 4:19 PM, Mike Weiblen [EMAIL PROTECTED] wrote:
Hi Robert and all,
wrt to CMake and cURL...
Attached is the script I use to launch CMake on Windows.
You'll note that script encapsulates cmdline args to override some of
the existing CMakeLists defaults for my preferences. Relevent to this
thread, I also use those args to point to the location of my curl
libs. Not yet being expert in CMake, this is the easiest way for me
to automate my preferences, especially when some of my prefs are not
community-shared defaults.
While I like the idea of the curl lib and plugin, I'm not yet using
that feature myself, so I dont have a self-defined set of requirements
for acceptable binaries. (I do know the current binaries are broken,
I'm looking into rebuilding them now)
I would appreciate some help/clarification for curl in the 3rdParty binaries:
- is the desire for them to be static or dynamic libs? I dont much
care, esp if it's just flipping a switch in the curl buildsystem.
- curl stability on XP and Vista. I dont use Vista if I can avoid it,
so I'm not testing there. If someone could identify the exact curl
version that would be acceptible for XP and Vista, I'll be glad to
build it.
(Luigi, I know you posted some info previously, I'm still going thru my archive)
thanks in advance.
-- mew
On Wed, Apr 16, 2008 at 4:25 AM, Robert Osfield
[EMAIL PROTECTED] wrote:
Hi All,
Over the last week there have been amendments to the
OpenSceneGraph/src/osgPlugins/CMakeLists.txt posted to the osg-users
list, these amendments hardwire the CMakeLists.txt file to link to
static versions of the libcurl under Windows. While supporting static
build is perfectly acceptable idea, forcing it as the way to link to
libcurl isn't as not all users will want to use libcurl this way.
Would it be possible for Windows/CMake experts to have a bash at
provide a src/osgPlugins/CMakeLists.txt that automatically picks up on
whether a static or dynamic version of lib curl is used, or if this
isn't possible have a CMake compile option for controlling this.
I'm planning to make a 2.3.9 today as 2.3.8 was broke under Windows,
it'd be good to roll the above fixes in to this release.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Mike Weiblen -- Austin Texas USA -- http://mew.cx/
___
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
#this file is automatically generated
OPTION(CURL_IS_STATIC on if curl is a static lib ON)
MARK_AS_ADVANCED(CURL_IS_STATIC)
IF(WIN32)
SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG ${CMAKE_SHARED_LINKER_FLAGS_DEBUG}
/NODEFAULTLIB:MSVCRT)
IF(CURL_IS_STATIC)
ADD_DEFINITIONS(-DCURL_STATICLIB)
SET(TARGET_EXTERNAL_LIBRARIES ws2_32 winmm)
ENDIF(CURL_IS_STATIC)
ENDIF(WIN32)
INCLUDE_DIRECTORIES( ${CURL_INCLUDE_DIRS} )
SET(TARGET_SRC ReaderWriterCURL.cpp )
SET(TARGET_LIBRARIES_VARS CURL_LIBRARY )
end var setup ###
SETUP_PLUGIN(curl)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows src/osgPlugins/CMakeLists.txt entry
I' ve done recentrly some experiments with curl under windows.
I' ve managed to build curl with cmake under windows. In that case, we
can get some info on configuration, so we can decide if it was a satic
or a dinamic build.
Otherwise I do not know a way to infer from the .lib found if it is a
static or a dnamic one.
If someone knows how to detect if a .lib is static or dynamic, that test
could be added to the CMakeLists curl plugin file.
currently I just assumed the win32 curl lib was static (see cmakelist
included)
An option could be added to let the user select.
Is the static / dynamic a win32 only option?
Thanks,
Luigi
Robert Osfield wrote:
Hi All,
Over the last week there have been amendments to the
OpenSceneGraph/src/osgPlugins/CMakeLists.txt posted to the osg-users
list, these amendments hardwire the CMakeLists.txt file to link to
static versions of the libcurl under Windows. While supporting static
build is perfectly acceptable idea, forcing it as the way to link to
libcurl isn't as not all users will want to use libcurl this way.
Would it be possible for Windows/CMake experts to have a bash at
provide a src/osgPlugins/CMakeLists.txt that automatically picks up on
whether a static or dynamic version of lib curl is used, or if this
isn't possible have a CMake compile option for controlling this.
I'm planning to make a 2.3.9 today as 2.3.8 was broke under Windows,
it'd be good to roll the above fixes in to this release.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#this file is automatically generated
IF(WIN32)
SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG ${CMAKE_SHARED_LINKER_FLAGS_DEBUG}
/NODEFAULTLIB:MSVCRT)
ADD_DEFINITIONS(-DCURL_STATICLIB)
SET(TARGET_EXTERNAL_LIBRARIES ws2_32 winmm)
ENDIF(WIN32)
INCLUDE_DIRECTORIES( ${CURL_INCLUDE_DIRS} )
SET(TARGET_SRC ReaderWriterCURL.cpp )
SET(TARGET_LIBRARIES_VARS CURL_LIBRARY )
end var setup ###
SETUP_PLUGIN(curl)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CURL builds: was :Re: Testing of OSG SVN in prep for 2.3.8 dev release
Hi Mike,Robert and Maciej
There is a CMake based setup for recent Curllib in
(https://dev.openwengo.com/svn/openwengo/owbuild/trunk/libs-3rdparty-cmakelists/curl
)
It is configured for building curlib 7.16.2 as a dll under windows but
it seems can be tweaked to compile the latest curlib (I' ve found
curl-7.18.1.tar.gz)
as a static lib.
I' ve downaloaded the latest OSG svn, applied the Maciej mod to cmake
file and it seems to be working under my WinXP Pro
(removed the old net plugin and accessed a web served osg file.
I attach the curl plugin CMakeLists file
If someone is interested, I can try to document the process of cmake
building curl statically, it is quite simple:
I had to disable the linking of SSLEAY and OPENSSL in order to not
introduce a further dep.
FYI I am also using cmake based builds for
freetype-2.3.5,jpeg-6b,libpng-1.2.24,zlib-1.2.3,tiff-3.7.4 under WinXP.
Using CMake, it should be easier to provide cross platform source based
build instructions for the basic OSG dependencies.
If interested, let me know
Hope it helps
Luigi
Robert Osfield wrote:
Hi Mike et al.
On Sat, Apr 12, 2008 at 7:15 PM, Mike Weiblen [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
fwiw I'm planning to do a fair bit of 3rdParty lib rework/update this
coming week...
I have be informed that libcurl needs a different version under Vista
vs XP, I don't know of all the details though. If this turns out to
be the case and then we'll be faced with the issue of which to link
against - or do you use a dynamic library version and provide both
version? Or do we wait for an upcoming rev of libcurl in hope that
this might unify things... Either way we'll need to check up on the
exact situation. It might be that only some features of libcurl
aren't working fine across XP and Vista, but if the OSG doesn't use
these then we might just be fine.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#this file is automatically generated
IF(WIN32)
SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG ${CMAKE_SHARED_LINKER_FLAGS_DEBUG}
/NODEFAULTLIB:MSVCRT)
ADD_DEFINITIONS(-DCURL_STATICLIB)
SET(TARGET_EXTERNAL_LIBRARIES ws2_32 winmm)
ENDIF(WIN32)
INCLUDE_DIRECTORIES( ${CURL_INCLUDE_DIRS} )
SET(TARGET_SRC ReaderWriterCURL.cpp )
SET(TARGET_LIBRARIES_VARS CURL_LIBRARY )
end var setup ###
SETUP_PLUGIN(curl)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Hints on Python wrappers (was osgPython (SWIG) 2.2.0)
Sorry, got no answer, so try to repost I' m interested in using OSG from Python or other scripted languages. After some searching and testing I found osgswig and tried that path (still unsure which is the best script wrapper for OSG to use) Using osgswig I found some bugs and added some nodes that were missing. (posted to tehe main site at http://code.google.com/p/osgswig/issues/detail?id=5 ) My questions: 1) opinions on which route to go for wrapping, (know there are wrappers based on introspection, I' ve tried to use them but found few examples) 2) In osgswig there is a working example of a python pick handler that subclass from osgGA.GUIEventHandler. I would like to subclass from osg.NodeVisitor without success. Is this something doable in osgswig or in other wrappers? 3) are there plans for supporting wrappers into core osg? 4) is osg-users the right place to write for issues regarding script language wrappers? Thanks in advance Luigi Calori ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgPython (SWIG) 2.2.0
Thank you very much... it worked!!
either
%inline %{
osg::Geode *NodeToGeode2(osg::Node *b) {
return dynamic_castosg::Geode*(b);
}
%}
or
%extend osg::Node {
virtual osg::Geode* asGeode() {return dynamic_castosg::Geode*(self);}
};
The Cmake projects worked fine (just some mods to standard FindOSG), I
spent some time to find out how to install correctly into site_packages
If I' m correct, the dll must be renamed .pyd and the generated py must
be copied inside the site_packages
I noticed the compile time of the _osg project is quite slow (at least
on my machine) do you think it would be possible to split the big osg
wrapper into smaller pieces to
both speed up build time and separate original (yours) and added (mine)
Do you plan to insert your CMake files into the osgswig svn?
Having things in svn will really help a lot the development
I' m planning to experiment further and then try to add site_packages
installation to cmake if do not find a better way to work
thanks again
Luigi
René Molenaar wrote:
I read this in the swig manual:
If you need to cast a pointer or change its value, consider writing
some helper functions instead.
see: http://www.swig.org/Doc1.3/Python.html
%inline %{
/* C++-style cast */
Foo *BarToFoo(Bar *b) {
return dynamic_castFoo*(b);
}
%}
You can also create the member function node.asGeode() in a similar
way with swig. This is a safe and handy method. There might be other
options... this way you would need to use swig, and can't use the
binary version.
René
2008/2/13, Luigi Calori [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
René Molenaar wrote:
Swig wrappers for OpenSceneGraph Python and Perl
These files are part of: The VRmeer Library - Delft University of
Technology
The files are based on osgswig (http://code.google.com/p/osgswig/)
with some additions and CMake files.
Thanks for the post, I' ll try them as soon as possible, I' m
currently
try to learn python and osgswig using the binary version under
windows XP
I stumbled upon a problem:
I would like to parse the one scene, so willing to use something
like:
node = osgDB.readNodeFile('cow.osg')
while node.className() == 'Group':
print node.className()
node = node.asGroup().getChild(0)
print node.className()
The problem arise when getChild() returns a Geode.
There is no --- node.asGeode() method so I have no idea of
how to
get the handle of a Geode in the scene.
Sorry for my dumbness, any help really appreciated,
Luigi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
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] ANN: osgPython (SWIG) 2.2.0
René Molenaar wrote:
Swig wrappers for OpenSceneGraph Python and Perl
These files are part of: The VRmeer Library - Delft University of
Technology
The files are based on osgswig (http://code.google.com/p/osgswig/)
with some additions and CMake files.
Thanks for the post, I' ll try them as soon as possible, I' m currently
try to learn python and osgswig using the binary version under windows XP
I stumbled upon a problem:
I would like to parse the one scene, so willing to use something like:
node = osgDB.readNodeFile('cow.osg')
while node.className() == 'Group':
print node.className()
node = node.asGroup().getChild(0)
print node.className()
The problem arise when getChild() returns a Geode.
There is no --- node.asGeode() method so I have no idea of how to
get the handle of a Geode in the scene.
Sorry for my dumbness, any help really appreciated,
Luigi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgPython (SWIG) 2.2.0
I would also be interested in Cmake osgswig building I, as a novice in both python and Lua, would greatly appreciate any script example usage. I' m trying to use the binary version of osgSwig, it seems working well but some further python example would really help Is this the right place to ask question regarding osgswig? thanks in advance and compliments for the work Luigi René Molenaar wrote: I just separated an osgswig cmake project from our larger Library. Tomorrow I can try to build some of your version of the wrappers in this structure. (our version has changed a version of yours here and there). You can add me to the Project members of the google code page? I saw another member on there, I worked with him to create our current version. He makes great use of osgPython in combination with IPython gtk and the rest of our Library. Cheers, René 2008/2/12, Hartmut Seichter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi there, I updated the SWIG based python bindings. http://code.google.com/p/osgswig/ Please test and break it. Some, hopefully, clarifying words about licensing: The generating scripts are under the MIT license. The modules directly derived from OpenSceneGraph are following the OSGPL v0.0 or the appropriate licenses. The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are using this module you also agree to follow the licensing terms of the GPLv2. Shameless plug :) If you need a commercial license for osgART or features beyond marker based tracking please contact ARToolworks Inc. (http://www.artoolworks.com/) Cheers, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg python binding
I' m also interested in scripting: tried introspection based osgLua and osgPython with not much success. Also tried binary version of osgSwig (version 2.1.11 I presume), was able to run viewer.py but not much more. I did not found many python examples, neither in any of the project above, Is it because the wrapping is not yet stable or like the example are left as an exercise to the reader Any available example scripts would be really appreciated by a novice python user as I am. Iwould also be very intersted in CMake building, and willing to help expecially under Windows platform. Thanks Luigi Hartmut Seichter wrote: Hi Cedric, I am the developer of osgSWIG. You can find scripts in src/Languages/Python 1) run wrap.sh 2) run compile.sh I know this is very much suboptimal and might not even work on your distribution. I am working on a CMake based build system which probably solves quite a lot of problems. There is also one big issue I am facing with one of the headers in core OSG. You might stumble upon the same thing, there are three const variables in osg::Vec3f which use the C++ style of declaration and are not supported by SWIG 1.3.30 /H Cedric Pinson wrote: I have found http://code.google.com/p/osgswig/ to bind osg to python, i did not try yet. I would like to know if someone use it on linux. I would like feedback Cedric -- Hartmut Seichter PhD (HKU), Dipl.-Ing. (BUW) www.technotecture.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] help on impostors
I' m trying to evaluate the usage of impostor nodes. It seems to me the impostors are not using transparency. Are there other example apart from osgimpostor, possibly saved as .osg files? thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] using jpeg textures
Hello, I' m trying to build a terrain + models database available throug web, in order to minimize bandwith, so I' ve built the terrain using the following optiions: osgdem --image-ext jpeg --RGB_24 -O JPEG_QUALITY 20 compressImageData ... -o prova.ive this way in all the .ive generated, the texture should be compressed in jpeg and included in the file. Results are consistent and the individual pages much smaller than the ones built using .dds default compression osgdem --compressed .. -o prova1.ive the problem arise when running those dataset: unfortunately, the memory footprint of the jpeg one is much bigger than the dds one (3-5 times bigger) (desumed by what windows reports as process size) and , while in the first step the jpeg one si faster to load (adsl testing) rapidly , because of the memory used, it starts slowing down up to becoming almost unusable. I tried to dig into the code, trying to compare the jpeg an dds loader codes, but it seems to me they are similar, apart from the jpeg is probably keeping uncompressed image data around. I tried also to force setting internalFormatMode=USE_S3TC_DXT5_COMPRESSION;unRefImageDataAfterApply=TRUE inside the ive loader without success (similarly to what Laurent expose on another thread) I also am trying to add a dds on the fly compression step to the jpeg loader but up to now it is simply too slow (the code has been taken from osgconv compress visitor) You can experiment the two examples: dds: osgviewer http://3d.cineca.it/storage/terrain/demo/out_run_2/demo2.ive jpeg osgviewer http://3d.cineca.it/storage/terrain/demo/out_run_1/prova.ive on my win XP machine (osg 2.2 nad vpb 0.9) the first stay round 50-60 Mb of memory, the second quickly go over 300 500 Mb Thanks in advance for any hints Luigi Calori Robert Osfield wrote: HI Laurent, The ReaderWriter::Options is the wrong place to go look for forcing texture compression, as this only affects the loaders, and none of these are set up to doing anything when being passed these string you are trying. I don't understand where you got this idea from. osgconv has support for doing texture compression. Try: osgconv mymodel.flt --compress-dxt3 mymodel.ive Robert. On Dec 7, 2007 4:09 PM, Laurent Di Cesare [EMAIL PROTECTED] wrote: Hello, I'm encountering performance problems when loading lots of textures in my scene. I've been trying to set options like internalFormatMode to USE_S3TC_DXT5_COMPRESSION, but I can't see any effect, and wonder what syntax I should be using: If I call osgDB::ReaderWriter::Options* pOptions = new osgDB::ReaderWriter::Options(); pOptions-setObjectCacheHint( osgDB::ReaderWriter::Options::CACHE_ALL ); pOptions-setOptionString( internalFormatMode=USE_S3TC_DXT5_COMPRESSION;unRefImageDataAfterApply=TRUE;useHardwareMipMapGeneration=FALSE ); I can't see much of a result, and I've been crawling in the source code to try to find where this is parsed without success. I've delved a little into the code and found that only ive and osg plugins seem to handle these options. Would it be possible to parse these options at the osgdb level rather than the plugin level? Also, I am not sure whether it is possible to cache Texture objects in osgdb. Images are correctly cached, but operations like rescaling textures seem to be called several times for the same image. Is there a way for me to explicitly call a cache on the Texture objects to avoid such rescaling? Thanks in advance, Laurent Di Cesare. ___ 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] osgconv
Argentieri, John-P63223 wrote: Robert, osgconv --compressed still doesn't work in windows. Here's the output from osg 2.2: /Failed to create pbuffer, failing back to normal graphics window./ /Error: Unable to create graphis context - cannot run compression/ /Data written to 'xxx.ive'./ John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org I thought thiw had been addressed, see http://lists.openscenegraph.org/htdig.cgi/osg-submissions-openscenegraph.org/2007-August/000110.html If it still does not work for you try the (ugly) hack of creating a dummy viewer inside osgconv (see diff included) hope it helps. P.S. if this solve your problem , mail back to Robert Thanks Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN version of OpenSceneGraph
Williams, Blake wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Wednesday, September 12, 2007 10:19 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN version of OpenSceneGraph The Build.htm file for OpenThreads seems to say it worked. I see the linking, the Creating library output, and the Results section says 0 errors. I haven't seen anything significant yet in the build output from osgviewer and osgversion, but the former works and the latter doesn't. I just saw the note from Blake, and that's the sort of thing I was looking for. Is OpenThreads listed in dependencies or similar for osgviewer? andy No, but osgviewer does not call any function directly from OpenThreads. When I add OpenThreads to the dependency list for osgversion, it links properly. I don't know how to modify the cmakelists.txt files to have this happen automatically, though. There was a typo in osgversion/CMakeLists.txt the variable TARGET_ADDED_LIBRARIES must be UPPERCASE, not Target_ADDED_LIBRARIES, I see now OpenThreads has moved up in the Applications CMakeLists.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN version of OpenSceneGraph
Under VS8, everytthing fine apart from linking of osgversion, need to explicitely link OpenThreads so add SET(Target_ADDED_LIBRARIES OpenThreads) after SET(TARGET_SRC osgversion.cpp ) hope it helps ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake config for OpenVRML plugin - debug vs release libs
Jean-Sébastien Guay wrote: Hello Luigi, Sorry I am on a really slow connection now, so just hints, I can not test: That's fine, thanks for helping even in less than optimal work conditions :-) The idea is that TARGET_ADDED_LIBRARIES is interpreted by SETUP_PLUGIN macro as a list of undifferentiated external lib libraries to link to I had to replace TARGET_ADDED_LIBRARIES with TARGET_EXTERNAL_LIBRARIES, otherwise CMake would complain that it doesn't know how to make the library... I think that was just because of the untested disclaimer you put in your message :-) A typo... sorry. TARGET_LIBRARIES_VARS is interpreted as a list of variable names, the simple name is intended to hold the library to iln in optimizemed mode, the var with _DEBUG appended holds the lib name to use in debug mode. That works well, except for one thing. CMake seems to not use the debug version of the OpenVRML library (given as OPENVRML_LIBRARY and OPENVRML_LIBRARY_DEBUG in FindOpenVRML.cmake) in the debug linker properties... I have no idea why. I can see in the CMake dialog that the right library is specified (openvrml.lib for release, openvrmld.lib for debug) but after doing configure+generate, it's openvrml.lib in both release and debug in the Visual C++ linker properties. The weird thing is that ANTLR_LIBRARY and REGEX_LIBRARY work well for release and debug... It's just OPENVRML_LIBRARY that doesn't work. Is it FindOpenVRML.cmake that has a problem? I'm including both files just to see if you can spot what's wrong... Try deleting the cache, I think the Find stuff does not recompute if the variable is in cache Hope it helps Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake config for OpenVRML plugin - debug vs release libs
Hello Sebastian Sorry I am on a really slow connection now, so just hints, I can not test: if you define SET(ANTRL_LIBRARY antlr.lib) SET(ANTRL_LIBRARY_DEBUG antlrd.lib) SET(REGEX_LIBRARY regex.lib) SET(REGEX_LIBRARY_DEBUG regexd.lib) SET(TARGET_LIBRARIES_VARS OPENVRML_LIBRARY ANTRL_LIBRARY REGEX_LIBRARY) SET(TARGET_ADDED_LIBRARIES Ws2_32.lib) It should work (not tested) The idea is that TARGET_ADDED_LIBRARIES is interpreted by SETUP_PLUGIN macro as a list of undifferentiated external lib libraries to link to TARGET_LIBRARIES_VARS is interpreted as a list of variable names, the simple name is intended to hold the library to iln in optimizemed mode, the var with _DEBUG appended holds the lib name to use in debug mode. Hope it helps Luigi Jean-Sébastien Guay wrote: Hello, I suspect this is a question for either Luigi Calori or Eric Wing... I am trying to correct the CMakeLists.txt in the src/osgPlugins/vrml directory, which I had hacked together without really knowing what I was doing. I have something that's basically better (as in, it doesn't produce errors when Configuring in CMake) but I still have a small problem. In addition to the openvrml.lib library (which is openvrmld.lib for debug) which I specify using OPENVRML_LIBRARY and OPENVRML_LIBRARY_DEBUG, the OpenVRML plugin also requires to link to two other libs which are compiled from the OpenVRML source code: antlr.lib and regex.lib (antlrd.lib and regexd.lib) as well as the standard Windows Ws2_32.lib library (which has no debug version as far as I know). Right now, I specify those like this, in the plugin's CMakeLists.txt: SET(TARGET_EXTERNAL_LIBRARIES antlr regex Ws2_32) What I need is to be able to specify antlrd.lib and regexd.lib for debug builds, and I don't know the CMake way of doing this. I tried: SET(TARGET_EXTERNAL_LIBRARIES_DEBUG antlrd regexd Ws2_32) but that doesn't seem to work (the generated project still has the non-debug libs in its linker settings). Is there a way of doing this? How? Thanks, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake build target INSTALL
Hartmut Seichter wrote: Ok, the problem seems that Cmake detects a Coin3D 2.4.5 installation only halfway correctly. It is missing the libs and thus I suppose the values from the cache don't make it into the target for the .iv plugin (include directory etc pp). When running the INSTALL target the cmake script craps out because it can't find osgdb_iv.dll and skips everything after that. The INSTALL target run a script that try to copy all the built files into the install places. If some build target fails, the script does not find a file and so crash. Non know if is possible to configure in a way it continue even if some file is missing. You can try to use the advanced option OSG_MSVC_VERSIONED_DLL to build a build time directory structure that mimic what install target do but at build time Sorry for the noise, I hope that sheds some more light on the problem below. Cheers, Hartmut Hartmut Seichter wrote: Hi there, two things as of SVN rev 7366 using the INSTALL target in combination with Visual Studio 2003: - osgdb_freetype is not being copied (anyway the plugins folder is not as crowded, I have a hunch that more is missing) - applications like osgversion etc are not copied I did clean cache etc with cmake (using version 2.4.7) Cheers, Hartmut ___ 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] couple more problems in OSG_MSVC_VERSIONED_DLL RE: OpenSceneGraph-2.1.9 dev version released
Andy Skinner wrote: Is someone who knows this stuff looking into this and the extra subdirectories created in lib? Sorry for the late response, I' m out of office/home without good connection, just now got a low speed one. on my side, I see, when OSG_MSVC_VERSIONED_DLL is activated, under lib there are still Release and Debug folders that contains osgdb_gdal.lib and osgdb_gdald.lib files respectively. These files should not be generated as long as the other plugins, but I did not figured out why they got built. If these are the folders you refer to, it is a known problem, otherwise, let me know. Luigi thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, September 05, 2007 4:35 AM To: Public OpenSceneGraph Users discussion list. Subject: Re: [osg-users] OpenSceneGraph-2.1.9 dev version released Hi Andy, Thanks for the through review, OpenThreads should probably be under its own OSVERSION. Robert. On 9/4/07, Andy Skinner [EMAIL PROTECTED] wrote: Sorry if I've missed this (I looked), but is the OpenThreads.dll file supposed to use the OSG SOVERSION number or its own? I've got: osg20-osg.dll osg20-OpenThreads.dll for Windows, but: libosg.so.20 libOpenThreads.so.7 for Linux. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New build configuration for Windows checked in.
Serge Lages wrote:
I am building to test it out.
A first question, the OPENSCENEGRAPH_SOVERSION is different from the
OSG version ? I am getting osg19-osg.dll, it is normal ?
Yes, I' ve been asked by Robert to put OPENSCENEGRAPH_SOVERSION on core
dll instead of my first guess OPENSCENEGRAPH_VERSION that is used for
plugin folder.
I presume is for consintency with Unix conventions
If you get error on GEO plugin, this is expected and a patch is already
submitted
Hope it works
Luigi
On 8/30/07, * Robert Osfield* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi All,
Over the last week there has been various discussions on the
osg-submissions lists about refining the Windows build configuration
so that it builds in a way that makes it easier to use without
setting
paths to plugins or libs. Luigi Calori has very kindly down all the
hard work in experimenting with and managing to get CMake to get it to
build in this way, and finally the culmination of this work is now
checked into SVN.
Key differences of the new build configuration are:
1) .lib for all the core libraries are built in OpenSceneGraph/lib
2) .dll's for all the core libraries are built in
OpenSceneGarph/bin
3) dll's for all the core libraries are now built with
osg-version prefix
i.e. osg-version-osgUtil.dll
4) .dll's for all plugins are built in
OpenSceneGarph/bin/osgPlugins-version
A dry list, but... what it means to you as Window developers is
pretty amazing
1) End of DLL hell is in sight - both core library dll's and plugins
are versioned
so mixing multiple versions of the OSG on one system will
now be far far
less painful than ever before
2) No need to set paths to find when the dll's or plugins are.
3) The build structure mirrors that what will be installed if you
decide to install.
4) Install is now just an optional extra - you no longer need to
do it
I know I'm a uber geek, who doesn't even use Windows, but it seems
mighty wholesome and pleasing to me :-)
Now to make use of all this wholesome goodness you'll first need to
update to the CMake 2.4.7 version as 2.4.6 isn't capable of doing the
above. As its all so new Luigi has made the new build configuration
an option, rather than the default build so you'll need to enable it.
Finally its very new, and only tested by Luigi so far, so we'll need
willing helpers to go test it.
Below is a copy and paste from CMakeList.txt with a segment Luigi's
added to explain a little about the new feature and how to enable it.
Many thanks to Luigi for his efforts,
Robert.
# the foolowing options are MSVC specific,
# the first OSG_MSVC_VERSIONED_DLL activate a custom build-time layout
that should allow to run examples and application
# fron bin folder without requiring installation step.
# it also prepend osg${OPENSCENEGRAPH_SOVERSION}- to only .dll
files, leaving .lib files untouched in lib
# it also use a hack to get rid of Debug and Release folder in
MSVC projects
# all the .dll and .pdb are in bin and all the .lib and .exp are
in lib
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.magrathea-engine.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New build configuration for Windows checked in.
Serge Lages wrote: On 8/30/07, *Serge Lages* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It seems I have some troubles with OpenThreads, in release it asks for OpenThreads.dll but in debug it works fine, it asks for osg19-OpenThreads.dll. It may be a problem on my side, I am investigating... Deleting the .lib and rebuilding seems to have made it work. I think the dll name is written inside the lib I have found inconsistency in wrapper generation, a patch is on the go. To resume I have build OSG (core and plugins only) with the dll version number, and everything seems to work as expected. Good job ! : Thanks Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tutorials
I vote for 2) I think we should provide examples on how to build an external application that is OSG-based, the tutorials are probably good candidates. They could also be used with different OSG versions. I can help to set up the CMake projects. P.S. It seems to me to not have received the original Robert message, It is not the first ime I got a reply to a message I' ve never received. has it occured to anyone else? Thanks Luigi David Callu wrote: better to keep examples into the OpenSceneGraph/examples to keep sync with OSG core isn't it ?? 2007/8/25, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Where to host the example source... 1) I see three options - zip files attached to the wiki 2) A svn repository for tutorial examples 3) Putting tutorial examples into the OpenSceneGraph/examples as part of the core OSG. Keeping the tutorials separate from the core OSG will require a maintainer for it, any volunteers? Keeping it separate does have an advantage of show how one builds applications outwith the standard OSG distribution. Putting tutorials into the core OSG has the advantage is that the code will be as easily any of the core OSG examples. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please buil test OpenSceneGraph SVN
Under WinXP, compilation ok, one small problem on osgconv, not a ble to compress textures osgconvd.exe --compressed cow.osg cow.ive Failed to create pbuffer, failing back to normal graphics window. Error: Unable to create graphis context - cannot run compression Data written to 'cow.ive'. solved (for me) by adding #include osgViewer/Viewer The new plugin search path prevent running osg examples and apps from build folders, without installation step due to VisualStudio adding debug/release to plugin this can be fixed twaking CMake Macros sent patches to osg-submission ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-Based CMake projects
Robert Osfield wrote: FYI, I've added CMake support (OSG style) to Present3D and VirtualPlanetBuilder: http://present3d.osgforge.org/ http://virtualplanetbuilder.osgforge.org/ I intend to have CMake support for osgProducer as well. I knew of virtualplanetbuilder, good to know there is also Present3d available, I' ll try to build it under windows, do you expect to be hard? the svn checkout direction in http://www.openscenegraph.org/projects/Present3D/wiki/Downloads/SVN should be corrected to use the .org domain i think. I see files in CMakeModules folder of the OSG, VPB and present3d are almost identical, a part from some renaming. Would it be worthwile to make them part of OSG installation and let OSG derived projects to get them from OSG dir? This could probably ease Cmake adoption by OSG based projects Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why does the osgPlugins directory include the version?
Eron Steger wrote: I see... Unfortunately, at least under Windows this doesn't work. I believe this is because the plugins are separated into debug and release directories. Consider a search for the OBJ plugin. It is located in the following locations: OpenSceneGraph\lib\osgPlugins-2.1.2\debug\osgdb_objd.dll OpenSceneGraph\lib\osgPlugins-2.1.2\release\osgdb_obj.dll From the look of it, osgDB isn't searching inside the debug/release directories, instead looking for the file at OpenSceneGraph\lib\osgPlugins-2.1.2\osgdb_objd.dll. not sure about latest release, but as for previous dev release, this is the situation after the build solution phase, if you also build the Install target, this should place plugins directly in the bin folder of your INSTALL_PREFIX folder. The default CMake behaviour is to produceVisual Studio projects that put dll into separate folders for Debug and Release builds. It is possible to move them in the install step or by by defining a post build custom command but I do not know if they can be directly generated in the same folder Hope it helps Luigi - Eron Robert Osfield wrote: Hi Eron, The version number is inserted into the plugin directory name to avoid problems with mixing plugins of different versions to that linked to at compile time. You should not need to ever encode the plugin directory path into your app, only the path to the parent directory of the plugin directory, as osgDB will automatically prepend the correct osgPlugin-version directory to the path when it can't find a plugin straight away. Robert. On 7/30/07, Eron Steger [EMAIL PROTECTED] wrote: Hello, I'm curious as to why the compiled 'osgPlugins' directory on Windows contains the version in the directory's name (i.e. OpenSceneGraph\lib\osgPlugins-2.1.2\debug). This provides a constant annoyance everytime the version is updated, as the path has to be updated. As well, since the rest of the compiled osg library doesn't have a version associated with it, it doesn't really provide backward compatibility since those other files will be clobbered when compiling a new release. - Eron ___ 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
