Re: [osg-users] [build] Building OpenSceneGraph Windows
Hi Stephan, in my honest opinion it looks more like a compiler configuration issue than an OSG problem. Try to check the environment variables PATH (in a command window "echo %PATH%") and look for the path to your mingw/bin. As far as I know the mingw_get does not configure the environment variables of the Windows system. CMake is, during configuration, testing if the compiler works correctly before configuring OSG itself. Regards, Christian Le 24/12/2017 05:13, Stefan Waldegger a écrit : Hi, this is my first post here and I have already searched in this Forum and on google but I did not get the answer which is handling my problem. So I have read a lot about OSG in the internet and no I want to give it a try. I have downloaded OSG 3.4.1 from the official homepage. Then I unzipped it and put it to a convinient place and had a look into it. I found the sourcecode and some makefiles in the folder. >From my experiences using Ubuntu and other Unix distibutions I know how easy this normally is, just call make and a big batch is being executed and voila, all the .so and .a files are here and everybody is happy. But now I am on windows. Windows 10 to be honest. I am using Code::Blocks as IDE and MinGW compiler. Downloaded with MinGW_get. So it is not that comes with Code::Blocks. Also I downloaded CMake for windows with the Gui. Then I started the CMake gui and on the first glance it all looked very easy. I entered the path of OSG as source and the same path as destnation, clicked on configure, chose MinGW as compiler, clicked ok. Aaaand then. Like 20 messageboxes are popping up in seria telling me that dll files are missing libisl-15.dll, libmingwex-0.dll, libiconv-2.dll, libgmp-10.dll, and much more. And naturally CMake finishes wihtout having done anything in the end. It is this messagebox wich comes when you want to try to sart a program the the dll is missing. But the funny thing is, when I look in the MinGW\bin folder, all the dlls are there. It is also the first time I am using CMake in windows, so I dont have any experience here. Do you know this issue, is there a solution? Thank you all for your support in advance. Merry Christmas Cheers, Stefan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72635#72635 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DTIS/PSEV Département Traitement de l'information et systèmes ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does OSG still build against Qt 4.8.7?
Hi Marko,
sorry, but I'm not familiar at all with the Macport's portfile system,
so I may not bee of big help for you...
You say that only Qt4 is installed so what do you mean by Qt5 variant
works ?
The error excerpt you show is after the build process as he is already
looking for the built libraries, do you have any excerpt of the build
process of Openscenegraph ?
Christian
Le 23/03/2016 00:27, Marko Käning a écrit :
Hi,
I tried again.
Here is an excerpt of my MacPorts’ Portfile:
---
configure.args-append -DOSG_CONFIG_HAS_BEEN_RUN_BEFORE=YES \
-DOSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX=imageio \
-DOSG_WINDOWING_SYSTEM=Cocoa \
-DOSG_USE_QT:BOOL=OFF
# disable unwanted optional dependencies to avoid opportunistic configuration
# before cmake 2.8 this required patching CMakeLists.txt
# TODO: add some of these back either directly or as variants after testing
configure.args-append -DCMAKE_DISABLE_FIND_PACKAGE_Inventor=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_COLLADA=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_FBX=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_Xine=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_OpenVRML=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_Performer=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_GTA=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_LibVNCServer=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_OurDCMTK=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_SDL2=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_SDL=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_GtkGl=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_DirectInput=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_NVTT=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_Asio=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_ZeroConf=1 \
-DCMAKE_DISABLE_FIND_PACKAGE_LIBLAS=1
variant qt4 description "with Qt4 support" {
configure.args-delete -DOSG_USE_QT:BOOL=OFF
configure.args-append -DOSG_USE_QT:BOOL=ON -DDESIRED_QT_VERSION=4
}
variant qt5 description "with Qt5 support" {
configure.args-delete -DOSG_USE_QT:BOOL=OFF
configure.args-append -DOSG_USE_QT:BOOL=ON -DDESIRED_QT_VERSION=5
}
---
Variant ‘qt5’ works, but variant ‘qt4’ fails to do so:
---
-- Found osgDB: /opt/local/lib/libosgDB.dylib
-- Found osgGA: /opt/local/lib/libosgGA.dylib
-- Found osgManipulator: /opt/local/lib/libosgManipulator.dylib
-- Could NOT find osgQt (missing: OSGQT_LIBRARY OSGQT_INCLUDE_DIR)
-- Found osgText: /opt/local/lib/libosgText.dylib
-- Found osgUtil: /opt/local/lib/libosgUtil.dylib
-- Found osgViewer: /opt/local/lib/libosgViewer.dylib
-- Found osgWidget: /opt/local/lib/libosgWidget.dylib
-- Found osg: /opt/local/lib/libosg.dylib
-- Found OpenThreads: /opt/local/lib/libOpenThreads.dylib
CMake Error at
/opt/local/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148
(message):
Could NOT find OpenSceneGraph (missing: OPENSCENEGRAPH_INCLUDE_DIR
OSGQT_FOUND) (found suitable version "3.4.0", minimum required is "3.4.0")
Call Stack (most recent call first):
/opt/local/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388
(_FPHSA_FAILURE_MESSAGE)
/opt/local/share/cmake-3.5/Modules/FindOpenSceneGraph.cmake:234
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:38 (find_package)
-- Configuring incomplete, errors occurred!
---
What am I missing?
Why isn't the libosgQt library built in case of Qt4?
Greets,
Marko
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
SCHULTE Christian
Ingénieur Recherche
Responsable du Laboratoire de Simulation
ONERA - DCSD/PSEV
Département Commande des Systèmes et Dynamique du Vol
ONERA - Centre de Salon de Provence
BA 701
13661 SALON AIR Cedex - France
Tel :04.90.17.01.45
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does OSG still build against Qt 4.8.7?
Sorry Marko, it's a little bit late... ;-) You are right I meant Qt 4.8.7, not 8.4.0 (wonder what it would look like this version of Qt:-D )! The main problem I think is that you have probably both version installed on your machine and the first found by CMake is the Qt5. Look which version of qmake is found in the cmake-gui (or ccmake). That's the starting point for the Qt choice of CMake. Regards, Christian Le 22/03/2016 16:34, Marko Käning a écrit : Hi Christian, On 22 Mar 2016, at 16:23 , Christian Schulte <christian.schu...@onera.fr> wrote: I confirm you that OSG 3.4.0 still builds with QT 8.4.0 on Windows Seven and on Linux CentOS 6.7. you probably mean Qt 4.8.0?! I wonder whether -DOSG_USE_QT:BOOL=ON -DDESIRED_QT_VERSION=4 is actually enough to get it to build the osgQt lib… For some reason I could get this to work for Qt5 only, trying the same for Qt4 on OSX didn't succeed for me - up to now. Greets, Marko ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Département Commande des Systèmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent Window Application for Windows and more OS
Hello everyone, I succeeded in integrating transparent windows as well on Windows platform than on Linux X11. The only problem remaining is that I wanted to be able to modify the transparency color in a coherent way with the clearColor of the main camera. Is there a way to access the window handler during the (pre)render stage ? I don't want to integrate some platform specific code to the render stage code, but maybe there is a way to register a call to a method of osgViewer::GraphicsWindow implementation ? Once I've treated this problem I will propose it on the submission list with a complete example for Linux and Windows. Thanks for your help, Christian Le 29/07/2015 11:05, Christian Schulte a crit: Hello everyone, I'm currently integrating in osgViewer the transparency an I'm looking for some advices. I started with the code published by Chris Hidden on the mailing list, and modified it a little bit in order to be able to choose between color transparency (LWA_COLORKEY), or alpha transparency (LWA_ALPHA) or both. The probleme is that it is, for the moment, done during the window creation. What I wanted is to be able to adapt the LWA_COLORKEY whenever the user wants, same for LWA_ALPHA. My questions to the community : Where would be the right place to make these changes (as I need to be able to recover the window handle) ? Do you think that it could be interesting to be able to switch from transparent to non transparent during execution ? Should the color, alpha and activation boolean be added to the traits and be modified through GraphicsWindow class ? Has someone already implemented the transparency for another OS / Windowing System, and if yes could we try to unify the way it is done ? Sorry for all these questions, but as it is my first contribution try, I want to be sure to make no mistake ! Cheers, Christian -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image file loading
Hi Julie, have you tried to set the OSG_NOTIFY_LEVEL to DEBUG, in order to see what happens. If the file exists and loads correctly with other software, maybe your osgPlugin for the png file format has not been compiled or is not found. Look at the osgPlugin path for osgdb_png.dll. Christian Le 25/08/2015 08:02, Julie Green a écrit : Hi, I have a problem with image file loading Code: std::string path(D:/i.png); osg::ref_ptrosg::Image image = osgDB::readImageFile(path); The file is there, but my application doesn't load it. Thanks for your help! Cheers, Julie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64881#64881 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Département Commande des Systèmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image file loading
Hi Julie, restart a cmake-gui, you must have some necessary dependencies that are not set. Activate Advanced Options and Grouped and look if you have the ZLIB dependencies (ZLIB_INLCUDE_DIR, ZLIB_LIBRARY) and the PNG dependencies (PNG_LIBRARY_RELEASE and PNG_PNG_INCLUDE_DIR) set. Christian Le 25/08/2015 11:44, Julie Green a écrit : Hi Christian, you`re right, there's no osgdb_png.dll in Plugins directory. How to install it? Julie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64884#64884 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Département Commande des Systèmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Transparent Window Application for Windows and more OS
Hello everyone, I'm currently integrating in osgViewer the transparency an I'm looking for some advices. I started with the code published by Chris Hidden on the mailing list, and modified it a little bit in order to be able to choose between color transparency (LWA_COLORKEY), or alpha transparency (LWA_ALPHA) or both. The probleme is that it is, for the moment, done during the window creation. What I wanted is to be able to adapt the LWA_COLORKEY whenever the user wants, same for LWA_ALPHA. My questions to the community : Where would be the right place to make these changes (as I need to be able to recover the window handle) ? Do you think that it could be interesting to be able to switch from transparent to non transparent during execution ? Should the color, alpha and activation boolean be added to the traits and be modified through GraphicsWindow class ? Has someone already implemented the transparency for another OS / Windowing System, and if yes could we try to unify the way it is done ? Sorry for all these questions, but as it is my first contribution try, I want to be sure to make no mistake ! Cheers, Christian -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with make my own function
Hello Alvaro (?), this isn't an OSG problem, it is a pure c++ coding problem... In your header file you declare a class with a public method, but you define a function that is not member of your class in your cpp. You should define osg::Camera* Ventana::createCamera(int x, int y, int w, int h) instead of osg::Camera* createCamera(int x, int y, int w, int h) Furthermore, you don't even instantiate your class Ventana in your main. In your main you should create an instance of Ventana Ventana* myInstance = new Ventana(); As you didn't define any constructor it will use a default generated constructor for your class. After this you can call viewer-addSlave(myInstance-createCamera(300, 100, 900, 600)); This should make it work. You should consider review your coding basics... Regards, Christian Le 29/07/2015 13:36, alvaro ginestar rodriguez a crit: hi everyone !! i would like make a class and function for make a window in osg, i have this source, but when i tried them separately, it have errors. The file "DemoVentana.cpp"it does well, but the other one no. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] force vsync to false (sofware not hardware) on NVidia
Hello Jan, I succeeded in OSG to turn off vSync in soft when the driver is set to application controlled. The problem in my case was really that in the GraphicsWindowWin32.cpp CreateWindow method the setSyncToVBlank method is only called if vSync==true... and that's the odd thing! I'm currently modifying the code in order to make it possible to activate and DESACTIVATE vSync in OSG. And it works for me under windows but I first have to check that it will also work for ATI cards (I have no Intel Graphics so cannot test these ones) before I try to submit. I don't know if there is a similar bug in Linux ? By the way I will try also to see if there is a correct manner to integrate the handling of transparent windows (as specified by Chris Hidden in the mailing list end of 2014 (see Transparent Window Application discussion) without having some negative impact on already existing codes... Maybe I should launch a new discussion thread on this subject, as I would want to know if there would be some interest in being able to change transparency and window behaviour even in use of OSG, not only on initialization... Christian Le 22/07/2015 10:39, Jan Ciger a écrit : Hello, I am prototyping some OpenGL stuff in Python using Pyglet and have encountered the same vsync problem, both in Linux Windows. I think it is Nvidia's driver that is (again - Nvidia had various vsync issues in the past) trying to be smart and is breaking vsync in OpenGL. It has most likely nothing to do with OSG. For me if the vsync setting in the driver is set to application controlled, it is always on, no matter what the application specifies (vsync=False or vsync=True in the gl.Config setup in Pyglet makes no difference). The only way to turn vsync off is to disable it in the driver's control panel. J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Département Commande des Systèmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] force vsync to false (sofware not hardware) on NVidia
Hello, sorry to pop-up my question, isn't there someone who has any idea of how to fix/overcome this problem ? I can try to patch this, but I want to be sure to understand why it has been done like this before I break something :-[ Thanks, Christian Le 06/07/2015 10:05, Christian Schulte a crit: Hello everybody, I'm trying to switch on or off the vsync on my NVidia K4200 on Win7 64 bits by using traits-vsync and setting the NVidia parameter to 'Use Application parameters" for the vsync. Setting vsync to true, works, I can see the OSG_INFO "GraphicsWindowWin32::setSyncToVBlank" as expected. The problem is I cannot set it to false, because by default the NVidia behaviour is vsync = true (i.e. if nothing is specified the drivers choice is vsync=true). After digging a little bit I've found in GraphicWindowWin32.cpp GraphicsWindowWin32::realizeImplementation() that : vsync is only changed if it is true - the setSyncToVBlank(bool) is only called if the traits-vsync is true, so you cannot change it to false. Removing the protection (if vsync equal true), the setSyncToVBlank is not called either because it is in an if condition depending on vsync equal true (if (_traits.valid() (_traits-sharedContext.valid() || _traits-vsync || _traits-swapGroupEnabled))) The question is why is there this double protection on the vsync equal true ? Is there a risk that I don't understand (and then please can someone explain :-) ) about desactivating the vsync ? Thanks a lot, Christian -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] force vsync to false (sofware not hardware) on NVidia
Thanks Robert, I will give a try and make some tests on my machines here. If I find a stable tweak I will propose it for submission. If in the meanwhile some windows expert can give me some advice, I would appreciate ! Christian Le 20/07/2015 11:03, Robert Osfield a crit: Hi Christian, On 20 July 2015 at 09:48, Christian Schulte christian.schu...@onera.fr wrote: sorry to pop-up my question, isn't there someone who has any idea of how to fix/overcome this problem ? I can try to patch this, but I want to be sure to understand why it has been done like this before I break something :-[ I haven't contributed to the GraphcsWindowWin32 as I have spent the vast majority of my time using Unices, deferring to others in the community for windows expertise. I therefore don't feel in a position to dive in on the topic without others from the Windows side to the community diving in with their own insights. In general though, if you can tweak the code and get it working how you need to work I'll review the changes and consider merging them if they don't look like they'll break existing functionality. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingnieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Dpartement Commande des Systmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] force vsync to false (sofware not hardware) on NVidia
Hello everybody,
I'm trying to switch on or off the vsync on my NVidia K4200 on Win7
64 bits by using traits-vsync and setting the NVidia parameter
to 'Use Application parameters" for the vsync.
Setting vsync to true, works, I can see the OSG_INFO
"GraphicsWindowWin32::setSyncToVBlank" as expected.
The problem is I cannot set it to false, because by default the
NVidia behaviour is vsync = true (i.e. if nothing is specified the
drivers choice is vsync=true).
After digging a little bit I've found in GraphicWindowWin32.cpp
GraphicsWindowWin32::realizeImplementation() that :
vsync is only changed if it is true - the
setSyncToVBlank(bool) is only called if the traits-vsync is
true, so you cannot change it to false.
Removing the protection (if vsync equal true), the
setSyncToVBlank is not called either because it is in an if
condition depending on vsync equal true (if (_traits.valid()
(_traits-sharedContext.valid() ||
_traits-vsync || _traits-swapGroupEnabled)))
The question is why is there this double protection on the vsync
equal true ? Is there a risk that I don't understand (and then
please can someone explain :-)
) about desactivating the vsync ?
Thanks a lot,
Christian
--
SCHULTE Christian
Ingnieur Recherche
Responsable du Laboratoire de Simulation
ONERA - DCSD/PSEV
Dpartement Commande des Systmes et Dynamique du Vol
ONERA - Centre de Salon de Provence
BA 701
13661 SALON AIR Cedex - France
Tel :04.90.17.01.45
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] geographic to geocentric coordinate transformation
Hello Elias,
underneath you will find your corrected and commented example (sorry, I
had to change the lat,lon and models :-) ).
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgDB/ReadFile
#include osg/PositionAttitudeTransform
int main( int argc, char** argv ) {
osg::ref_ptrosg::GraphicsContext::Traits traits;
if(!(traits = new osg::GraphicsContext::Traits()).valid()) {
// print
osg::notify(osg::WARN)
- traits = new osg::GraphicsContext::Traits() -
invalid : abandon std::endl;
// error
return NULL;
}
// set traits properties
traits-screenNum= 0;
traits-x = 40;
traits-y = 40;
traits-width = 1024;
traits-height = 768;
traits-doubleBuffer = true;
traits-windowDecoration = true;
traits-vsync= true;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext(traits);
osg::ref_ptrosg::Group root = new osg::Group;
osg::ref_ptrosg::Node cessna = osgDB::readNodeFile(EC225.ive);
osg::ref_ptrosg::Node map =
osgDB::readNodeFile(y:/Bdt/Marseille/marseillemipmaphard09dds.ive);
osg::ref_ptrosg::Camera camera = new osg::Camera;
osg::Vec3d center, eye, up;
//Getting XYZ position for cessna
osg::Matrix cessnaLocation;
osg::EllipsoidModel ellipsoid;
double x,y,z;
ellipsoid.convertLatLongHeightToXYZ(osg::DegreesToRadians(43.449310),
osg::DegreesToRadians(5.197525), 200.0, x, y, z);
osg::Vec3 positionForCessna = osg::Vec3d(x,y,z);
//Placing cessna
osg::ref_ptrosg::PositionAttitudeTransform moveCessna = new
osg::PositionAttitudeTransform;
moveCessna-setPosition(positionForCessna);
// Calculating attitude (heading north)
double phi = 0.0;
double psi = 0.0;
double theta = 0.0;
osg::Matrixd localToWorld;
osg::Matrixd attitude;
ellipsoid.computeLocalToWorldTransformFromXYZ(osg::DegreesToRadians(43.449310),
osg::DegreesToRadians(5.197525), 200.0,localToWorld);
attitude.makeRotate(
osg::DegreesToRadians(phi), osg::Y_AXIS,
osg::DegreesToRadians(theta), osg::X_AXIS,
osg::DegreesToRadians(-psi), osg::Z_AXIS);
attitude *= localToWorld;
osg::Quat quat = attitude.getRotate();
moveCessna-setAttitude(quat);
moveCessna-addChild(cessna.get());
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
// Create camera as shallow copy of theo ne of the view
camera =
dynamic_castosg::Camera*(viewer-getCamera()-clone(osg::CopyOp::SHALLOW_COPY));
camera-setGraphicsContext(gc);
camera-setProjectionMatrixAsPerspective(40.0,1.33,0.1,1.0);
camera-setViewport(new osg::Viewport(0, 0, gc-getTraits()-width,
gc-getTraits()-height));
camera-setClearColor(osg::Vec4f(0.5f,0.5f,0.0f,0.0f));
camera-setCullingActive(false);
//Getting XYZ position for camera
//Lat Lon are the same, height is 500.0
// The eye : position of the camera
ellipsoid.convertLatLongHeightToXYZ(osg::DegreesToRadians(43.449310),
osg::DegreesToRadians(5.197525), 500.0, x, y, z);
eye = osg::Vec3d(x,y,z);
// The center : position where you look at (same position a little
bit underneath...
ellipsoid.convertLatLongHeightToXYZ(osg::DegreesToRadians(43.449310),
osg::DegreesToRadians(5.197525), 499.9, x, y, z);
center = osg::Vec3d(x,y,z);
// The up : a little more tricky...
// It is the up vector of your screen (ie what is the bottom top
axis of your screen)
// If you want it to be north up
up = osg::Vec3d( -std::cos(osg::DegreesToRadians(43.449310)) *
std::sin( osg::DegreesToRadians(5.197525)),
-std::sin(osg::DegreesToRadians(43.449310)) * std::sin(
osg::DegreesToRadians(5.197525)),
std::cos(osg::DegreesToRadians(5.197525)));
// If you want it to be east up
up = osg::Vec3d( -std::cos(osg::DegreesToRadians(43.449310)),
std::cos(osg::DegreesToRadians(43.449310)),
0.0);
// Now you can set your view matrix
camera-setViewMatrixAsLookAt(eye,center,up);
// Some light for the scene...
osg::ref_ptrosg::Light light = new osg::Light();
light-setLightNum(0);
light-setDataVariance(osg::Object::DYNAMIC);
osg::ref_ptrosg::LightSource lightSource = new osg::LightSource;
lightSource-setLight(light);
lightSource-setLocalStateSetModes(osg::StateAttribute::ON);
// Adding the elements
root-addChild( map.get() );
root-addChild( moveCessna.get() );
root-addChild( lightSource.get());
// Setting up the view
viewer-setCamera( camera.get() );
viewer-setSceneData( root.get() );
osg::ref_ptrosgViewer::StatsHandler stats = new
osgViewer::StatsHandler();
viewer-addEventHandler(stats.get());
while (!viewer-done())
{
viewer-frame();
}
return 1;
}
Hope it helps out !
Re: [osg-users] [vpb] geographic to geocentric coordinate transformation
Hello Elias,
since you have created your terrain using --geocentric in osgdem the
terrain is indeed in ECEF coordinates, but there is no reason that your
cessna model is. Looking at your code, the cessna is at the earth centre
(0.0,0.0,0.0). If you want to have your cessna on your terrain you
should load your cessna on a PositionAttitudeTransform and move it
correctly onto earth surface, using the ellipsoid xyzFromLatLonEle. You
should try to place your camera also using this and decomposing your
matrix in order to find where is the problem(
cam-setViewMatrix(translation * toYup * rotation);)
Also you should use as much as possible the osg functionalities in order
to use the same math constants (osg::PI_2 instead of _M_PI_2).
Regards,
Christian
Le 17/06/2015 10:39, Elias Tarasov a écrit :
Hello!
It seems i have a problem Deniz had faced previously.
My generated terrain viewed from osgviewer is here:
https://drive.google.com/file/d/0ByDDImhSolf6Szh5YW81MDdqV2M/view?usp=sharing
My gdalinfo for dem file used to generate terrain is here:
Driver: GTiff/GeoTIFF
Files: n30_w086_1arc_v3_conv.tif
n30_w086_1arc_v3_conv.tif.aux.xml
Size is 58, 50
Coordinate System is:
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.257223563,
AUTHORITY[EPSG,7030]],
AUTHORITY[EPSG,6326]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433],
AUTHORITY[EPSG,4326]]
Origin = (-85.4959721,30.5362503)
Pixel Size = (0.0002778,-0.0002778)
Metadata:
AREA_OR_POINT=Point
DTED_CompilationDate=0002
DTED_DataEdition=02
DTED_DigitizingSystem=SRTM
DTED_HorizontalAccuracy=0013
DTED_HorizontalDatum=WGS84
DTED_MaintenanceDate=
DTED_MaintenanceDescription=
DTED_MatchMergeDate=
DTED_MatchMergeVersion=A
DTED_NimaDesignator=DTED2
DTED_OriginLatitude=030N
DTED_OriginLongitude=086W
DTED_Producer=USCNIMA
DTED_RelHorizontalAccuracy=NA
DTED_RelVerticalAccuracy=0004
DTED_SecurityCode_DSI=U
DTED_SecurityCode_UHL=U
DTED_UniqueRef_DSI=H24 084
DTED_UniqueRef_UHL=H24 084
DTED_VerticalAccuracy_ACC=0005
DTED_VerticalAccuracy_UHL=0005
DTED_VerticalDatum=E96
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -85.4959722, 30.5362500) ( 85d29'45.50W, 30d32'10.50N)
Lower Left ( -85.4959722, 30.5223611) ( 85d29'45.50W, 30d31'20.50N)
Upper Right ( -85.4798611, 30.5362500) ( 85d28'47.50W, 30d32'10.50N)
Lower Right ( -85.4798611, 30.5223611) ( 85d28'47.50W, 30d31'20.50N)
Center ( -85.4879167, 30.5293056) ( 85d29'16.50W, 30d31'45.50N)
Band 1 Block=58x50 Type=Int16, ColorInterp=Gray
Min=31.000 Max=61.000
Minimum=31.000, Maximum=61.000, Mean=49.202, StdDev=6.253
NoData Value=0
Unit Type: m
Metadata:
STATISTICS_MAXIMUM=61
STATISTICS_MEAN=49.202413793103
STATISTICS_MINIMUM=31
STATISTICS_STDDEV=6.2528388891449
Here, center of my terrain is:
Center ( -85.4879167, 30.5293056) ( 85d29'16.50W, 30d31'45.50N)
Now i want to place a camera in the center of that terrain to use it from an
app:
const double M_PI_2 = 1.57079632679489661923;
int main( int argc, char** argv ) {
osg::ref_ptrosg::Group root = new osg::Group;
osg::ref_ptrosg::Node cessna =
osgDB::readNodeFile(c:/OpenSceneGraph/data/cessnafire.osg);
osg::ref_ptrosg::Node map =
osgDB::readNodeFile(c:/Terrain/FromUSGS/output/out.osgb);
root-addChild( cessna.get() );
root-addChild( map.get() );
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
viewer-setSceneData( root.get() );
osg::Matrixd vm;
osg::EllipsoidModel ellipsoid;
ellipsoid.computeLocalToWorldTransformFromLatLongHeight(osg::DegreesToRadians(-85.4877762),
osg::DegreesToRadians(30.5292506), 100, vm);
vm.invert(vm);
osg::Matrixd rotation2YUp;
rotation2YUp.makeRotate(-M_PI_2, osg::Vec3f(1.0, 0.0, 0.0));
vm *= rotation2YUp;
viewer-getCamera()-setViewMatrix(vm);
return viewer-run();
}
But i don't see anything. Just empty screen.
Well, since terrain had been built in geocentric mode, i think app somehow
moved terrain and cessna to the correct position in ECEF.
So, i just need to move a camera to that position.
I guess camera's position is wrong, but i don't know how to fix it.
Thank you!
Cheers,
Elias
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64106#64106
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
SCHULTE Christian
Ingénieur Recherche
Responsable du Laboratoire de Simulation
ONERA - DCSD/PSEV
Département Commande des Systèmes et Dynamique du Vol
ONERA - Centre de Salon de Provence
BA 701
13661 SALON AIR
Re: [osg-users] [vpb] Correct way to get texture data from USGS or any other source?
Hy Elias, your procedure seems correct to me, it is more your conclusion that I don't understand... What do you mean by "vpb didn't make texture elevated" ? Ha you fully zoomed on the textured zone in order to be sure that it is really not elevated. When I see the size of your dem, I would say that the elevations look reduced, due to the very large size of represented zone and the fact that there are only small elevations (try to calculate the ratio of highest point of dem and the length or width of your terrain). As far as I know you can define the extend of generated terrain in osgdem (and vpb) with command line option : -e x y w h Extents of the model to generate The artefact is due to the fact that the whole current LOD containing your texture will be black (that's why when you get farer away you see more black texture) I think the result will be correct (or look correct to you, as I think that it is already correct :-) ) once you reduce the extend of your generated database. Regards, Christian Le 11/06/2015 10:52, Elias Tarasov a écrit : Hello! My statement about the problem, that had been solved, looks a little premature. The problem: Terrain is displayed incorrectly. Results: 1. https://drive.google.com/file/d/0ByDDImhSolf6cGFyV21PRXZuZHM/view?usp=sharing 2. https://drive.google.com/file/d/0ByDDImhSolf6N3FvRkNJUW1nMlk/view?usp=sharing Step-by-step actions to make a terrain 0. Gathering required data 0.1. Choose texture: https://drive.google.com/file/d/0ByDDImhSolf6S3E0M1VmR2xDd1U/view?usp=sharing 0.2. Choose dem: https://drive.google.com/file/d/0ByDDImhSolf6cDNtWjlUa3VqdXc/view?usp=sharing 0.3. Downloaded texture: https://drive.google.com/file/d/0ByDDImhSolf6eXRpYlhxMFN3NnM/view?usp=sharing 0.4. Downloaded dem: https://drive.google.com/file/d/0ByDDImhSolf6MXVLUV9kOG1xR2c/view?usp=sharing 1. Straightforward vpbmaster --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile Error: vpbmaster can not run without all source data being in the correct destination coordinates system, please reproject them. Recieved signal 15, doing TERMINATE_RUNNING_TASKS_THEN_EXIT. Setting up MachinePool to use all 8 cores on this machine. MachinePool::signal(15) Machine::signal(15) Machine::cancelThreads() hostname=, threads=8 Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Cancel thread Completed Machine::cancelThreads() hostname=, threads=8 2. osgdem osgdem --geocentric -d dem/n30_w086_1arc_v3.tif -t texture/2.tif -o output/out.osgb answer: --geocentric -d dem/n30_w086_1arc_v3.tif ADD: dem/n30_w086_1arc_v3.tif -t texture/2.tif ADD: texture/2.tif -o output/out.osgb Adding terrainTile DataSet::_run() 0 0 Now checking for plug-in osgPlugins-3.3.8/osgdb_nvtt.dll osg::Registry::addImageProcessor(ImageProcessor) Loaded plug-in osgPlugins-3.3.8/osgdb_nvtt.dll and located ImageProcessor started DataSet::createDestination(30) reprojecting to file temporaryfile_2.tif ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. Failed to reproject texture/2.tif Time for after_reproject 0.003934 And here program crashes. 3. Manual reprojection using gdalwarp 3.1. gdalinfo for dem file: Driver: GTiff/GeoTIFF Files: n30_w086_1arc_v3.tif Size is 3601, 3601 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-86.0001384,31.0001391) Pixel Size = (0.0002778,-0.0002778) Metadata: AREA_OR_POINT=Point DTED_CompilationDate=0002 DTED_DataEdition=02 DTED_DigitizingSystem=SRTM DTED_HorizontalAccuracy=0013 DTED_HorizontalDatum=WGS84 DTED_MaintenanceDate= DTED_MaintenanceDescription= DTED_MatchMergeDate= DTED_MatchMergeVersion=A DTED_NimaDesignator=DTED2 DTED_OriginLatitude=030N DTED_OriginLongitude=086W DTED_Producer=USCNIMA DTED_RelHorizontalAccuracy=NA DTED_RelVerticalAccuracy=0004 DTED_SecurityCode_DSI=U DTED_SecurityCode_UHL=U DTED_UniqueRef_DSI=H24 084 DTED_UniqueRef_UHL=H24 084 DTED_VerticalAccuracy_ACC=0005 DTED_VerticalAccuracy_UHL=0005 DTED_VerticalDatum=E96 Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper
Re: [osg-users] [vpb] Correct way to get texture data from USGS or any other source?
Hello, how I found it ? Easy (LOL!), the EPSG:2238 is the official map projection for north of Florida and from the values in the file (Center ( 1657500.330, 572499.510)) you can see (okay, I admit if you are used to look at this kind of data :-) ) that it is a distance in feet from a reference point. That is typical for a Mercantor or Lambert projection. In every case I would advise you to check in a converter what latitude and longitude you will obtain from the centre of the image and double check with google maps or equivalent that you find again the same point. Because you can convert a lot of different projections to latitude and longitude, as the equations are nearly the same only the correction factors or the reference ellipsoid will change. So it will convert but you are not sure to be in the right place in the world... For your information, the EPSG:3857 is a non officially recognized projection as it uses a sphere as earth reference and not a ellipsoid. Furthermore this projection system is centred on Equator/Greenwich so you may have in the United States an error up to 43 km in map projection, (nearly 21 km on the ground). Regards, Christian Le 09/06/2015 23:15, Elias Tarasov a écrit : Hello! Christian Schulte wrote: Hello! I totally agree with Sebastian. These data is surely geo-referenced, as I myself often used in the past data from USGS. Locking at the metadata you provided I would say that you are in an EPSG:2238 Lambert Conformal Conic projection, which is the main projection system for north Florida. You may try to specify to GDAL the source projection using this EPSG code. Regards, Christian Yes, it worked! However, i dont understand how did you figure out that projection is 2238. No such a number is presented into metadata. For a test, i also used EPGS:3857 and it seems to work similar. Thanks a lot! Elias. Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64020#64020 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Département Commande des Systèmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Correct way to get texture data from USGS or any other source?
Hello! I totally agree with Sebastian. These data is surely geo-referenced, as I myself often used in the past data from USGS. Locking at the metadata you provided I would say that you are in an EPSG:2238 Lambert Conformal Conic projection, which is the main projection system for north Florida. You may try to specify to GDAL the source projection using this EPSG code. Regards, Christian Le 09/06/2015 12:59, Sebastian Messerschmidt a écrit : Am 09.06.2015 um 11:35 schrieb Elias Tarasov: Hello! I try to build map using vpb in ECEF. According to manuals i've read it needs to start: vpbmaster --geocentric -t texture_file -o output_file So, clearly i need georeferenced texture file. On that page: http://www.osgvisual.org/projects/osgvisual/wiki/OsgTerrainData there is a bunch of links to get data. Since --geocentric option allows not to use elevation data, then only textures are needed. Who told you this? Of course you can use elevation data in geocentric mode ... Simply use -t for imagery and -d for digitial elevation data And here is a problem: i can't get georeferenced textures from USGS. They are referenced, but in a non-supported coordinate frame. I never had problems of this kind yet. But there are definitively geo-referenced data-sets on USGS, as I'm using them myself. Use LandSAT imagery, which is WGS84 projected, so there should no problems here. If you need some sample data I can share a small set on googledrive etc. All files i choose from different sets there are without georeferenced information. gdalinfo output: ... Yes it seems there is no valid projection. But still the data is referenced. What am i doing wrong? Without having your data, this is hard to tell Thanks a lot and best regards! Elias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63998#63998 ___ 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 -- SCHULTE Christian Ingénieur Recherche Responsable du Laboratoire de Simulation ONERA - DCSD/PSEV Département Commande des Systèmes et Dynamique du Vol ONERA - Centre de Salon de Provence BA 701 13661 SALON AIR Cedex - France Tel :04.90.17.01.45 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Matrox M9188 OpenGL
Hi Chris, I agree with Sergey, I'm myself using for research helicopter flight simulation a ATI Eyefinity 6x with VSync activated in order to generate 6 views in a composite viewer each for one video projector without any problems. The card we are using is an ATI Eyefinity 6 Radeon HD 5870 with 1GB GDDR5, but I've seen that you could have up to 2GB on the new version. Cheers, Christian Le 25/04/2013 20:13, Sergey Kurdakov a crit: Hi Chris, It is my understanding that AMD cards won't frame-lock without the S400 card you might be correct, but you mentioned, that rendering in not very demanding, thus setting VSync might be enough to soft-frame-lock on powerful card ( which should be oders of magnitude more powerful than old Matrox cards ) Regards Sergey ___ 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] : Cannot compile DDS plugin GL_HALF_FLOAT not defined in this scope
Hi Robert, I agree with you that there is no other way than testing. Maybe we could make an platform dependent include of math.h instead of cmath for the platforms you think there is a risk (like IRIX) on the trunk and ask the community to test it. Christian Le 01/02/2013 10:13, Robert Osfield a écrit : Hi Christian, On 1 February 2013 07:31, Christian Schulte christian.schu...@onera.fr wrote: my nightly build worked fine on RedHat 5.3(64bits) but also on CentOS 6.3(64bits), WinXP(32bits)¨and Win7(64bits). Thanks again for your quick answer and solution. By the way did you think about how to correct the math.h problem (regarding the round function, see discussion [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR) ? In our environment I have recompiled all OSG 3.0.1 and trunk replacing math.h by cmath in include/osg/Math and didn't have any problems until now. The only way to find out whether cmath is safe to use in include/osg/Math is to do it and then get the community to test across the full set of platforms. Problem areas are likely to be HP-UX, AIX, Solaris and IRIX. The later being the most likely to be a problem but it's also not something we official support now as no one tests on that platform that I'm aware of. Perhaps we could put a CMAKE variable into control whether to use cmath or math.h in case using cmath is problematic. This does add complexity though and if we don't need it it'll be a waste of time. There is no way for me to know until we do wider testing. 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
[osg-users] [osgPlugins] : Cannot compile DDS plugin GL_HALF_FLOAT not defined in this scope
Hi, I just tried to recompile on a RedHat Enterprise 5.3 with gcc 4.7.2 the OSG trunk. The compilation fails on ReaderWriterDDS.cpp on a error : 'GL_HALF_FLOAT' not declared in this scope. I use Mesa 6.5.1, it's the last release recognized by yum on RedHat (I know it's quite old... :-( ). In include/osg/Texture, GL_HALF_FLOAT is defined only if GL_ARB_half_float_pixel is not defined. The problem is that glext.h does define GL_ARB_half_float_pixel, GL_HALF_FLOAT_ARB and GL_HALF_FLOAT_NV but not the GL_HALF_FLOAT. Adding to include/osg/Texture at line 400 : #ifndef GL_ARB_half_float_vertex #define GL_HALF_FLOAT0x140B #endif corrects the problem on this type of configuration. Does this mod induce any problems on other platforms ? What's your opinion ? Cheers, Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] : Cannot compile DDS plugin GL_HALF_FLOAT not defined in this scope
Hi Robert, my nightly build worked fine on RedHat 5.3(64bits) but also on CentOS 6.3(64bits), WinXP(32bits)¨and Win7(64bits). Thanks again for your quick answer and solution. By the way did you think about how to correct the math.h problem (regarding the round function, see discussion [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR) ? In our environment I have recompiled all OSG 3.0.1 and trunk replacing math.h by cmath in include/osg/Math and didn't have any problems until now. Cheers, Christian Le 31/01/2013 17:28, Robert Osfield a écrit : Hi Christian, I have had a look through the OSG code base and there is mix of GL_HALF_FLOAT, GL_HALF_FLOAT_NV and GL_HALF_FLOAT_ARB thanks to various submissions at different times. This obviously isn't ideal so I've replaced all the L_HALF_FLOAT_NV and GL_HALF_FLOAT_ARB usage with GL_HALF_FLOAT and changed the #define in include/osg/Texture to simply: #ifndef GL_HALF_FLOAT #define GL_HALF_FLOAT0x140B #endif Could you do an svn update and let me know how you get on. Thanks, Robert. On 31 January 2013 16:10, Christian Schulte christian.schu...@onera.fr wrote: Hi, I just tried to recompile on a RedHat Enterprise 5.3 with gcc 4.7.2 the OSG trunk. The compilation fails on ReaderWriterDDS.cpp on a error : 'GL_HALF_FLOAT' not declared in this scope. I use Mesa 6.5.1, it's the last release recognized by yum on RedHat (I know it's quite old... :-( ). In include/osg/Texture, GL_HALF_FLOAT is defined only if GL_ARB_half_float_pixel is not defined. The problem is that glext.h does define GL_ARB_half_float_pixel, GL_HALF_FLOAT_ARB and GL_HALF_FLOAT_NV but not the GL_HALF_FLOAT. Adding to include/osg/Texture at line 400 : #ifndef GL_ARB_half_float_vertex #define GL_HALF_FLOAT0x140B #endif corrects the problem on this type of configuration. Does this mod induce any problems on other platforms ? What's your opinion ? Cheers, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Hi, I think it is used as cross-checking method. Indeed, if the calculated number (using osg::Image) is less than the number of mipmaps specified in the dds file, the calculated value is kept. On the other hand if the theoretical number of possible mipmaps is higher than the number of mipmaps specified by the dds file, the number used is the one of the dds file. In my opinion, it seems to be possible to have dds files with wrong mipmap informations... Cheers, Christian Le 11/01/2013 13:42, Lukasz Izdebski a écrit : Hi, I have a question. Why while reading dds file, to set number of mipmaps it is using function osg::Image::computeNumberOfMipmapLevels( s, t, r ) but not what is written in dds file header ? I think that dds file knows better how many mipmaps it has inside. Thank you! Cheers, Lukasz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51911#51911 ___ 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] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Hi, I didn't either find such a program being able to give a wrong number of mipmaps, I only said that it may exist... Maybe it is better if Wojciech explains us why he made this calculations. If we can indeed don't make it it is ok for me, but it does not change anything to the fact that the floor calculation is wrong on gcc under windows using math.h. And by the way, I checked, it is not the only place in OSG code where floor is used. So maybe it is still better to correct this behaviour. I just recompiled OSG on win xp, win7 and linux and in all cases no problems appeared by replacing math.h by cmath in include/osg/Math. However, I saw some other places where math.h has been included, maybe it will be necessary to change all math.h to cmath and not only the one in include/osg/Math. Cheers, Christian Le 11/01/2013 15:00, Lukasz Izdebski a écrit : Hi, But for example we have 512x512 dds texture compressed with DXT1 and in header we have 4 mipmaps. In this example is meaningless to compute number of mipmaps, because OpenGL ,with my knowledge, does not generate mipmaps for compressed textures. So setting bigger number of mipmaps is wrong. I didn't find a program which generate dds and write wrong number of mipmaps. If it does change the program :). Thank you! Cheers, Lukasz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51914#51914 ___ 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] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Hi, I just tried the compilation of my test code on Microsoft Visual C++, and the problem does not appear so it seems gcc linked... I will try to recompile OSG on my different platforms using cmath in osg/Math, hoping we don't see any other bugs. Will keep you informed later today. Christian Le 09/01/2013 20:41, Jason Daly a écrit : I was about to ask why we aren't just using the log2 function here, but apparently Microsoft doesn't consider this C99-standard function to be important (ie: it's not included in Microsoft's math.h). Seems like cmath is indeed the best solution. --J On 01/09/2013 11:39 AM, Christian Schulte wrote: Hi Robert, I think the problem is linked indeed to a MS math.h problem, but in my opinion it is not linked directly to the floor function but could affect even other functions. I don't know what would be the consequences on the global OSG behaviour but I agree with you that replacing the math.h include would be the best solution. Maybe someone could try to compile my little test code with a Microsoft compiler to see if it is gcc linked or Windows linked. Cheers, Christian Le 09/01/2013 16:50, Robert Osfield a écrit : Hi Christian, Does this mean there is a bug in the MS version of math.h and the floor function it provides? Previously we haven't used cmath as some platforms didn't support it properly, I recall IRIX being a problem, but am not sure if it extends further than this. IRIX support has long been deprecated so won't be a constraint these days. So... using #includecmath could well be a viable solution, It does still concern me that the MS version of math.h is giving different results to cmath. Robert. On 9 January 2013 15:27, Christian Schultechristian.schu...@onera.fr wrote: Hi all, I have investigated a little deeper the problem... Indeed, on Windows platform, the number of mipmaps returned by osg::Image::computeNumberOfMipmapLevels( s, t, r ) is wrong, but it is correct on Linux platforms for the same dds file... Here is attached a little test program that explains why (it is more or less a computeNumberOfMipmapLevels with s=t=1024 and r=1), and it is not linked to OSG. Compile it on Windows 32 bits (works on Win7 and WinXP) (g++ main.cpp -o main.exe) You will see the following result : logf(wf) = 6.93147182464599609375 log(wd)= 6.93147180559945308431 logf(2.0f) = 0.69314718246459960938 log(2.0) = 0.69314718055994528623 logf(wf)/logf(2.0f)= 10. log(wd)/log(2.0) = 10. floor(logf(wf)/logf(2.0f)) = 9. - Here is the error, it should be 10 too... floor(log(wd)/log(2.0))= 10. floor(testf) = 10. floor(testd) = 10. Replacing the include of math.h by cmath results in : logf(wf) = 6.93147182464599609375 log(wd)= 6.93147180559945308431 logf(2.0f) = 0.69314718246459960938 log(2.0) = 0.69314718055994528623 logf(wf)/logf(2.0f)= 10. log(wd)/log(2.0) = 10. floor(logf(wf)/logf(2.0f)) = 10. floor(log(wd)/log(2.0))= 10. floor(testf) = 10. floor(testd) = 10. Under Linux both solutions give the second results. The problem is that osg/Math includes math.h and not cmath. I don't know which would be the best solution : Replace math.h by cmath in include/osg/Math Store the logf division (float testf = logf(wf)/logf(2.0f)) of osg::Image::computeNumberOfMipmapLevels( s, t, r ) in a float before computing the floor. Up to the list to give the answer... PS : this is also the solution to the discussion osgPlugins : dds problem on windows platform I launched 07/03/2011 Cheers, Christian Schulte Le 20/12/2012 15:15, Lukasz Izdebski a écrit : Hi, i probably have solution for this problem, i have found a bug in dds plugin ReaderWriterDDS.cpp Line 633 unsigned numMipmaps = osg::Image::computeNumberOfMipmapLevels( s, t, r ); when compute numMipmaps returns wrong number. this number is less then number of mipmaps in dds file( ddsd.dwMipMapCount ) . This bug makes that when dds mipmaps are loaded to opengl last mipmap (4x4) isn't loaded. and with combination with LINEAR_MIPMAP_LINEAR make this bug. the numMipmaps should be taken form ddsd.dwMipMapCount in attachment i send a corrected version of file. ... Thank you! Cheers, Lukasz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51653#51653 Attachments: http://forum.openscenegraph.org//files/readerwriterdds_204.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Robert, I just tried another solution, which works and is maybe, let's say, more correct from a coding point of view. Indeed, we want to floor a division of two floats, so we should logically use floorf instead of floor, because in math.h floor is only double. That's also the reason we don't have the error with cmath because we have a float overload of the double floor(double). What do you think about this solution ? (I will still try to see which are the consequences of replacing math.h by cmath, but it will be a little longer :-) ) Cheers, Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant with optimization MERGE_GEOMETRY and MAKE_FAST_GEOMETRY
Hi all,
I bring up this post again to see if someone else than me has this
problem. I still have this kind of problem with the trunk of OSG,
and I don't know why this really happens...
The only actual solution is OSG_OPTIMIZER="DEFAULT
~MAKE_FAST_GEOMETRY"
Cheers,
Christian
Le 24/04/2012 09:18, Christian Schulte a crit:
Hi all,
I am migrating our simulation environment from OSG 2.8.3 to OSG
3.0.0-rc1 and have some problems with a quite huge multi LOD
database we use daily. Indeed we receive continuously an openGL
error "Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)". After a very long tracking in optmization
options and in the database itself we finally were able to find
the problem... but not the solution.
In the joined file you will find a simple geometry (these are in
reality two roofs of houses placed on the database) causing the
OpenGL error.
In order to reproduce the error set the OSG_OPTIMZER environment
variable to "MERGE_GEOMETRY MAKE_FAST_GEOMETRY"
Removing MAKE_FAST_GEOMETRY from the OSG_OPTIMIZER variable
suppress the warning...
The other way to correct this error is to transform in the osg
file
PrimitiveSets 2
{
DrawArrays TRIANGLES 0 18
DrawArrays TRIANGLES 18 18
}
to
PrimitiveSets 1
{
DrawArrays TRIANGLES 0 36
}
Does anyone have an idea of the origin of this problem and how to
correct (or avoid) this error (other solution than modifying the
OSG_OPTIMIZER or correcting all the different lods..) ?
Cheers,
SCHULTE
Christian
Research Engineer
in charge of the Simulation Laboratory
System Control and Flight Dynamics Department
Simulation and Flight Testing Unit
ONERA - The French Aerospace Lab
Ecole de l'Air - BA 701
13661 SALON cedex AIR
FRANCE
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Group {
name Obj Group
nodeMask 0x
cullingActive TRUE
num_children 1
LOD {
name GeomObject_0-4378
nodeMask 0x
cullingActive TRUE
Center 238.723 -437.402 8.54999
Radius -1
RangeMode DISTANCE_FROM_EYE_POINT
RangeList 1 {
0 4378.56
}
num_children 1
Group {
DataVariance STATIC
name Merge Group
nodeMask 0x
cullingActive TRUE
num_children 1
Geode {
DataVariance STATIC
name merged Objects
nodeMask 0x
cullingActive TRUE
StateSet {
UniqueID StateSet_0
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
textureUnit 0 {
GL_TEXTURE_2D ON
}
}
num_drawables 1
Geometry {
DataVariance STATIC
Use StateSet_0
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 2
{
DrawArrays TRIANGLES 0 18
DrawArrays TRIANGLES 18 18
}
VertexArray Vec3Array 28
{
389.165 -234.038 11.9992
394.657 -240.028 11.9992
394.872 -235.067 14.5505
394.126 -234.253 14.5505
394.341 -229.291 11.9992
389.165 -234.038 11.9992
394.126 -234.253 14.5505
399.833 -235.282 11.9992
394.341 -229.291 11.9992
394.126 -234.253 14.5505
394.872 -235.067 14.5505
394.657 -240.028 11.9992
399.833 -235.282 11.9992
394.872 -235.067 14.5505
346.808 -266.449 12.0013
351.408 -266.736 12.0013
349.251 -264.292 13.6757
347.307 -258.461 12.0013
346.808 -266.449 12.0013
349.251 -264.292 13.6757
349.463 -260.905 13.6757
351.907 -258.748 12.0013
347.307 -258.461 12.0013
349.463 -260.905 13.6757
351.408 -266.736 12.0013
351.907 -258.748 12.0013
349.463 -260.905 13.6757
349.251 -264.292 13.6757
}
VertexIndices UIntArray 36
{
0 1 2 2 3 0 4 5 6 7
8 9 9 10 7 11 12 13 14 15
16 17 18 19 19 20 17 21 22 23
24 25 26 26 27 24
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 28
{
Re: [osg-users] invalid enumerant with optimization MERGE_GEOMETRY and MAKE_FAST_GEOMETRY
Hi Robert,
yes I also tried on this little code to make an osgconv, that's
the way I used to find that the problem comes from the
PrimitiveSets. The file generated by osgconv merges the two
primitiveSets in only one, ie :
Before :
PrimitiveSets 2
{
DrawArrays TRIANGLES 0 18
DrawArrays TRIANGLES 18 18
}
After:
PrimitiveSets 1
{
DrawArrays TRIANGLES 0 36
}
The problem is that my database is a multifile ive database (962
ive files) with external image files (1669 dds files) so I have no
clue how to correct these errors on the whole database (because
this error happens ofter than once, nearly on each roof of the
houses in the database
:o ). I don't know how the database has
been generated, we bought it several years ago for our simulation
laboratory, so the creation process is not known.
Cheers,
Christian
Le 10/01/2013 11:20, Robert Osfield a crit:
Hi Christian,
On 10 January 2013 09:46, Christian Schulte christian.schu...@onera.fr wrote:
I bring up this post again to see if someone else than me has this problem.
I still have this kind of problem with the trunk of OSG, and I don't know
why this really happens...
The only actual solution is OSG_OPTIMIZER="DEFAULT ~MAKE_FAST_GEOMETRY"
I have just tried running your model on my Linux box and I get the
"Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)" when the optimizer is it's default form.
Curiously if I run osgconv on the model which will run the optimizer
and then write out a new file, if I load this new file it works fine -
even without changing the optimizer options.
This behaviour would suggest that the optimizer is creating some scene
graph state that generates invalid OpenGL data when rendering but this
state isn't saved and reloaded. From your investigation it'd look to
be the MAKE_FAST_GEOMETRY option that is introducing this issue,
however, the odd thing is the resulting .osg that osgconv generates
still has the vertex indices in the scene graph.
BTW, how did you generate the original model with vertex indices?
vertex indices are very much a deprecated and strongly recommend not
to use feature of the OSG that is only still available for backwards
compatibility.
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] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Hi all,
I have investigated a little deeper the problem... Indeed, on
Windows platform, the number of mipmaps returned by
osg::Image::computeNumberOfMipmapLevels( s, t, r ) is wrong, but
it is correct on Linux platforms for the same dds file...
Here is attached a little test program that explains why (it is
more or less a computeNumberOfMipmapLevels with s=t=1024 and r=1),
and it is not linked to OSG. Compile it on Windows 32 bits (works
on Win7 and WinXP) (g++ main.cpp -o main.exe) You will see the
following result :
logf(wf) = 6.93147182464599609375
log(wd) = 6.93147180559945308431
logf(2.0f) = 0.69314718246459960938
log(2.0) = 0.69314718055994528623
logf(wf)/logf(2.0f) = 10.
log(wd)/log(2.0) = 10.
floor(logf(wf)/logf(2.0f)) = 9. - Here
is the error, it should be 10 too...
floor(log(wd)/log(2.0)) = 10.
floor(testf) = 10.
floor(testd) = 10.
Replacing the include of math.h by cmath results in :
logf(wf) = 6.93147182464599609375
log(wd) = 6.93147180559945308431
logf(2.0f) = 0.69314718246459960938
log(2.0) = 0.69314718055994528623
logf(wf)/logf(2.0f) = 10.
log(wd)/log(2.0) = 10.
floor(logf(wf)/logf(2.0f)) = 10.
floor(log(wd)/log(2.0)) = 10.
floor(testf) = 10.
floor(testd) = 10.
Under Linux both solutions give the second results.
The problem is that osg/Math includes math.h and not cmath. I
don't know which would be the best solution :
Replace math.h by cmath in include/osg/Math
Store the logf division (float testf = logf(wf)/logf(2.0f))
of osg::Image::computeNumberOfMipmapLevels( s, t, r ) in a
float before computing the floor.
Up to the list to give the answer...
PS : this is also the solution to the discussion "osgPlugins :
dds problem on windows platform" I launched 07/03/2011
Cheers,
Christian Schulte
Le 20/12/2012 15:15, Lukasz Izdebski a crit:
Hi,
i probably have solution for this problem, i have found a bug in dds plugin
ReaderWriterDDS.cpp
Line 633
unsigned numMipmaps = osg::Image::computeNumberOfMipmapLevels( s, t, r );
when compute numMipmaps returns wrong number. this number is less then number of mipmaps in dds file( ddsd.dwMipMapCount ) . This bug makes that when dds mipmaps are loaded to opengl last mipmap (4x4) isn't loaded. and with combination with LINEAR_MIPMAP_LINEAR make this bug.
the numMipmaps should be taken form ddsd.dwMipMapCount
in attachment i send a corrected version of file.
...
Thank you!
Cheers,
Lukasz
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51653#51653
Attachments:
http://forum.openscenegraph.org//files/readerwriterdds_204.cpp
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#include math.h
#include stdio.h
#include iostream
using namespace std;
int main(int argc, char** argv)
{
double wd=1024.0;
float wf=1024.0;
cout.precision(20);
cout.setf(ios::fixed,ios::floatfield);
coutlogf(wf) = logf(wf)endl;
coutlog(wd)= log(wd)endl;
coutlogf(2.0f) = logf(2.0f)endl;
coutlog(2.0) = log(2.0)endl;
coutlogf(wf)/logf(2.0f)= logf(wf)/logf(2.0f)endl;
coutlog(wd)/log(2.0) = log(wd)/log(2.0)endl;
coutfloor(logf(wf)/logf(2.0f)) = floor(logf(wf)/logf(2.0f))endl;
coutfloor(log(wd)/log(2.0))= floor(log(wd)/log(2.0))endl;
float testf = logf(wf)/logf(2.0f);
double testd = log(wd)/log(2.0);
coutfloor(testf) = floor(testf)endl;
coutfloor(testd) = floor(testd)endl;
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Hi Robert, I think the problem is linked indeed to a MS math.h problem, but in my opinion it is not linked directly to the floor function but could affect even other functions. I don't know what would be the consequences on the global OSG behaviour but I agree with you that replacing the math.h include would be the best solution. Maybe someone could try to compile my little test code with a Microsoft compiler to see if it is gcc linked or Windows linked. Cheers, Christian Le 09/01/2013 16:50, Robert Osfield a écrit : Hi Christian, Does this mean there is a bug in the MS version of math.h and the floor function it provides? Previously we haven't used cmath as some platforms didn't support it properly, I recall IRIX being a problem, but am not sure if it extends further than this. IRIX support has long been deprecated so won't be a constraint these days. So... using #includecmath could well be a viable solution, It does still concern me that the MS version of math.h is giving different results to cmath. Robert. On 9 January 2013 15:27, Christian Schulte christian.schu...@onera.fr wrote: Hi all, I have investigated a little deeper the problem... Indeed, on Windows platform, the number of mipmaps returned by osg::Image::computeNumberOfMipmapLevels( s, t, r ) is wrong, but it is correct on Linux platforms for the same dds file... Here is attached a little test program that explains why (it is more or less a computeNumberOfMipmapLevels with s=t=1024 and r=1), and it is not linked to OSG. Compile it on Windows 32 bits (works on Win7 and WinXP) (g++ main.cpp -o main.exe) You will see the following result : logf(wf) = 6.93147182464599609375 log(wd)= 6.93147180559945308431 logf(2.0f) = 0.69314718246459960938 log(2.0) = 0.69314718055994528623 logf(wf)/logf(2.0f)= 10. log(wd)/log(2.0) = 10. floor(logf(wf)/logf(2.0f)) = 9. - Here is the error, it should be 10 too... floor(log(wd)/log(2.0))= 10. floor(testf) = 10. floor(testd) = 10. Replacing the include of math.h by cmath results in : logf(wf) = 6.93147182464599609375 log(wd)= 6.93147180559945308431 logf(2.0f) = 0.69314718246459960938 log(2.0) = 0.69314718055994528623 logf(wf)/logf(2.0f)= 10. log(wd)/log(2.0) = 10. floor(logf(wf)/logf(2.0f)) = 10. floor(log(wd)/log(2.0))= 10. floor(testf) = 10. floor(testd) = 10. Under Linux both solutions give the second results. The problem is that osg/Math includes math.h and not cmath. I don't know which would be the best solution : Replace math.h by cmath in include/osg/Math Store the logf division (float testf = logf(wf)/logf(2.0f)) of osg::Image::computeNumberOfMipmapLevels( s, t, r ) in a float before computing the floor. Up to the list to give the answer... PS : this is also the solution to the discussion osgPlugins : dds problem on windows platform I launched 07/03/2011 Cheers, Christian Schulte Le 20/12/2012 15:15, Lukasz Izdebski a écrit : Hi, i probably have solution for this problem, i have found a bug in dds plugin ReaderWriterDDS.cpp Line 633 unsigned numMipmaps = osg::Image::computeNumberOfMipmapLevels( s, t, r ); when compute numMipmaps returns wrong number. this number is less then number of mipmaps in dds file( ddsd.dwMipMapCount ) . This bug makes that when dds mipmaps are loaded to opengl last mipmap (4x4) isn't loaded. and with combination with LINEAR_MIPMAP_LINEAR make this bug. the numMipmaps should be taken form ddsd.dwMipMapCount in attachment i send a corrected version of file. ... Thank you! Cheers, Lukasz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51653#51653 Attachments: http://forum.openscenegraph.org//files/readerwriterdds_204.cpp ___ 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] OSC plugin on Windows?
Hi Paul, Hi Stephan, looking at the errors the missing windows lib would be the one containing the network features, as I know it is the basic WinSock library ws2_32.dll. cheers, Christian Le 19/11/2012 20:32, Stephan Huber a écrit : Hi Paul, thanks for the feedback! Yes, osc should compile on windows, but I forgot to disable the windows build as I haven't had time to test it on this platform. Afaik only an additional windows-lib is missing in the cmake-file. I'll submit a modified camke-file, so the osc-plugin is disabled for win, as long as I haven't fixed the buld, cheers, Stephan Am 19.11.12 19:36, schrieb Paul Martz: Hi Stephan -- Is the OSC plugin tested on Windows? I'm getting several undefined symbols during link using VS2010, building 32bit on Win7 (see below). I don't see any CMake controls to disallow this plugin on Windows, so I'm guessing these are build errors that should be fixed. -Paul 1NetworkingUtils.obj : error LNK2019: unresolved external symbol __imp__WSAStartup@8 referenced in function public: __thiscall NetworkInitializer::NetworkInitializer(void) (??0NetworkInitializer@@QAE@XZ) 1NetworkingUtils.obj : error LNK2019: unresolved external symbol __imp__WSACleanup@0 referenced in function public: __thiscall NetworkInitializer::~NetworkInitializer(void) (??1NetworkInitializer@@QAE@XZ) 1NetworkingUtils.obj : error LNK2019: unresolved external symbol __imp__ntohl@4 referenced in function unsigned long __cdecl GetHostByName(char const *) (?GetHostByName@@YAKPBD@Z) 1UdpSocket.obj : error LNK2001: unresolved external symbol __imp__ntohl@4 1NetworkingUtils.obj : error LNK2019: unresolved external symbol __imp__gethostbyname@4 referenced in function unsigned long __cdecl GetHostByName(char const *) (?GetHostByName@@YAKPBD@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__htons@4 referenced in function void __cdecl SockaddrFromIpEndpointName(struct sockaddr_in ,class IpEndpointName const ) (?SockaddrFromIpEndpointName@@YAXAAUsockaddr_in@@ABVIpEndpointName@@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__htonl@4 referenced in function void __cdecl SockaddrFromIpEndpointName(struct sockaddr_in ,class IpEndpointName const ) (?SockaddrFromIpEndpointName@@YAXAAUsockaddr_in@@ABVIpEndpointName@@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__ntohs@4 referenced in function class IpEndpointName __cdecl IpEndpointNameFromSockaddr(struct sockaddr_in const ) (?IpEndpointNameFromSockaddr@@YA?AVIpEndpointName@@ABUsockaddr_in@@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__socket@12 referenced in function public: __thiscall UdpSocket::Implementation::Implementation(void) (??0Implementation@UdpSocket@@QAE@XZ) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__closesocket@4 referenced in function public: __thiscall UdpSocket::Implementation::~Implementation(void) (??1Implementation@UdpSocket@@QAE@XZ) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__WSAGetLastError@0 referenced in function public: class IpEndpointName __thiscall UdpSocket::Implementation::LocalEndpointFor(class IpEndpointName const )const (?LocalEndpointFor@Implementation@UdpSocket@@QBE?AVIpEndpointName@@ABV3@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__getsockname@12 referenced in function public: class IpEndpointName __thiscall UdpSocket::Implementation::LocalEndpointFor(class IpEndpointName const )const (?LocalEndpointFor@Implementation@UdpSocket@@QBE?AVIpEndpointName@@ABV3@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__connect@12 referenced in function public: class IpEndpointName __thiscall UdpSocket::Implementation::LocalEndpointFor(class IpEndpointName const )const (?LocalEndpointFor@Implementation@UdpSocket@@QBE?AVIpEndpointName@@ABV3@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__send@16 referenced in function public: void __thiscall UdpSocket::Implementation::Send(char const *,int) (?Send@Implementation@UdpSocket@@QAEXPBDH@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__sendto@24 referenced in function public: void __thiscall UdpSocket::Implementation::SendTo(class IpEndpointName const ,char const *,int) (?SendTo@Implementation@UdpSocket@@QAEXABVIpEndpointName@@PBDH@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__bind@12 referenced in function public: void __thiscall UdpSocket::Implementation::Bind(class IpEndpointName const ) (?Bind@Implementation@UdpSocket@@QAEXABVIpEndpointName@@@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__recvfrom@24 referenced in function public: int __thiscall UdpSocket::Implementation::ReceiveFrom(class IpEndpointName ,char *,int) (?ReceiveFrom@Implementation@UdpSocket@@QAEHAAVIpEndpointName@@PADH@Z) 1UdpSocket.obj : error LNK2019: unresolved external symbol __imp__timeGetTime@0 referenced in function private: double __thiscall
[osg-users] StateSet UpdateCallback on a camera
Hi everyone,
I'm facing a problem in our flight simulation environment, where we
want to make the fog camera dependent ( in order to have cameras
without fog for simulation control). I tried to follow the 2009
thread "[osg-users] Set fog in the canera StateSet" and succeded to
implement a non variyng fog. But in our case we have a
statesetcallback for changing the parameter of the fog and one for
activating disactivating the fog.
This is how was set the fog before (one fog for all views) :
/*
* Fog
*/
Fog * fog = pe-getFog(); // pe is a
osgParticle::PrecipitationEffect
root-getOrCreateStateSet()-setAttributeAndModes(fog,
osg::StateAttribute::ON);
fog-setUpdateCallback(new vesaFogUpdateCallback);
root-getOrCreateStateSet()-setUpdateCallback(new
vesaFogEnableUpdateCallback);
But, adding the fog to our different views, neither the
vesaFogUpdateCallback nor the vesaFogEnableUpdateCallback are
accessed anymore... This is the code I tryed to implement :
BOOST_FOREACH(propTreeNode v,
arbreUtile-getOptionalChildProperties("graphic.windows.views"))
{
propTreeHolder pView(v.second);
if(pView.empty() || v.first.compare("msgFile")==0 ||
v.first.compare("activeView")==0)
continue;
std::string name = v.first;
osgViewer::View* view = new osgViewer::View;
view-setName(name);
addView(view);
view-setSceneData(root);
view-getCamera()-setName(name);
view-getCamera()-setClearColor(fog-getColor());
view-getCamera()-setViewport(
new osg::Viewport(
traits-width *
pView.getPropValuefloat("xMin",0.0),
traits-height *
pView.getPropValuefloat("yMin",0.0),
traits-width *
pView.getPropValuefloat("sizeX",1.0),
traits-height *
pView.getPropValuefloat("sizeY",1.0)
)
);
view-getCamera()-setGraphicsContext(gc.get());
view-getCamera()-setCullSettings(cs);
if
(arbreUtile-getPropValuebool("graphic.windows.views."+name+
".effects.withFog",true))
{
osg::ref_ptrosg::Fog fog = new osg::Fog();
floatvarNear = 0.0f;
floatend = 0.0f;
floatdensity = 0.0f;
std::string tmp = "";
osg::Fog::Mode mode;
osg::Vec4f color;
/*
* Get values
*/
varNear =
arbreUtile-getPropValuefloat("sim.environement.fog.start",
1.);
end =
arbreUtile-getPropValuefloat("sim.environement.fog.end",
2.);
density =
arbreUtile-getPropValuefloat("sim.environement.fog.density",
0.1);
color =
arbreUtile-getPropValueosg::Vec4f("sim.environement.fog.color",
osg::Vec4f(0.7,0.7,0.7,1.0));
if((tmp =
arbreUtile-getPropValuestd::string("sim.environement.fog.mode",std::string("exp2")))
== "linear" )
mode = osg::Fog::LINEAR;
else if(tmp == "exp")
mode = osg::Fog::EXP;
else if(tmp == "exp2")
mode = osg::Fog::EXP2;
else
mode = osg::Fog::EXP2;
fog-setMode(mode);
fog-setStart(varNear);
fog-setEnd(end);
fog-setDensity(density);
fog-setColor(color);
view-getCamera()-getOrCreateStateSet()-setAttributeAndModes(fog,
osg::StateAttribute::ON);
fog-setUpdateCallback(new
vesaFogUpdateCallback);
view-getCamera()-getOrCreateStateSet()-setUpdateCallback(new
vesaFogEnableUpdateCallback);
}
}
The solution I found is to create an UpdateCallback for each camera
which implements the code present in both my old Fog callbacks.
Does anyone have an idea of why the UpdateCallBack of the stateset
does not work when associated to a camera ? What am I doing wrong ?
Moreover, I initially tried to activate desactivate the osf::Fog,
the osg::Light and the osgParticle::PrecipitationEffect using a
NodeMask/CullMask logic for each camera. It works for the
PrecipitationEffect, but doesn't for the Fog and the Light. Is it a
normal behaviour or is there something wrong in my code (in which
case I would show you the code).
Thankyou for your help,
SCHULTE
Christian
Research
Engineer
in charge of the Simulation Laboratory
System Control and Flight Dynamics Department
Simulation and Flight Testing Unit
ONERA - The French Aerospace Lab
Ecole de l'Air - BA 701
13661 SALON cedex AIR
FRANCE
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet UpdateCallback on a camera
Thanks Tim for your response,
I will try your solution with an empty UpdateCallBack for the camera.
Concerning multiples views in my application, I didn't post my whole
code, but we are in a class derived from osgViewer::CompositeViewer.
I understand that Fog and Light are not SceneGraphNodes, but in my case
I associated my osg::Light to an osg::LightSource whihc is a node, and
it is this lightSource that I tried to cull, in order to have a view
without any light.
Thanks,
Christian
Le 06/07/2012 11:46, Tim Moore a écrit :
Salut,
On Fri, Jul 6, 2012 at 10:13 AM, Christian Schulte
christian.schu...@onera.fr wrote:
Hi everyone,
I'm facing a problem in our flight simulation environment, where we want to
make the fog camera dependent ( in order to have cameras without fog for
simulation control). I tried to follow the 2009 thread [osg-users] Set fog
in the canera StateSet and succeded to implement a non variyng fog. But in
our case we have a statesetcallback for changing the parameter of the fog
and one for activating disactivating the fog.
...
But, adding the fog to our different views, neither the
vesaFogUpdateCallback nor the vesaFogEnableUpdateCallback are accessed
anymore... This is the code I tryed to implement :
BOOST_FOREACH(propTreeNode v,
arbreUtile-getOptionalChildProperties(graphic.windows.views))
{
propTreeHolder pView(v.second);
if(pView.empty() || v.first.compare(msgFile)==0 ||
v.first.compare(activeView)==0)
continue;
std::string name = v.first;
osgViewer::View* view = new osgViewer::View;
I don't know if this is pseudo-code or not, but generally you don't
create more than one Viewer per application; instead you use
CompositeViewer or slave cameras in one Viewer. However, if this is
working for you, who am I to say different :)
view-setName(name);
addView(view);
view-setSceneData(root);
view-getCamera()-setName(name);
view-getCamera()-setClearColor(fog-getColor());
...
view-getCamera()-getOrCreateStateSet()-setAttributeAndModes(fog,
osg::StateAttribute::ON);
fog-setUpdateCallback(new vesaFogUpdateCallback);
view-getCamera()-getOrCreateStateSet()-setUpdateCallback(new
vesaFogEnableUpdateCallback);
}
}
The solution I found is to create an UpdateCallback for each camera which
implements the code present in both my old Fog callbacks.
Does anyone have an idea of why the UpdateCallBack of the stateset does not
work when associated to a camera ? What am I doing wrong ?
Viewer only runs an UpdateVisitor on a camera if it has an update
callback. This may be a small bug, as you have discovered, as it
ignores the possibility that the camera's state set could have update
callbacks. I believe you will find that your state set update callback
will get run even if you install an empty callback on the camera node.
Tim
Moreover, I initially tried to activate desactivate the osf::Fog, the
osg::Light and the osgParticle::PrecipitationEffect using a
NodeMask/CullMask logic for each camera. It works for the
PrecipitationEffect, but doesn't for the Fog and the Light. Is it a normal
behaviour or is there something wrong in my code (in which case I would show
you the code).
I'm not sure what you mean, as Fog and Light aren't scene graph nodes.
Be sure that any StateAttribute objects have their data variance set
to DYNAMIC.
Tim
Thankyou for your help,
SCHULTE Christian
Research Engineer
in charge of the Simulation Laboratory
System Control and Flight Dynamics Department
Simulation and Flight Testing Unit
ONERA - The French Aerospace Lab
Ecole de l'Air - BA 701
13661 SALON cedex AIR
FRANCE
___
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] invalid enumerant with optimization MERGE_GEOMETRY and MAKE_FAST_GEOMETRY
Hi all,
I am migrating our simulation environment from OSG 2.8.3 to OSG
3.0.0-rc1 and have some problems with a quite huge multi LOD
database we use daily. Indeed we receive continuously an openGL
error "Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)". After a very long tracking in optmization
options and in the database itself we finally were able to find the
problem... but not the solution.
In the joined file you will find a simple geometry (these are in
reality two roofs of houses placed on the database) causing the
OpenGL error.
In order to reproduce the error set the OSG_OPTIMZER environment
variable to "MERGE_GEOMETRY MAKE_FAST_GEOMETRY"
Removing MAKE_FAST_GEOMETRY from the OSG_OPTIMIZER variable suppress
the warning...
The other way to correct this error is to transform in the osg file
PrimitiveSets 2
{
DrawArrays TRIANGLES 0 18
DrawArrays TRIANGLES 18 18
}
to
PrimitiveSets 1
{
DrawArrays TRIANGLES 0 36
}
Does anyone have an idea of the origin of this problem and how to
correct (or avoid) this error (other solution than modifying the
OSG_OPTIMIZER or correcting all the different lods..) ?
Cheers,
SCHULTE
Christian
Research
Engineer
in charge of the Simulation Laboratory
System Control and Flight Dynamics Department
Simulation and Flight Testing Unit
ONERA - The French Aerospace Lab
Ecole de l'Air - BA 701
13661 SALON cedex AIR
FRANCE
Group {
name Obj Group
nodeMask 0x
cullingActive TRUE
num_children 1
LOD {
name GeomObject_0-4378
nodeMask 0x
cullingActive TRUE
Center 238.723 -437.402 8.54999
Radius -1
RangeMode DISTANCE_FROM_EYE_POINT
RangeList 1 {
0 4378.56
}
num_children 1
Group {
DataVariance STATIC
name Merge Group
nodeMask 0x
cullingActive TRUE
num_children 1
Geode {
DataVariance STATIC
name merged Objects
nodeMask 0x
cullingActive TRUE
StateSet {
UniqueID StateSet_0
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
textureUnit 0 {
GL_TEXTURE_2D ON
}
}
num_drawables 1
Geometry {
DataVariance STATIC
Use StateSet_0
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 2
{
DrawArrays TRIANGLES 0 18
DrawArrays TRIANGLES 18 18
}
VertexArray Vec3Array 28
{
389.165 -234.038 11.9992
394.657 -240.028 11.9992
394.872 -235.067 14.5505
394.126 -234.253 14.5505
394.341 -229.291 11.9992
389.165 -234.038 11.9992
394.126 -234.253 14.5505
399.833 -235.282 11.9992
394.341 -229.291 11.9992
394.126 -234.253 14.5505
394.872 -235.067 14.5505
394.657 -240.028 11.9992
399.833 -235.282 11.9992
394.872 -235.067 14.5505
346.808 -266.449 12.0013
351.408 -266.736 12.0013
349.251 -264.292 13.6757
347.307 -258.461 12.0013
346.808 -266.449 12.0013
349.251 -264.292 13.6757
349.463 -260.905 13.6757
351.907 -258.748 12.0013
347.307 -258.461 12.0013
349.463 -260.905 13.6757
351.408 -266.736 12.0013
351.907 -258.748 12.0013
349.463 -260.905 13.6757
349.251 -264.292 13.6757
}
VertexIndices UIntArray 36
{
0 1 2 2 3 0 4 5 6 7
8 9 9 10 7 11 12 13 14 15
16 17 18 19 19 20 17 21 22 23
24 25 26 26 27 24
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 28
{
-0.329549 -0.416106 0.847498
-0.329549 -0.416106 0.847498
-0.329549 -0.416106 0.847498
-0.329549 -0.416106 0.847498
-0.299824 0.450371 0.840995
-0.299824 0.450371 0.840995
-0.299824 0.450371 0.840995
0.329549 0.416106 0.847498
0.329549 0.416106 0.847498
0.329549 0.416106 0.847498
0.329549 0.416106 0.847498
0.299824 -0.450371 0.840995
0.299824 -0.450371 0.840995
0.299824 -0.450371 0.840995
-0.0266145 -0.586828 0.809274
-0.0266145 -0.586828 0.809274
-0.0266145 -0.586828 0.809274
-0.465507 0.0400426 0.884138
-0.465507 0.0400426 0.884138
[osg-users] Little Warning about using osgGA::GUIEventHandler and linux/input.h
Hello everyone,
after some headaches I have found a solution to a compile problem in
a program using osgGA::GUIEventHandler and linux/input.h (neccesary
for make work an old joystick model, not possible to be modified).
Here is an exctract of the code which throw the error "Expected
unqualified id before :" for lines 619 and 622 :
switch (ea.getEventType())
{
case (osgGA::GUIEventAdapter::FRAME):
{
osgViewer::View* view =
dynamic_castosgViewer::View*(gUIActionAdapter);
if (view == NULL) return false;
updateResolution(view);
break;
}
case (osgGA::GUIEventAdapter::KEYUP):
{
switch (ea.getKey()) {
case ('f'):
arbreUtile-setPropValuebool("graphic.windows.fullScreen",
!arbreUtile-getPropValuebool("graphic.windows.fullScreen",false));
break;
case (osgGA::GUIEventAdapter::KEY_Pause):
arbreUtile-setPropValuebool("sim.pause",!
arbreUtile-getPropValuebool("sim.pause",false));
break;
case
(osgGA::GUIEventAdapter::KEY_F2): // This is line 619
arbreUtile-setPropValuebool("graphic.windows.showGui", !
arbreUtile-getPropValuebool("graphic.windows.showGui",false));
break;
case
(osgGA::GUIEventAdapter::KEY_F12): // This is line 622
arbreUtile-setPropValuebool("graphic.windows.record", !
arbreUtile-getPropValuebool("graphic.windows.record",
false));
break;
default:
break;
}
break;
}
default:
return false;
}
The option "-save-temps" allowed me to have a look at the file after
pre-compiler which gives :
switch (ea.getEventType())
{
case (osgGA::GUIEventAdapter::FRAME):
{
osgViewer::View* view =
dynamic_castosgViewer::View*(gUIActionAdapter);
if (view == NULL) return false;
updateResolution(view);
break;
}
case (osgGA::GUIEventAdapter::KEYUP):
{
switch (ea.getKey()) {
case ('f'):
arbreUtile-setPropValuebool("graphic.windows.fullScreen",
!arbreUtile-getPropValuebool("graphic.windows.fullScreen",false));
break;
case (osgGA::GUIEventAdapter::KEY_Pause):
arbreUtile-setPropValuebool("sim.pause",!
arbreUtile-getPropValuebool("sim.pause",false));
break;
case
(osgGA::GUIEventAdapter::60): // This is line 619
arbreUtile-setPropValuebool("graphic.windows.showGui", !
arbreUtile-getPropValuebool("graphic.windows.showGui",false));
break;
case
(osgGA::GUIEventAdapter::80): // This is line 622
arbreUtile-setPropValuebool("graphic.windows.record", !
arbreUtile-getPropValuebool("graphic.windows.record",
false));
break;
default:
break;
}
break;
}
default:
return false;
}
As you can see, KEY_F2 and KEY_F12 has been replaced by a numeric
value, but not KEY_Pause... In fact the file linux/input.h contains
a list of define for the keyboard, including :
#define KEY_F2 60
...
#define KEY_F12 88
...
#define KEY_PAUSE 119
Temporally, we had to undef KEY_F2 and KEY_12 in order to compile
and link correctly our program.
I you have some hints to do this differently and in a cleaner way
:-) I'm ready to test other solutions (but I cannot exclude
linux/input.h)
Thanks,
Cheers
Christian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG website error
Hello everyone, from France I receive following response trying to log to www.openscenegraph.org : Traceback (most recent call last): File /usr/lib/python2.5/site-packages/trac/web/api.py, line 339, in send_error 'text/html') File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 684, in render_template data = self.populate_data(req, data) File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 592, in populate_data d['chrome'].update(req.chrome) File /usr/lib/python2.5/site-packages/trac/web/api.py, line 168, in __getattr__ value = self.callbacks[name](self) File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 460, in prepare_request for category, name, text in contributor.get_navigation_items(req): File /usr/lib/python2.5/site-packages/trac/versioncontrol/web_ui/browser.py, line 295, in get_navigation_items if 'BROWSER_VIEW' in req.perm: File /usr/lib/python2.5/site-packages/trac/perm.py, line 523, in has_permission return self._has_permission(action, resource) File /usr/lib/python2.5/site-packages/trac/perm.py, line 537, in _has_permission check_permission(action, perm.username, resource, perm) File /usr/lib/python2.5/site-packages/trac/perm.py, line 424, in check_permission perm) File /usr/lib/python2.5/site-packages/trac/perm.py, line 282, in check_permission get_user_permissions(username) File /usr/lib/python2.5/site-packages/trac/perm.py, line 357, in get_user_permissions for perm in self.store.get_user_permissions(username): File /usr/lib/python2.5/site-packages/trac/perm.py, line 175, in get_user_permissions cursor.execute(SELECT username,action FROM permission) File /usr/lib/python2.5/site-packages/trac/db/util.py, line 51, in execute return self.cursor.execute(sql) File /usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py, line 58, in execute args or []) File /usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py, line 50, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked Does anyone experience the same behaviour ? Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OSG-3.0 branch or 3.0.0-rc7
Hi Robert, sorry for the late response here my compile and run tests : compiles and runs fine on Windows XP 32 bits with gcc 4.5.2 compiles and runs fine on Windows 7 64 bits with gcc 4.5.2 compiles and runs fine on Red Hat Entreprise 5 32 bits with gcc 4.1.2 There is still the problem with the dds plugin that I explained to you in a mail exchange on March 7 and 8 2011 " Subject : osgPlugins : dds problem on windows platform", that appeared after the modifications ofWojtek Lewandowski made the 22.05.2009 cheers, Christian Le 28/06/2011 10:09, Stephan Maximilian Huber a crit: Hi Robert, Am 28.06.11 09:43, schrieb Robert Osfield: I'm now ready to tag 3.0.0 but if users have a OSG-3.0 branch checked out it'd great if you could do a final svn update and build to make sure that I haven't introduced any last minute errors. Rev. 12679 (osg.trunk) compiled w/o errors on OS X 32bit. 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] ATI driver quality?
Hi Chris, we are using on our helicopter flight simulator build with osg 2.9.11 the ATI Radeon HD5870 withh ATI Eyefinity 6 with 1 Go of DDR5 under Windows 7. I agree with J-S on the fact that the drivers are much more stable than before in concern of OpenGL. However the ATI Catalyst drivers are still heavy and some upgrades make the application crash due to incomplete or incorrect implementation of OpenGL 3. Many bug-fixes have been made by AMD/ATI but some problems still remain. Let's say that once you have found a stable driver version, you should keep it as long as possible and only upgrade if you need some new functionalities. In our case we took the ATI card for the Eyefinity technology (6 screens on the same card, and the possibility to rule up to 4 cards in a PC). I don't know the quality of ATI drivers under Linux (I don't neither know which platform you want to use...), maybe some other people may be of any help for the Linux side. Cheers, Christian Le 05/04/2011 20:07, Jean-Sébastien Guay a écrit : Hi Chris, I'm projecting to get a new development system in the next year or so, which means about 6 months of planning before I buy something. Wow, you're a very cautious consumer! :-) I've been on Nvidia for the last few years, and have been mostly happy with the driver support, but I'm looking toward ATI/AMD again because NVidia's OpenCL 64-bit FPU performance is allegedly crippled in their latest consumer hardware, putting it in a severe disadvantage against rival parts from AMD: http://www.anandtech.com/show/2977/nvidia-s-geforce-gtx-480-and-gtx-470-6-months-late-was-it-worth-the-wait-/6 It may be useful to note that the GTX 480 and 470 are not the most recent generation of GPUs from nVidia, there are now the 5xx series. So the information in the above link may be outdated. Maybe it still applies, but it's worth checking out. The other thing is if it's only slower for that particular feature, I wouldn't call that a severe disadvantage. It all depends on what you'll be doing with it. I have a GTX 470 at home, and it's very fast (at least compared to my GTX 260 at work, it's much faster). My main concern with AMD/ATI is the poor quality of drivers I've experienced in past years. I run Win7/64 right now. Can anyone weigh in on the recent quality of these drivers? I haven't directly used ATI cards lately. I have heard they've become much better, but still lagging behind nVidia, mostly with respect to OpenGL driver stability and performance. Perhaps someone here has used recent-generation and comparable cards from both and can better answer - that's pretty much the only way you'll be able to get that information. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgPlugins : dds problem on windows platform
Hello everybody, I recently tried to move my developments from OpenSceneGraph 2.8.3 to OpenScenGraph 2.9.11. The dds plugin seems to not work correctly anymore. If I load a dds (from an ive, osg or directly from an image file) I get no error but no texture is shown at all. I tried it with DXT1 and DXT3 compressed files with no success. By rollback I have been able to find out that it doesn't work aymore since version 2.9.4 and integration of the correction of Wojtek Lewandowski into the dds plugin. Has anyone else these problems or any suggestion to correct them ? Cheers, Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
