Re: [osg-users] Qt5 QMdiArea
BTW, sorry to notice only now that you were explicitely talking about Qt5 in the thread title... Émeric 2015-08-18 16:53 GMT+02:00 Vincent Majorczyk : > Hi Émeric, > thank you for your reply, I forgot to write that I'm trying this on Linux. > Maybe it is an incompatibility problem. > > >> I've added the ViewerWidget class, inheriting from QWidget and >> encompassing the OSG root node, viewer and rendering thread (I'm no >> more using a QTimer) as member attributes. > > > I think the main difference between my implementation and yours is the use of > thread. > >> ViewerWidget::createGraphicsWindow creates the osgQt::GraphicsWindowQt >> as in osgviewerQt example. > > > I didn't change this method. > >> ViewerWidget::addViewWidget creates the OSG view, initializes the >> manipulator, scene graph and camera configuration (as in osgviewerMFC >> example), > > > My class works if I use a QWidget (or a QStackedWidget) as container, but not > if I use QMdiArea or QTabWidget. So I doubts the problem come from > manipulator, scenegraph or camera configuration. > > I would like try with the thread instead of QTimer. What is the library you > used (QThread, OpenThread, std/C++11 , pthread, boost ...) ? How did you > proceed? with Qt5 and OSG Threads, the multithreading model doesn't work: > >> Qt5 is currently crashing and reporting "Cannot make QOpenGLContext current >> in a different thread" when the viewer is run multi-threaded, this is >> regression from Qt4. > > > Vincent[/code] > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=64832#64832 > > > > > > ___ > 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] Qt5 QMdiArea
Hi Vincent, > thank you for your reply, I forgot to write that I'm trying this on Linux. > Maybe it is an incompatibility problem. You're welcome. Actually, the same code run without a problem on the same PC dual-booting Windows 7 Professional and Fedora 21. > My class works if I use a QWidget (or a QStackedWidget) as container, but not > if I use QMdiArea or QTabWidget. So I doubts the problem come from > manipulator, scenegraph or camera configuration. > > I would like try with the thread instead of QTimer. What is the library you > used (QThread, OpenThread, std/C++11 , pthread, boost ...) ? How did you > proceed? with Qt5 and OSG Threads, the multithreading model doesn't work: > >> Qt5 is currently crashing and reporting "Cannot make QOpenGLContext current >> in a different thread" when the viewer is run multi-threaded, this is >> regression from Qt4. OK, I think I get your point. I'm not using Qt5, but Qt 4.8.6 at the moment. My rendering thread inherits from OpenThread (I have a set of various base classes, shared among various viewer implementations, ranging from Qt, MFC or FireBreath plug-in). I have no problem with Qt4 multithreading on Windows, nor on Linux, unless you omit to specify the Qt::AA_X11InitThreads attribute: int main(int argc, char *argv[]) { Q_INIT_RESOURCE(viewerQt); QCoreApplication::setAttribute(Qt::AA_X11InitThreads); QApplication app(argc, argv); app.setOrganizationName("EOS imaging"); app.setApplicationName("osgviewerQt"); MainWindow mainWin; #if defined(Q_OS_SYMBIAN) mainWin.showMaximized(); #else mainWin.show(); #endif return app.exec(); } Émeric > > > Vincent[/code] > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=64832#64832 > > > > > > ___ > 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] View volume image on web
Hi Clement, If by volume, you mean voxels, then you're out of luck, as OpenGL ES, which WebGL relies upon, lacks of 3D texture support [1]. This is something WebGL 2.0 is supposed to solve. In the meantime, there seems to be a trick involving GLSL [2] but I didn't look deep into the code/solution. BTW, how did you use WebGL with OSG? I know of OSG.JS [3], a JavaScript reimplementation of OSG API aiming to develop WebGL applications, but that's a totally different project. [1] https://www.khronos.org/message_boards/showthread.php/7225-3D-textures-in-WebGL [2] http://gamedev.stackexchange.com/questions/34110/how-can-i-implement-3d-textures-using-webgl [3] http://osgjs.org Émeric 2015-05-21 4:30 GMT+02:00 : > Hi, > >I saved my volume image data as dds format by using osgDB::writeImage > method. Does anyone know any method to be able to show dds image on webpage? > I tried webgl and it does not work. I am not sure whether webgl supports > volume rendering or not. Thanks. > > > Regards, > Clement > > > > ___ > 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] StatsHandler missing numbers
Hi Andreas, What release of Intel drivers are you running? I recently experienced issues with an application on various Dell notebooks and Intel NUC barebones (all HD4000-based) where texts printed with glRasterPos3 were not displayed at all with driver release 8.x. Upgrading to release 9.x (from Dell and Intel websites) solved the issue. I didn't found anything clear w.r.t. this problem in the Intel drivers changelogs though. It's noteworthy that the application I was referring to isn't OSG-related (plain OpenGL) and was running on Windows 7 (not 8.1), but who knows! Émeric 2015-04-16 19:56 GMT+02:00 Andreas Schreiber : > Hi, > > same thing happens. > > If it starts in fullscreen the cow modell seems broken. Its part wise > transparent... > If I try making a screenshot, the screenshot is totally fine. > You must think that I'm crazy... > > If I press "s" for the stats in fullscreen the cow modell is shown normally > =). > > In fullscreens they are drawn in a bright gray color. > In window mode you only see the zeros, the others are missing or to bright. > > I must have the newest drivers, but I look at them. > ... > > Thank you! > > Cheers, > Andreas > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=63444#63444 > > > > > ___ > 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] Offscreen rendering (e.g. pbuffer) and event processing
Hi Robert, > Thanks for spotting to typo. I hadn't noticed this before, and it hadn't > been reported either. I am fixing this and will get it checked in once my > clean build has completed. My first major contribution to the OSG community ;-) > As for implementing an off screen viewer functionality using a pbuffer. I > haven't ever tried this on contemplated it. It should be possible to mimic > traditional window events by injecting them into the EventQueue, and you've > spotted passing on the appropriate window size will be required. I can't > provide any specific advice though as you are already further down the road > of trying something I haven't done yet :-) OK, thanks for feedback. For completeness, you'll also had to override ViewerBase::checkEvents() if you want to leverage on viewer's on-demand run scheme. Indeed, the Viewer and CompositeViewer implementations only check for events from devices and windows. With an off-screen viewer, you won't get any window, only views for which you need to take care of setting a graphics contexts as I proposed previously. For a CompositeViewer-inherited off-screen viewer, checkEvents() looks like: bool OffscreenViewer::checkEvents() { if (CompositeViewer::checkEvents()) return true; Views views; getViews(views); // Check events from any views for (Views::iterator vitr = views.begin(); vitr != views.end(); ++vitr) { if ((*vitr)->getEventQueue() && !((*vitr)->getEventQueue()->empty())) return true; } return false; } Hope this helps, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Offscreen rendering (e.g. pbuffer) and event processing
Hi, I should have said that I was drawing the viewer in a pixel buffer in my other question [1], that now leads to this one... I'm streaming the pixel buffer data and displaying/manipulating the scene in/from a webpage. The offscreen viewer obviously hasn't any window, nor associated event queue. I would like to forward the keyboard/mouse inputs emitted by the JavaScript code in my webpage, so that I can leverage upon the OSG manipulators (namely, trackball). At the moment, I'm doing the following: viewer.getEventQueue()->setGraphicsContext(pbuffer); viewer.getEventQueue()->syncWindowRectangleWithGraphcisContext(); These operations are normally performed when initializing a GraphicsWindow, e.g. in GraphicsWindowWin32::init() and are thus missing when initializing a pbuffer, in e.g. PixelBufferWin32::init(). The syncWindowRectangleWithGraphcisContext (ever noticed the misspelling?) was the missing thing for me in [1]. Thus, the GUIEventAdapter created when processing an event in the EventQueue had its _Xmin, _Xmax, _Ymin, _Ymax, _windowWidth and _windowHeight had their default values. So, am I adding correctly an event queue to an offscreen viewer/view this way? Émeric [1] http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2015-February/269273.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sending fake mouse events to a TrackballManipulator? (again)
Hi, I need to simulate mouse inputs for a basic test application. Following Robert's advice [1], I'm injecting mouse events to the event queue of the viewer's application. My implementation is very similar to the one in GraphicsWindowWin32::handleNativeWindowingEvent. But a mouse drag (independently of the mouse button: left, middle, right; don't understand why) rotates the scene around the axis perpendicular to the display (Oz I presume). And there seems to be a huge threshold somewhere, as the scene is rotated several times while I'm dragging the mouse very slightly. To sum up, I'm getting no 3D rotation, nor panning or zooming, only flat 2D rotation around the Oz axis. Does this strange behavior suggest something obvious that I'm missing? If helpful, my code looks like this: void transformMouseXY(float& x, float& y) { assert(g_viewer.valid()); // g_viewer is a global osg::ref_ptr assert(g_viewer->getEventQueue()); if (g_viewer->getEventQueue()->getUseFixedMouseInputRange()) { osgGA::GUIEventAdapter* eventState = g_viewer->getEventQueue()->getCurrentEventState(); // SCREEN_WIDTH and SCREEN_HEIGHT are two constant unsigned integers x = eventState->getXmin() + (eventState->getXmax()-eventState->getXmin())*x/float(SCREEN_WIDTH); y = eventState->getYmin() + (eventState->getYmax()-eventState->getYmin())*y/float(SCREEN_HEIGHT); } } void inputProc(unsigned int MessageID, const void* Data) { assert(g_viewer.valid()); osgGA::EventQueue* queue = g_viewer->getEventQueue(); assert(queue); double eventTime = queue->getTime(); switch (MessageID) { caseMSG_LBUTTON_DOWN: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseButtonPress(mx, my, 1, eventTime); } break; caseMSG_MBUTTON_DOWN: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseButtonPress(mx, my, 2, eventTime); } break; caseMSG_RBUTTON_DOWN: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseButtonPress(mx, my, 3, eventTime); } break; caseMSG_LBUTTON_UP: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseButtonRelease(mx, my, 1, eventTime); } break; caseMSG_MBUTTON_UP: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseButtonRelease(mx, my, 2, eventTime); } break; caseMSG_RBUTTON_UP: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseButtonRelease(mx, my, 3, eventTime); } break; caseMSG_MOUSEMOVE: { float mx = ((unsigned int*)Data)[0]; float my = ((unsigned int*)Data)[1]; transformMouseXY(mx, my); queue->mouseMotion(mx, my, eventTime); } break; caseMSG_UNKNOWN: default: { // DO STUFF } } g_viewer->frame(); } Thanks, Émeric [1] http://forum.openscenegraph.org/viewtopic.php?t=1155 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compositeView in multithreaded Win32 MFC MDI application
Hi, > It is an app in OSG examples, named osgviewerMFC, that demonstrates almost > exactly what I need. > > The app doesn't use CompositeView class. And things are much simpler then. Yep, there's no really problem replacing the Viewer by a CompositeViewer in the osgviewerMFC example, except for the StatsHandler that's messing the focus of the osgViewer::Views attached to the CompositeViewer, as you'll probably discover. But where things are really becoming funny is when trying to play efficiently with the osgViewer::Views attached to the CompositeViewer, when in a MFC context (read "context" here as "general application context", not as "graphics context"). Ideally, I would like not to have one Viewer per CView as in the cOSG class of the osgviewerMFC example, but one CompositeViewer shared by all the CViews of the active CChildFrame/opened CDocument. As an attempt, I thus put the CompositeViewer, OSG root node/group and render thread in the CChildFrame class, but couldn't get this to run smoothly (have a look at http://forum.openscenegraph.org/viewtopic.php?p=62278, most notably my two last comments about inserting a CSplitterWnd). Performance-wise, I don't know if this makes sense, but I also tried putting a unique CompositeViewer (and render thread) in the CWinApp, holding the osgViewer::Views of the various CViews of the various opened CChildFrames/CDocuments. I obviously kept the OSG root nodes/groups in the CChildFrames (keeping them in the the CDocuments may have been more appropriate). Not better: random crashes IIRC, potentially thread-related. If you have other MFC/OSG architectures in mind to share, welcome, as it seems we're only a few in this boat ;-) Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
Andrew, > I think you will find that not many people really dug into using MFC with > OSG ( as you can tell by the deafening silence on the forum on these topics) Yes, indeed... > I am using a separate CMFC_OSG_MDIView for each CView. I am not sure why you > see that would be a problem. It does mean a separate Camera and separate > osgViewer::Viewer etc for each CView but as you can share > ,osg::Group/osg::Geometry objects as needed between scene graphs, I am not > sure why this would have any downside. OK, there's the difference. You're still using an osgViewer::Viewer instance per CMFC_OSG_MDIView, while on my side, I was trying to use one osgViewer::CompositeViewer to manage all the osgViewer::View inheriting the CMFC_OSG_MDIView window data. > The big difference between what I do and the OSG MFC examples is that > - I am single threaded I'm running a separate render thread. > I found that the osg threading mechanism seemed to be flawed, as I had 4 osg > threads using 100% of the CPU even when the app was idle. Perhaps I was > missing something. But it seems fundamental that , for example, the cull > thread is always running and never sleeping. Great for real-time games, not > so much for applications that need to be 'nice'. Could it be that you're using continuous rendering (default option) rather than on-demand rendering? You can change this with osgViewer::ViewerBase::setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND). The drawback is that you'll thus have to override the MFC stack to trigger osgViewer::View::requestRedraw() when required (e.g. OnSize). > - I then completely bypass the viewer OSG event handler and handle all > events using the standard MFC event mechanism. That is I handle OnPaint, > OnKeyDown,OnLButtonDown etc etc and do what is needed. For example, in my > OnDraw(CDC *cdc) I call viewer()->frame(); I had to do a couple of funky > things to get this to work properly . I can give you more details if you > want to go that way. I see. In this case, the above on-demand rendering trick won't work as ViewerBase::run() performs various tests in order to determine if osgViewer::ViewerBase::frame() should be called to redraw the display. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
Hi, 2015-01-09 23:58 GMT+01:00 Andrew Cunningham : > Hi, > I finally got around to resolving these MFC/Aero issues using the following . > Hope someone finds this helpful While I didn't hit the Aero issue you're talking about (I'm still on Windows XP), this post remains helpful as I'm getting performance issue with a similar MFC/OSG application. By contrast with the osgviewerMFC example where the cOSG class (that makes the glue between OSG and MFC) is a component of the view (CMFC_OSG_MDIView), I imagine that in your situation, this cannot be the case, as each view of your CSplitterWnd would otherwise have it's own OSG viewer/scene graph, right? I also imagine that you're using a CompositeViewer rather than a Viewer instance to manage the OSG part of your different CSplitterWnd views? Where did you put the instance of this CompositeViewer, as a member variable of the child frame? In my application, I'm relying upon a CompositeViewer, a member variable of the child frame. This child frame also has a CSplitterWnd member variable. Each view of the CompositeViewer inherits the window data from the CSplitterWnd view's HWND. With this architecture, the performances are far from stellar. Basically, the framerate is divided by the number of views. If it does matter, I'm using a separate render thread for each CompositeViewer. Since there's one CompositeViewer per child frame, there's in fact one distinct CompositeViewer by opened document. I don't know if it's the optimum architecture. For the records, I've also tried one unique CompositeViewer and render thread at the application level, shared by all the child frames/opened documents, but I was getting random crashes. But that's another story, back to the performance problem. Do you also notice performance issue with your application? I don't know where it comes from, maybe context switching as each view of the CompositeViewer inherit a different graphics context from the CSplitterWnd view? I've discarded the CSplitterWnd as the cause, as I'm getting the same kind of performance drop simply replacing the Viewer in the osgviewerMFC example with a CompositeViewer holding two views of the same scene graph. For completeness, I've also looked at the osgviewerQt example that makes use of a CompositeViewer, each view also having it's own graphics context. I'm not seeing any performance problem there on the same PC. Cheers, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MFC example flickering: OnEraseBkgnd not called
Hi, Did you noticed that CMFC_OSG_MDIView::OnEraseBkgnd in the osgviewerMFC example is never called, hence leading to flickering? This is with OSG 3.2.1. I don't know when this regression was introduced, as it seems that OnEraseBkgnd was correctly working with OSG 2.x [1]. I can however tell you that it relates to the inherited window data. Indeed, simply commenting the traits->inheritedWindowData = windata; line in cOSG::InitCameraConfig in MFC_OSG.cpp file makes CMFC_OSG_MDIView::OnEraseBkgnd being called again. But of course, the OSG rendering will be wrong. Émeric [1] http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-August/134798.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handling double precision data: node's meta-data or plugin data or what?
Hi Mike, 2014-11-04 8:22 GMT+01:00 Mike Connell : > 1 Read your data into a Vec3Darray - as doubles > 2 Decide upon a local origin - "best" may be the centroid of your data, but > the first point is somewhat quicker to find. > 3 Subtract the local origin from all the points in your array - they are now > still doubles, but each is a much smaller number which can be accurately > represented by a float > 4 Build a osg::Geometry with a Vec3Array for vertices, using your translated > points > 5 Put the Geometry under an osg::MatrixTransform, set the MT translation to > your local origin > return the MT OK, now I understand. > You *can* keep the original Vec3DArray if you want, but you probably don't > need to, you'd have to compare the values there against the values of (local > origin+p) to see if the difference is a problem for you, I doubt it will be. Indeed, I think that I can safely discard the double precision data once reduced in floats and decorated by the MatrixTransform. Furthermore this approach has the advantage of keeping only one vertex array "copy" in memory. Many thanks for the clarification, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handling double precision data: node's meta-data or plugin data or what?
Hi Robert, 2014-10-31 14:50 GMT+01:00 Robert Osfield : > If you really do need to handle double data then the best way is to load it > in doubles then post process the loaded subgraph to convert the double data > to floats in the way that is appropriate for that data - such as decorating > subgraphs with MatrixTransform and convert the osg::Geometry's Vec3dArray in > world coords to a Vec3Array in local coordinates. Well, this is where I'm lost ;-) Say I'm loading my data as double. My reader will thus store these data as Vec3dArray in the osg::Geometry::_vertexArray member variable of the geometry attached to the returned osg::Node. Now, I need to transform these double data as float for rendering. So, you create an osg::MatrixTransform node, attach it the osg::Node returned by the reader and create yet another osg::Node, also attached to the same osg::MatrixTransform node, but with an osg::Geometry::_vertexArray containing the data as float in a Vec3Array? Or is there only one osg::Node (the one returned by the loader, still attached to an osg::MatrixTransform node) with two vertex arrays: the osg::Geometry::_vertexArray member variable with the data as float for rendering, and yet another Vec3dArray with the data as double, stored as osg::Node's UserDataContainer (since an osg::Geometry can't hold two vertex arrays)? > If you want good rendering performance you'll need to convert to float > arrays at somepoint so after loaded is typically the best time. I'm OK with this, this is how the conversion procedure takes place that puzzles me. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handling double precision data: node's meta-data or plugin data or what?
Hi, I did some experiments today. While the FBX/DAE plugin is indeed able to read/write data in double precision, rendering them with OSG outputs the dreaded warning message about TriangleFunctor not supporting Vec3d* vertex arrays. In fact, the osgDB::Options::PrecisionHint is only used by the FBX/DAE plugin to either create a Vec3Array or a Vec3dArray to attach to the osg::Geometry::_vertexArray member variable, nothing more. And in the case osgDB::Options::PrecisionHint has DOUBLE_PRECISION_VERTEX bit, you'll hit the TriangleFunctor warning above, as my custom reader/writer... Émeric 2014-10-30 21:30 GMT+01:00 Émeric MASCHINO : > Robert, > > I think I get your point, but just to be sure. > > Dealing with double precision data involves: > - the native data (double precision), stored in an osg::Vec3dArray, > attached to an osg::Geometry object, > - the data reduced to floats, stored in the _vertexArray member > variable of the osg::Geometry object for rendering, > - attaching the osg::Geode to an osg::MatrixTransform (double > precision), so that both the double precision data in the > osg::Vec3dArray and the simple precision data in > osg::Geometry::_vertexArray are affected by the same transformation > matrix. > > Did I understand correctly? > > Émeric > > > > 2014-10-30 18:35 GMT+01:00 Émeric MASCHINO : >> Hi Robert, >> >>> For instance for GIS whole world databases the usual way to manage things is >>> to load the data in doubles then transform to a local origin and reduce any >>> vertex data from doubles to floats in the process and store this data in >>> straight osg::Vec3Array in an osg::Geometry. You then place the object in >>> the correct world space by decorating the subgraph with a Transform >>> (typically a MatrixTransform) that places the local origin in it's correct >>> world position and orientation. >> >> So data are duplicated? There's the original dataset in double >> precision and a transformed one in single precision? >> >>> If you look at osgEarth and >>> VirtualPlanetBuilder this is how they manage whole earth databases, >>> maintaining floats where OpenGL hardware requires it, but using double >>> MatrixTransforms and the use of double ModelView Matrices in the OSG cull >>> traversal that ensures maintenance of precision as long as possible before >>> one finally has to copy the data to OpenGL. >> >> Thanks for the pointer. >> >> Unfortunately, osgEarth is such a huge beast to reverse-engineer! And >> their Coordinates Systems git page [1] isn't that much informative >> about the implemented architecture in this regard. >> >> I was wondering, since both the FBX/DAE plugin is able to handle >> double precision data, isn't there a -maybe- similar mechanism in >> straight OSG that allows for rendering a FBX/DAE mesh? Or is the >> double to float reduction internally handled by the plugin? >> >> Émeric >> >> [1] >> https://github.com/gwaldron/osgearth/blob/master/docs/source/developer/coordinate_systems.rst ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handling double precision data: node's meta-data or plugin data or what?
Robert, I think I get your point, but just to be sure. Dealing with double precision data involves: - the native data (double precision), stored in an osg::Vec3dArray, attached to an osg::Geometry object, - the data reduced to floats, stored in the _vertexArray member variable of the osg::Geometry object for rendering, - attaching the osg::Geode to an osg::MatrixTransform (double precision), so that both the double precision data in the osg::Vec3dArray and the simple precision data in osg::Geometry::_vertexArray are affected by the same transformation matrix. Did I understand correctly? Émeric 2014-10-30 18:35 GMT+01:00 Émeric MASCHINO : > Hi Robert, > >> For instance for GIS whole world databases the usual way to manage things is >> to load the data in doubles then transform to a local origin and reduce any >> vertex data from doubles to floats in the process and store this data in >> straight osg::Vec3Array in an osg::Geometry. You then place the object in >> the correct world space by decorating the subgraph with a Transform >> (typically a MatrixTransform) that places the local origin in it's correct >> world position and orientation. > > So data are duplicated? There's the original dataset in double > precision and a transformed one in single precision? > >> If you look at osgEarth and >> VirtualPlanetBuilder this is how they manage whole earth databases, >> maintaining floats where OpenGL hardware requires it, but using double >> MatrixTransforms and the use of double ModelView Matrices in the OSG cull >> traversal that ensures maintenance of precision as long as possible before >> one finally has to copy the data to OpenGL. > > Thanks for the pointer. > > Unfortunately, osgEarth is such a huge beast to reverse-engineer! And > their Coordinates Systems git page [1] isn't that much informative > about the implemented architecture in this regard. > > I was wondering, since both the FBX/DAE plugin is able to handle > double precision data, isn't there a -maybe- similar mechanism in > straight OSG that allows for rendering a FBX/DAE mesh? Or is the > double to float reduction internally handled by the plugin? > > Émeric > > [1] > https://github.com/gwaldron/osgearth/blob/master/docs/source/developer/coordinate_systems.rst ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handling double precision data: node's meta-data or plugin data or what?
Hi Robert, > For instance for GIS whole world databases the usual way to manage things is > to load the data in doubles then transform to a local origin and reduce any > vertex data from doubles to floats in the process and store this data in > straight osg::Vec3Array in an osg::Geometry. You then place the object in > the correct world space by decorating the subgraph with a Transform > (typically a MatrixTransform) that places the local origin in it's correct > world position and orientation. So data are duplicated? There's the original dataset in double precision and a transformed one in single precision? > If you look at osgEarth and > VirtualPlanetBuilder this is how they manage whole earth databases, > maintaining floats where OpenGL hardware requires it, but using double > MatrixTransforms and the use of double ModelView Matrices in the OSG cull > traversal that ensures maintenance of precision as long as possible before > one finally has to copy the data to OpenGL. Thanks for the pointer. Unfortunately, osgEarth is such a huge beast to reverse-engineer! And their Coordinates Systems git page [1] isn't that much informative about the implemented architecture in this regard. I was wondering, since both the FBX/DAE plugin is able to handle double precision data, isn't there a -maybe- similar mechanism in straight OSG that allows for rendering a FBX/DAE mesh? Or is the double to float reduction internally handled by the plugin? Émeric [1] https://github.com/gwaldron/osgearth/blob/master/docs/source/developer/coordinate_systems.rst ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Handling double precision data: node's meta-data or plugin data or what?
Hi, I have to deal with double precision data files. By contrast to what's stated in [1], it seems to me that osg::Geometry can be passed double precision vertex data. At least in OSG 3.2.1 that may have fixed things since then. Allright. Great. But e.g. osgUtil::SmoothingVisitor fails to compute the normals of such vertex data, as osgUtil/SmoothingVisitor.cpp explicitely dynamic_casts vertex data as osg::Vec3Array*, probably because a TriangleFunctor (that doesn't seem to support anything else than osg::Vec3Array) is required. Now, reading in [2], [3] and the DAE/FBX readers source code, it appears that handling double precision data is a reality. At least for serialization. But what I'm missing is how to render them actually? I don't understand how the conversion from double to simple precision data is done for rendering. I don't seem to find any duplicated-with-different-precision-vertex-data in the DAE/FBX readers. BTW, [3] also mentions the newly (at the time) introduced osgDB::Options::PrecisionHint thing that is only used by the DAE/FBX to decide whether serialize the vertex data in osg::Vec3Array or osg::Vec3dArray. But nothing about rendering. I was thus wondering of maintaining my double precision vertex data as node's meta-data. So I read the brilliant discussion and PDF file [4] that seems to have led to the introduction of the UserDataContainer in core OSG. But here again, I'm coming short of determining if that's the right way to do so, as this API is only used to serialize presentation settings by the Present3D plugin. And while I'm thinking at "externalizing" my double precision data as meta-data (hence duplicating them with simple precision data for rendering), why not pass them as a separate object as plugin data? But here too, the examples using the {set|get}PluginData API are scarce: namely the DAE (once again) and FFmpeg plugins. In short: - how do you deal with double precision data? - how do you deal with any non-standard data (well, not related to geometry data)? How do you decide whether to use UserDataContainer to store them as meta-data in nodes or as plugin data? Thanks gurus, Émeric [1] http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-August/133876.html [2] http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-October/187722.html [3] http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2010-April/173920.html [4] http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-April/183451.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.2.1 OpenEXR plug-in incorrectly links against Release zlib.lib in Debug target
Hi, On Windows platform, the OSG 3.2.1 OpenEXR plug-in incorrectly links against both the Debug and Release version of zlib[d].lib in Debug target. Looking at src\osgPlugins\exr\CMakeLists.txt, shouldn't the directive at ln. 5 simply read: SET(TARGET_EXTERNAL_LIBRARIES ${OPENEXR_LIBRARIES}) rather than: SET(TARGET_EXTERNAL_LIBRARIES ${OPENEXR_LIBRARIES} ${ZLIB_LIBRARY} ) SETUP_PLUGIN seems to already add the correct zlib[d].lib dependence. Regards, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.2.1 DICOM plug-in incorrectly links against Release zlib.lib in Debug target
Hi, On Windows platform, the OSG 3.2.1 DICOM plug-in incorrectly links against both the Debug and Release version of zlib[d].lib in Debug target. Looking at src\osgPlugins\dicom\CMakeLists.txt, shouldn't the directive at ln. 8 simply read: LINK_LIBRARIES(${DCMTK_LIBRARIES}) rather than: LINK_LIBRARIES(${DCMTK_LIBRARIES} ${ZLIB_LIBRARY}) SETUP_PLUGIN seems to already add the correct zlib[d].lib dependence. Regards, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.2.1 osgviewerWX not showing up in Visual Studio solution and proposal to remedy the situation
Hi Robert, Indeed, you've made the changes in rev. 12838 but the logs aren't that explicit ;-) Anyway, I've checked that without the guard, both de Debug and Release versions of osgviewerWX[d]: - successfully build; - link only against Debug or Release libraries (including the wxWidgets ones); - run flawlessly. Maybe was it a transient problem with an old wxWidgets release? For records, I'm building against wxWidgets 3.0.1. Émeric 2014-09-25 13:40 GMT+02:00 Robert Osfield : > Hi Émeric, > > My guess is that check against build type had to be added to work around > problems under Windows with mixing release and debug libraries in the > context of WxWidgets. Have a check of the svn logs for the submission that > added this workaround, it might give some more insight to why it exists. > > Robert. > > On 25 September 2014 12:19, Émeric MASCHINO > wrote: >> >> Hi, >> >> Even though I've correctly set up my wxWidgets environment, the >> osgviewerWX example isn't added to my OSG 3.2.1 Visual Studio >> solution. >> >> Looking at the examples\CMakeLists.txt file, I've noticed that >> osgviewerWX inclusion is guarded against wxWidgets_FOUND (obviously) >> but also against CMAKE_BUILD_TYPE (with a further check that it equals >> to "Release"). Strangely enough, it appears that CMAKE_BUILD_TYPE >> isn't defined when I'm generating the Visual Studio solution/projects >> file with cmake-gui (at least for the Release|x64 target), so >> osgviewerWX is never included in my OSG 3.2.1 solution. >> >> Is this CMAKE_BUILD_TYPE guard really necessary? Indeed, osgviewerWX >> should be able to build both in Debug and Release targes, as permitted >> by the CMake's wxWidgets_USE_REL_AND_DBG variable. >> >> I thus propose to simply remove the guard in the >> examples\CMakeLists.txt file from: >> >> IF (wxWidgets_FOUND AND CMAKE_BUILD_TYPE) >> IF (${CMAKE_BUILD_TYPE} STREQUAL "Release") >> ADD_SUBDIRECTORY(osgviewerWX) >> ENDIF() >> ENDIF() >> >> to: >> >> IF (wxWidgets_FOUND) >> ADD_SUBDIRECTORY(osgviewerWX) >> ENDIF() >> >> BTW, this will be consistent with the other osgviewer examples (GLUT, >> SDL, FLTK, FOX). >> >> What's your opinion? >> >> Chhers, >> >> Émeric >> ___ >> 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] OSG 3.2.1 osgviewerWX not showing up in Visual Studio solution and proposal to remedy the situation
Hi, Even though I've correctly set up my wxWidgets environment, the osgviewerWX example isn't added to my OSG 3.2.1 Visual Studio solution. Looking at the examples\CMakeLists.txt file, I've noticed that osgviewerWX inclusion is guarded against wxWidgets_FOUND (obviously) but also against CMAKE_BUILD_TYPE (with a further check that it equals to "Release"). Strangely enough, it appears that CMAKE_BUILD_TYPE isn't defined when I'm generating the Visual Studio solution/projects file with cmake-gui (at least for the Release|x64 target), so osgviewerWX is never included in my OSG 3.2.1 solution. Is this CMAKE_BUILD_TYPE guard really necessary? Indeed, osgviewerWX should be able to build both in Debug and Release targes, as permitted by the CMake's wxWidgets_USE_REL_AND_DBG variable. I thus propose to simply remove the guard in the examples\CMakeLists.txt file from: IF (wxWidgets_FOUND AND CMAKE_BUILD_TYPE) IF (${CMAKE_BUILD_TYPE} STREQUAL "Release") ADD_SUBDIRECTORY(osgviewerWX) ENDIF() ENDIF() to: IF (wxWidgets_FOUND) ADD_SUBDIRECTORY(osgviewerWX) ENDIF() BTW, this will be consistent with the other osgviewer examples (GLUT, SDL, FLTK, FOX). What's your opinion? Chhers, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG deployment on Windows
OK, this is now clear with what Farshid also explained me in the other post. Thanks, Émeric 2014-09-24 22:29 GMT+02:00 Chris Hanson : > I just move the osgPlugins folder into the folder where the executable and > top-level OSG DLLs are found. All seems to work without any fuss. > > On Wed, Sep 24, 2014 at 1:04 PM, Émeric MASCHINO > wrote: >> >> Hi Chris, >> >> Are you then also putting the required plug-ins in the same folder and >> no more in a separate osgPlugins-X.Y.Z folder? >> >> Cheers, >> >> Émeric >> >> >> 2014-09-24 19:59 GMT+02:00 Chris Hanson : >> > I deploy my applications with their own local copy of OSG in the same >> > folder >> > as the main application executable. I typically have a dozen different >> > versions and flavors of OSG on my computer at once so OSG_ROOT becomes >> > irrelevant. >> > >> > On Wed, Sep 24, 2014 at 11:39 AM, Émeric MASCHINO >> > wrote: >> >> >> >> Hi Farshid, >> >> >> >> Correct, but what about the plug-ins and examples? They aren't >> >> installed in OSG_ROOT\bin. So if you only copy the DLLs in >> >> OSG_ROOT\bin, when trying to load a plug-in (installed in >> >> OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in >> >> OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, >> >> this last one will thus be searched in the PATH, with the risk of >> >> finding a similarly named DLL elsewhere in the filesystem before >> >> reaching the expected on in OSG_ROOT\bin. How do you manage this >> >> situation on your own? >> >> >> >> Cheers, >> >> >> >> Émeric >> >> >> >> >> >> 2014-09-24 19:12 GMT+02:00 Farshid Lashkari : >> >> > Hi Émeric, >> >> > >> >> > Placing the external libraries in OSG_ROOT\bin should work as long as >> >> > the >> >> > main executable is also in OSG_ROOT\bin. Windows should first search >> >> > for >> >> > DLLs in the same folder as the executable before searching in PATH. >> >> > So >> >> > there >> >> > is no need to add your application to PATH, or worry about >> >> > conflicting >> >> > DLLs >> >> > in PATH. I've deployed my application like this for years and never >> >> > had >> >> > any >> >> > issues. >> >> > >> >> > Cheers, >> >> > Farshid >> >> > >> >> > >> >> > On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> What's the best practice regarding OSG deployment on Windows? >> >> >> Indeed, >> >> >> several plug-ins depend on external libraries. Is it best to put the >> >> >> required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in >> >> >> OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that >> >> >> the plug-ins can find them? >> >> >> >> >> >> With this last approach, there's only one copy of each DLL shared by >> >> >> the OSG applications, plug-ins and examples. The drawback is that if >> >> >> a >> >> >> similarly named DLL is found in the PATH before reaching >> >> >> OSG_ROOT\bin, >> >> >> an incorrect DLL may be loaded. >> >> >> >> >> >> By contrast, copying the required DLLs in >> >> >> OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in >> >> >> OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. >> >> >> >> >> >> Any advice on what's better? >> >> >> >> >> >> Émeric >> >> >> ___ >> >> >> osg-users mailing list >> >> >> osg-users@lists.openscenegraph.org >> >> >> >> >> >> >> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > >> >> > >> >> > >> >> > ___ >> >> > osg-users mailing list >> >>
Re: [osg-users] OSG deployment on Windows
OK, thanks for the clarification Farshid. Yes, I was using exactly the same structure. But I didn't knew that the OSG plug-ins were first looking for their dependencies is OSG_ROOT\bin before relying upon the PATH. I thought that, when not found in the OSG_ROOT\bin\osgPlugins-X.Y.Z folder, the required DLLs were searched for in the PATH. Émeric 2014-09-24 20:03 GMT+02:00 Farshid Lashkari : > Hi Émeric, > > I'm assuming OSG_ROOT refers to the install folder of your OSG based > application. The plug-ins should go into OSG_ROOT\bin\osgPlugins-X.Y.Z. OSG > will automatically prepend the "osgPlugins-X.Y.Z\" path when attempting to > load "osgdb_*.dll" plugins. > > For example, let's say I install my application into the "C:\MyApp\" folder. > Here is how I organize the files: > > "C:\MyApp\bin\" contains: > - Executables (.exe) > - OSG library files (osg.dll, osgDB.dll, osgUtil.dll, ...) > - External dependencies (zlib1.dll, libxml2.dll, ...) > > "C:\MyApp\bin\osgPlugins-X.Y.Z\" contains: > - All OSG reader/writer plugins (osgdb_*.dll) > > Any executable launched from the "C:\MyApp\bin\" folder, will automatically > load dependencies from that folder before searching PATH. When attempting to > load a reader/writer plugin, OSG will automatically look in > "C:\MyApp\bin\osgPlugins-X.Y.Z\". If any of those plugins have external > dependencies, they will be loaded from "C:\MyApp\bin\", before searching in > PATH. > > This should allow multiple OSG based applications using different versions > to be installed on the system without conflicts. > > Hope this clears it up. > > Cheers, > Farshid > > On Wed, Sep 24, 2014 at 10:39 AM, Émeric MASCHINO > wrote: >> >> Hi Farshid, >> >> Correct, but what about the plug-ins and examples? They aren't >> installed in OSG_ROOT\bin. So if you only copy the DLLs in >> OSG_ROOT\bin, when trying to load a plug-in (installed in >> OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in >> OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, >> this last one will thus be searched in the PATH, with the risk of >> finding a similarly named DLL elsewhere in the filesystem before >> reaching the expected on in OSG_ROOT\bin. How do you manage this >> situation on your own? >> >> Cheers, >> >> Émeric >> >> >> 2014-09-24 19:12 GMT+02:00 Farshid Lashkari : >> > Hi Émeric, >> > >> > Placing the external libraries in OSG_ROOT\bin should work as long as >> > the >> > main executable is also in OSG_ROOT\bin. Windows should first search for >> > DLLs in the same folder as the executable before searching in PATH. So >> > there >> > is no need to add your application to PATH, or worry about conflicting >> > DLLs >> > in PATH. I've deployed my application like this for years and never had >> > any >> > issues. >> > >> > Cheers, >> > Farshid >> > >> > >> > On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO >> > wrote: >> >> >> >> Hi, >> >> >> >> What's the best practice regarding OSG deployment on Windows? Indeed, >> >> several plug-ins depend on external libraries. Is it best to put the >> >> required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in >> >> OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that >> >> the plug-ins can find them? >> >> >> >> With this last approach, there's only one copy of each DLL shared by >> >> the OSG applications, plug-ins and examples. The drawback is that if a >> >> similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, >> >> an incorrect DLL may be loaded. >> >> >> >> By contrast, copying the required DLLs in >> >> OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in >> >> OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. >> >> >> >> Any advice on what's better? >> >> >> >> Émeric >> >> ___ >> >> osg-users mailing list >> >> osg-users@lists.openscenegraph.org >> >> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> > >> > >> > ___ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG deployment on Windows
Hi Chris, Are you then also putting the required plug-ins in the same folder and no more in a separate osgPlugins-X.Y.Z folder? Cheers, Émeric 2014-09-24 19:59 GMT+02:00 Chris Hanson : > I deploy my applications with their own local copy of OSG in the same folder > as the main application executable. I typically have a dozen different > versions and flavors of OSG on my computer at once so OSG_ROOT becomes > irrelevant. > > On Wed, Sep 24, 2014 at 11:39 AM, Émeric MASCHINO > wrote: >> >> Hi Farshid, >> >> Correct, but what about the plug-ins and examples? They aren't >> installed in OSG_ROOT\bin. So if you only copy the DLLs in >> OSG_ROOT\bin, when trying to load a plug-in (installed in >> OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in >> OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, >> this last one will thus be searched in the PATH, with the risk of >> finding a similarly named DLL elsewhere in the filesystem before >> reaching the expected on in OSG_ROOT\bin. How do you manage this >> situation on your own? >> >> Cheers, >> >> Émeric >> >> >> 2014-09-24 19:12 GMT+02:00 Farshid Lashkari : >> > Hi Émeric, >> > >> > Placing the external libraries in OSG_ROOT\bin should work as long as >> > the >> > main executable is also in OSG_ROOT\bin. Windows should first search for >> > DLLs in the same folder as the executable before searching in PATH. So >> > there >> > is no need to add your application to PATH, or worry about conflicting >> > DLLs >> > in PATH. I've deployed my application like this for years and never had >> > any >> > issues. >> > >> > Cheers, >> > Farshid >> > >> > >> > On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO >> > wrote: >> >> >> >> Hi, >> >> >> >> What's the best practice regarding OSG deployment on Windows? Indeed, >> >> several plug-ins depend on external libraries. Is it best to put the >> >> required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in >> >> OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that >> >> the plug-ins can find them? >> >> >> >> With this last approach, there's only one copy of each DLL shared by >> >> the OSG applications, plug-ins and examples. The drawback is that if a >> >> similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, >> >> an incorrect DLL may be loaded. >> >> >> >> By contrast, copying the required DLLs in >> >> OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in >> >> OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. >> >> >> >> Any advice on what's better? >> >> >> >> Émeric >> >> ___ >> >> 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 > > > > > -- > Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com > http://www.alphapixel.com/ > Training • Consulting • Contracting > 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • > GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL > Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography > • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • > Android > @alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG deployment on Windows
Hi Farshid, Correct, but what about the plug-ins and examples? They aren't installed in OSG_ROOT\bin. So if you only copy the DLLs in OSG_ROOT\bin, when trying to load a plug-in (installed in OSG_ROOT\bin\osgPlugins-X.Y.Z) or running an example (installed in OSG_ROOT\shared\OpenSceneGraph\bin) that requires an external DLL, this last one will thus be searched in the PATH, with the risk of finding a similarly named DLL elsewhere in the filesystem before reaching the expected on in OSG_ROOT\bin. How do you manage this situation on your own? Cheers, Émeric 2014-09-24 19:12 GMT+02:00 Farshid Lashkari : > Hi Émeric, > > Placing the external libraries in OSG_ROOT\bin should work as long as the > main executable is also in OSG_ROOT\bin. Windows should first search for > DLLs in the same folder as the executable before searching in PATH. So there > is no need to add your application to PATH, or worry about conflicting DLLs > in PATH. I've deployed my application like this for years and never had any > issues. > > Cheers, > Farshid > > > On Wed, Sep 24, 2014 at 10:03 AM, Émeric MASCHINO > wrote: >> >> Hi, >> >> What's the best practice regarding OSG deployment on Windows? Indeed, >> several plug-ins depend on external libraries. Is it best to put the >> required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in >> OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that >> the plug-ins can find them? >> >> With this last approach, there's only one copy of each DLL shared by >> the OSG applications, plug-ins and examples. The drawback is that if a >> similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, >> an incorrect DLL may be loaded. >> >> By contrast, copying the required DLLs in >> OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in >> OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. >> >> Any advice on what's better? >> >> Émeric >> ___ >> 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] OSG deployment on Windows
Hi, What's the best practice regarding OSG deployment on Windows? Indeed, several plug-ins depend on external libraries. Is it best to put the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z or rather in OSG_ROOT\bin, thus ensuring that OSG_ROOT\bin is in the PATH so that the plug-ins can find them? With this last approach, there's only one copy of each DLL shared by the OSG applications, plug-ins and examples. The drawback is that if a similarly named DLL is found in the PATH before reaching OSG_ROOT\bin, an incorrect DLL may be loaded. By contrast, copying the required DLLs in OSG_ROOT\bin\osgPlugins-X.Y.Z may also require copying them in OSG_ROOT\bin as well as in OSG_ROOT\share\OpenSceneGraph\bin. Any advice on what's better? Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Override DICOM plug-in CMAKE_SHARED_LINKER_FLAGS
Hi, Building OSG 3.2.1 DICOM plug-in on a Windows XP x64 PC with Visual Studio 2010 fails at link with the following error: 67>osgDB.lib(osg100-osgDB.dll) : error LNK2005: "public: void __cdecl std::basic_ifstream >::`vbase destructor'(void)" (??_D?$basic_ifstream@DU?$char_traits@D@std@@@std@@QEAAXXZ) already defined in dcmimgle.lib(didispfn.obj) 67>osgDB.lib(osg100-osgDB.dll) : error LNK2005: "public: __cdecl std::basic_ifstream >::basic_ifstream >(char const *,int,int)" (??0?$basic_ifstream@DU?$char_traits@D@std@@@std@@QEAA@PEBDHH@Z) already defined in dcmimgle.lib(didispfn.obj) 67> Creating library C:/OpenSceneGraph/OpenSceneGraph-3.2.1/build/lib/osgPlugins-3.2.1/osgdb_dicom.lib and object C:/OpenSceneGraph/OpenSceneGraph-3.2.1/build/lib/osgPlugins-3.2.1/osgdb_dicom.exp 67>C:\OpenSceneGraph\OpenSceneGraph-3.2.1\build\bin\osgPlugins-3.2.1\osgdb_dicom.dll : fatal error LNK1169: one or more multiply defined symbols found This error was reported 3 years ago, without much interest [1]. Contrarily to what's regularly erroneously stated here and there, this error has _nothing_ to deal with CRT configuration mismatch (the dreaded /MT[d] vs. /MD[d] compiler settings). In such situation, you generally get a warning about trying to add /NODEFAULTLIB:MSVCRT flag. This _isn't_ the case here and I've double-checked that both my OSG and DCMTK builds are using the same settings. And indeed, it's identical: /MD[d]. This error has to deal with mixing both osgDB {i|o}fstream with STL ones, as correctly explained in [2] and [3]. There seems to be a consensus as considering this issue a Visual Studio 2010/2012 (what about 2013?) bug [4] and a well known work-around is to pass /FORCE:MULTIPLY to the linker. Simply doing so in the osgdb_dicom.vcxproj project file is obviously lost each time CMake is invoked. A cleaner solution would be to add this flag through the CMAKE_SHARED_LINKER_FLAGS of osgdb_dicom's CMakeLists.txt file, as in VirtualPlanetBuilder [5]. I've thus updated osgdb_dicom's CMakeLists.txt file to read as: IF (WIN32) SET(TARGET_EXTERNAL_LIBRARIES wsock32.lib) => I've added IF(MSVC) IF(${MSVC_VERSION} STREQUAL "1600") # Overcome Visual Studio 2010 error LNK2005: basic_ifstream symbols already defined in dcmingle.lib (didispfn.obj) SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} /FORCE:MULTIPLE") ENDIF() ENDIF() => End of work-around ENDIF() However, it seem's that the default CMAKE_SHARED_LINKER_FLAGS /machine:x64 is overriding customization, as osgdb_dicom linker settings only shows /machine:x64. I've checked that the updated CMakeLists.txt file was taken into account using an output message. Am I missing something obvious here and is there a way to prevent such an override? Or alternatively, is there a work-around for the Visual Studio 2010 work-around? Thanks, Émeric [1] http://forum.openscenegraph.org/viewtopic.php?t=8570 [2] http://forum.openscenegraph.org/viewtopic.php?t=8099 [3] http://stackoverflow.com/questions/23885275/lnk2005-already-defined-linker-behaves-strange [4] http://social.msdn.microsoft.com/Forums/vstudio/en-US/191de00a-53c9-4bd9-9cb6-e844eb224ca2/lnk2005-when-using-stdostringstream?forum=vclanguage [5] http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-September/253865.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.2.1 QuickTime plug-in doesn't compile on Windows
Hi Robert, > Apple likes moving the goal posts on all it's API which makes it difficult > to compile on all variants of their API's all the time. I've no problem with this. I only wanted to be sure that the breakage with the QuickTime plug-in on Windows is under control and expected. As for the OpenVRML plug-in. While the Visual Studio plug-ins webpage contains outdated information (hence my other post with a step-by-step OpenVRML plug-in HOWTO), a quick look at OSG SVN logs clearly states that the codebase was updated to work with OpenVRML 0.18.x and no more 0.14.x. I can't find the same explicit log for the QuickTime plug-in. Something saying "QuickTime SDK deprecated by ...". > Under Windows you can use the native directshow plugin or the ffmpeg plugin. Does it mean that both the QuickTime and Xine plug-ins are deprecated on Windows? It seems to me that the FFmpeg plug-in provides the missing bits. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.2.1 QuickTime plug-in doesn't compile on Windows
Hi, Just to be sure: is it expected that the OSG 3.2.1 QuickTime plug-in doesn't compile on Windows (lots of errors in MacTypes.h for example) with the latest QuickTime 7.3 SDK for Windows? Am I right to suppose that the codebase has been updated to build on OS X with today's QuickTime/QTKit, but since Apple killed the plug on Windows [1], the QuickTime plug-in doesn't compile anymore there? Is thus FFmpeg the way to go on Windows (and Linux) for .mov samples for example? Thanks, Émeric [1] https://karaoke.kjams.com/wiki/Blog/Apple_Abandons_QT_Win ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenVRML plug-in HOWTO
Hi Jordi, Well, how can I edit this page? The only available option that I can see in the ribbon are either print or send email. Maybe editing is restricted to OSG maintainers/contributors? Émeric 2014-09-23 12:05 GMT+02:00 Jordi Torres : > Hi Émeric, > > It would be nice if you could update this documentation at the website ( > http://www.openscenegraph.com/index.php/documentation/platform-specifics/windows/38-visual-studio-plugins > ). > > Thanks. > > 2014-09-23 11:59 GMT+02:00 Émeric MASCHINO : >> >> Hi, >> >> For those lost souls trying to build the OpenVRML plug-in on Windows, >> here's how I did it with OSG 3.2.1. Hope this helps, as I was >> desperately looking for such informations the passed days ;-) >> >> First, the informations at [1] are completely outdated. By contrast to >> what's stated there, OpenVRML 0.14.x is no more relevant at all, even >> on Windows. OpenVRML 0.18.x is the way to go. So, to build the >> OpenVRML plug-in, you need to build OpenVRML first. For this, the >> Boost C++ Libraries are required. And OpenVRML's default build >> configuration also has dependencies on libpng and FreeType. >> >> I've successfully built OpenVRML 0.18.9 against Boost 1.55.0, libpng >> 1.6.13 and FreeType 2.5.0 on a Windows XP x64 PC using the Visual >> Studio 2010 Professional IDE. I'm assuming here (i) that your OSG root >> _build_ folder is C:\OpenSceneGraph and (ii) that you've correctly set >> up and/or built Boost, libpng and FreeType. Here are the steps: >> - Download OpenVRML 0.18.9 source code openvrml-0.18.9.tar.gz from >> http://sourceforge.net/projects/openvrml/files/openvrml/0.18.9/; >> - Extract openvrml-0.18.9.tar.gz somewhere; say in C:\openvrml-0.18.9 >> folder; >> - Get the following missing project files from >> https://svn.code.sf.net/p/openvrml/code/tags/0.18.9/ and copy them to: >> - src/local/libopenvrml-dl/openvrml-dl.vcxproj: >> C:\openvrml-0.18.9/src/local/libopenvrml-dl/openvrml-dl.vcxproj; >> - src/node/x3d-interpolation/x3d-interpolation.vcxproj: >> C:\openvrml-0.18.9/src/node/x3d-interpolation/x3d-interpolation.vcxproj; >> - src/script/javascript.vcxproj: >> C:\openvrml-0.18.9/src/script/javascript.vcxproj; >> - Remove any entry Windows7.1SDK >> from the project files; >> - Remove any entry > >> Condition="'$(Configuration)|$(Platform)'=='{Debug|Release}|x64'">C:\Boost\include\boost-1_43;$(IncludePath) >> from the project files; >> - Fix the x64 platform settings of all projects files, copying from >> the Win32 section. Most were incorrectly created as Applications >> rather than DLLs! >> - Go to C:\openvrml-0.18.9 and open OpenVRML.sln solution; >> - Add $(BOOST_ROOT) to additional include directories of all projects; >> - Add $(BOOST_ROOT)\lib{32|64}-msvc-10.0 to additional library >> directories of all projects; >> - Add /bigobj compiler option to Debug|x64 configuration of openvrml >> DLL project to work around fatal error C1128; >> - Ensure that input libraries of openvrml DLL project is set to >> shlwapi.lib;XmlLite.lib;%(AdditionalDependencies) for all >> targets/platforms; >> - Ensure that input libraries of vrml97 DLL project is set to >> libpng16[d].lib;freetype250[_D].lib;%(AdditionalDependencies) for all >> targets/platforms and that additional library directories are properly >> set; >> - Build the vrml97 and x3d-* DLL projects. The openvrml DLL and >> openvrml-dl static library projects are automatically built as >> dependencies; >> - Copy the headers from C:\openvrml-0.18.9\src\libopenvrml hierarchy >> to C:\OpenSceneGraph\3rdParty\include\openvrml, replicating the >> hierarchy, as well as the resulting openvrml.lib library files to >> OpenSceneGraph\3rdParty\lib and openvrml.dll DLL files to >> OpenSceneGraph\3rdParty\bin; >> - Add OPENVRML_DIR environment variable, pointing to >> C:\OpenSceneGraph\3rdParty; >> - Update >> OpenSceneGraph\OpenSceneGraph-3.2.1\src\osgPlugins\vrml\CMakeLists.txt >> file to build against OpenVRML 0.18.x: >> - add references to Boost: add ln. 1-3: >> >> FIND_PACKAGE(Boost COMPONENTS thread) >> >> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS}) >> >> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS}) >> >> - remove references to antlr and regexp libraries: delete ln. 9-21 >> and ln. 23-24; >> - add OPENVRML_USE_DLL preprocessor definition: add ln. 31: >> >> ADD_DEFINITIONS(-DOPENVRML_USE_DLL) >> >> Final result should be: >> >> FIND
[osg-users] OpenVRML plug-in HOWTO
Hi, For those lost souls trying to build the OpenVRML plug-in on Windows, here's how I did it with OSG 3.2.1. Hope this helps, as I was desperately looking for such informations the passed days ;-) First, the informations at [1] are completely outdated. By contrast to what's stated there, OpenVRML 0.14.x is no more relevant at all, even on Windows. OpenVRML 0.18.x is the way to go. So, to build the OpenVRML plug-in, you need to build OpenVRML first. For this, the Boost C++ Libraries are required. And OpenVRML's default build configuration also has dependencies on libpng and FreeType. I've successfully built OpenVRML 0.18.9 against Boost 1.55.0, libpng 1.6.13 and FreeType 2.5.0 on a Windows XP x64 PC using the Visual Studio 2010 Professional IDE. I'm assuming here (i) that your OSG root _build_ folder is C:\OpenSceneGraph and (ii) that you've correctly set up and/or built Boost, libpng and FreeType. Here are the steps: - Download OpenVRML 0.18.9 source code openvrml-0.18.9.tar.gz from http://sourceforge.net/projects/openvrml/files/openvrml/0.18.9/; - Extract openvrml-0.18.9.tar.gz somewhere; say in C:\openvrml-0.18.9 folder; - Get the following missing project files from https://svn.code.sf.net/p/openvrml/code/tags/0.18.9/ and copy them to: - src/local/libopenvrml-dl/openvrml-dl.vcxproj: C:\openvrml-0.18.9/src/local/libopenvrml-dl/openvrml-dl.vcxproj; - src/node/x3d-interpolation/x3d-interpolation.vcxproj: C:\openvrml-0.18.9/src/node/x3d-interpolation/x3d-interpolation.vcxproj; - src/script/javascript.vcxproj: C:\openvrml-0.18.9/src/script/javascript.vcxproj; - Remove any entry Windows7.1SDK from the project files; - Remove any entry C:\Boost\include\boost-1_43;$(IncludePath) from the project files; - Fix the x64 platform settings of all projects files, copying from the Win32 section. Most were incorrectly created as Applications rather than DLLs! - Go to C:\openvrml-0.18.9 and open OpenVRML.sln solution; - Add $(BOOST_ROOT) to additional include directories of all projects; - Add $(BOOST_ROOT)\lib{32|64}-msvc-10.0 to additional library directories of all projects; - Add /bigobj compiler option to Debug|x64 configuration of openvrml DLL project to work around fatal error C1128; - Ensure that input libraries of openvrml DLL project is set to shlwapi.lib;XmlLite.lib;%(AdditionalDependencies) for all targets/platforms; - Ensure that input libraries of vrml97 DLL project is set to libpng16[d].lib;freetype250[_D].lib;%(AdditionalDependencies) for all targets/platforms and that additional library directories are properly set; - Build the vrml97 and x3d-* DLL projects. The openvrml DLL and openvrml-dl static library projects are automatically built as dependencies; - Copy the headers from C:\openvrml-0.18.9\src\libopenvrml hierarchy to C:\OpenSceneGraph\3rdParty\include\openvrml, replicating the hierarchy, as well as the resulting openvrml.lib library files to OpenSceneGraph\3rdParty\lib and openvrml.dll DLL files to OpenSceneGraph\3rdParty\bin; - Add OPENVRML_DIR environment variable, pointing to C:\OpenSceneGraph\3rdParty; - Update OpenSceneGraph\OpenSceneGraph-3.2.1\src\osgPlugins\vrml\CMakeLists.txt file to build against OpenVRML 0.18.x: - add references to Boost: add ln. 1-3: FIND_PACKAGE(Boost COMPONENTS thread) INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS}) LINK_DIRECTORIES(${Boost_LIBRARY_DIRS}) - remove references to antlr and regexp libraries: delete ln. 9-21 and ln. 23-24; - add OPENVRML_USE_DLL preprocessor definition: add ln. 31: ADD_DEFINITIONS(-DOPENVRML_USE_DLL) Final result should be: FIND_PACKAGE(Boost COMPONENTS thread) INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS}) LINK_DIRECTORIES(${Boost_LIBRARY_DIRS}) INCLUDE_DIRECTORIES(${OPENVRML_INCLUDE_DIR}) INCLUDE_DIRECTORIES(${OPENVRML_INCLUDE_DIR}/openvrml) IF (WIN32) INCLUDE_DIRECTORIES(${JPEG_INCLUDE_DIR}) INCLUDE_DIRECTORIES(${PNG_INCLUDE_DIR}) INCLUDE_DIRECTORIES(${ZLIB_INCLUDE_DIR}) SET(TARGET_LIBRARIES_VARS OPENVRML_LIBRARY JPEG_LIBRARY PNG_LIBRARY ZLIB_LIBRARY) SET(TARGET_EXTERNAL_LIBRARIES Ws2_32.lib) ADD_DEFINITIONS(-DOPENVRML_USE_DLL) ELSE() SET(TARGET_LIBRARIES_VARS OPENVRML_LIBRARY) ENDIF() SET(TARGET_SRC IndexedFaceSet.cpp Primitives.cpp ReaderWriterVRML2.cpp ConvertToVRML.cpp ) SET(TARGET_H ReaderWriterVRML2.h ConvertToVRML.h ) end var setup ### SETUP_PLUGIN(vrml vrml) Check you CMake configuration and build the OpenVRML plug-in: - OPENVRML_INCLUDE_DIR: C:/OpenSceneGraph/3rdParty/openvrml; - OPENVRML_LIBRARY: C:/OpenSceneGraph/3rdParty/lib/openvrml.lib; I didn't use OpenVRML Debug library in the end (see Notice below) so OPENVRML_LIBRARY_DEBUG was not set. Now, for runtime, OpenVRML requires some environment variables and data or the OpenVRML plug-in won't work at all: - Copy the resulting openvrml.dll DLL from C:\openvrml-0.18.9\{Win32|x64}\{Debug|Release}\bin to e.g. %OSG_ROOT%\bin; I'm assuming her
Re: [osg-users] osgViewerQT example question
Hi, Are you talking about the old osgviewerQT [1] or the newer osgviewerQt [2]? [1] http://trac.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osgviewerQT/osgviewerQT.cpp?rev=6819 [2] http://trac.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osgviewerQt I remember having problem with the old one, but not with osgviewerQt. BTW, are you running OSG on Linux or Windows? Émeric 2014-09-22 18:10 GMT+02:00 Nick Modly : > Hi, > > I'm looking at extending the osgViewerQT example by being able to add items > to the QGraphicsView (by setting a QGraphicsScene and adding items to that). > These items include some QT controls that need to be embedded in the window > with transparency enabled. > > When I simply create the scene and add the controls (using a > GraphicsProxyWidget), the view begins flickering black and white and the log > prints "QGLContext::makeCurrent(): Failed." over and over. It seems like QT > and OSG are fighting over the context. I've heard that you can get around > this by subclassing the QGraphicsScene and doing your OSG rendering in the > drawBackground() method, storing and retrieving the context before/after, but > I'm not exactly sure what that means - calling frame() there? > > Thank you! > > Cheers, > Nick > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=61113#61113 > > > > > > ___ > 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] osgscreencapture yields invalid pixel format error on Windows with --pbuffer argument
2014-08-21 18:52 GMT+02:00 Robert Osfield : > > It may also be nothing to do with the OSG itself, but an issue with the > drivers. I can't really help further I as don't have a Windows system or > Windows expertise. That's why I've tested on two different Windows versions (XP and 7), three different graphics cards (Quadro 3450/4000 SDI, Quadro 410 and HD Graphics 2500) from two different manufacturers (NVIDIA and Intel). IMHO, that's too much coincidences for a driver issue only. Thanks for your advice Robert, but what others are thinking about this? Windows crowd, aren't you hitting this issue too? Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgscreencapture yields invalid pixel format error on Windows with --pbuffer argument
Hi Robert, 2014-08-19 16:37 GMT+02:00 Robert Osfield : > Hi Émeric, > > It would be worth comparing the src/osgViewer/GraphicsWindowWin32.cpp in > 3.2.1 to 3.0.1 to see if there are any differences that might help. > > In general when debugging it's best to compile the OSG source code so you > step through the code and make revisions to see they help. Using the latest > OSG will also help with general bug fixes as well make it easier to pick up > any fixes that are required to address the problem you experience. Just tried with locally-compiled OSG 3.2.1 source code: exact same issue on Windows XP/7, with same hardware as previously :-( Do you think it's worth trying out the current OSG developer release source code? I've rather tried OSG 3.2.1 because it's the current stable release so had good hopes of getting something building successfully ;-) Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgscreencapture yields invalid pixel format error on Windows with --pbuffer argument
Hi Robert and the list, 2014-08-18 21:51 GMT+02:00 Robert Osfield : > You don't say what OS version, OSG version, hardware and drivers you are > using. Could you please provide this so that others might be able to get a > better idea of what type of system you are working with, and if they have > the same allow them to recreate the problem. Good catch, but I have the strong impression that this is a Windows (OSG 3.0.1 only?) problem. Here's why. I'm experiencing this issue on a Windows XP system sporting a NVIDIA Quadro 3450/4000 SDI display adapter (display drivers version 6.14.10.9185 a.k.a. ForceWare 91.85) with OSG 3.0.1 (I'm using the prebuilt VS2010 x64 binaries by AlphaPixel as a solid reference for people wanting to try). I'm _not_ having this issue on the exact same hardware with Fedora 20 (Linux), NVIDIA drivers version 303.123 and the Fedora-provided OSG 3.2.1 packages. Back on Windows, I'm _still_ having this issue with a totally different hardware: a Windows 7 system sporting a NVIDIA Quadro 410 display adapter (display drivers version 9.18.13.3523), still with AlphaPixel's OSG 3.0.1 x64 VS2010 binaries. The above Windows 7 system comes with a Core i3-3220 CPU that embeds a Intel HD Graphics 2500 display adapter. Removing the NVIDIA adapter to use the Intel one (drivers version 8.15.10.2639) yields the same issue. I don't have a system with an AMD display adapter, so can't test further. As you can see, all the tests on Windows are failing. It's noteworthy that I don't have OSG 3.2.1 readily available on Windows at the moment, so can't say if the problem lies in the Windows implementation or only in the OSG 3.0.1 Windows implementation. Are there people with Radeon display adapters wanting to try if they're hitting this issue with AlphaPixel's binaries? Are there people with OSG 3.2.1 built on Windows wanting to try if they're still hitting this issue? Thanks, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgscreencapture yields invalid pixel format error on Windows with --pbuffer argument
Hi, Does anybody successfully ran the osgscreencapture example on Windows when passing e.g. --pbuffer 1280 1024 cessna.osg as arguments? With such arguments, you render both in a P-Buffer and a viewer window. But I'm recording the following error in the console: Pixel buffer has been created successfully. Windows Error #2000: Win32WindowingSystem::OpenGLContext() - Unable to restore c urrent OpenGL rendering context. Reason: The pixel format is invalid. Select GL_BGRA read back format Window size 1280, 1024 Reading window usig glReadPixels, with a double buffer PixelBufferObject. Allocating image Generating pbo 0 Generating pbo 2 fps = 60.256, full frame copy = 2.9919ms rate = 438.09 Mpixel/sec, 1671.2 Mb/sec time for memcpy = 2.4892ms memcpy speed = 2008.6 Mb/sec fps = 59.804, full frame copy = 2.9196ms rate = 448.93 Mpixel/sec, 1712.5 Mb/sec time for memcpy = 2.4642ms memcpy speed = 2029 Mb/sec Press any key to continue... Please note that this issue only surfaces when rendering both in a P-Buffer and a viewer window. There's no problem when passing --pbuffer-only 1280 1024 cessna.osg (rendering in P-Buffer only, no viewer window) or simply cessna.osg (rendering in viewer window only). I've tracked down the problem to line 716: pbuffer = osg::GraphicsContext::createGraphicsContext(traits.get()); It's noteworthy that pbuffer is valid, as alluded to earlier in the console logs. It's a different issue than the one reported in http://forum.openscenegraph.org/viewtopic.php?t=7214. There, multithreading problems were triggering the same error, but with --pbuffer-only, whereas I've no problem with this configuration. I've nevertheless tried the proposed workarounds, without a success. I've also looked at the osgautocapture example, but there's no scenario leading to render both in a P-Buffer and a viewer window, so now invalid pixel format error there. However, I don't understand how the following test (line 233) can be true: if (viewer.getCamera()->getGraphicsContext() && viewer.getCamera()->getGraphicsContext()->getTraits()) { When rendering in a P-Buffer, viewer.getCamera()->getGraphicsContext()->getTraits() always returns NULL on my system. Any thought? Thanks, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to integrate osg into qt window?
Hi, Have a look at Wang Rui's excellent osgRecipes repository, more particularly osg_qt example: https://github.com/xarray/osgRecipes/blob/master/cookbook/chapter9/ch09_01/osg_qt.cpp There was an error where a new camera was incorrectly created rather than retrieved from the viewer. This has been fixed in the above provided URL. Hope this helps, Émeric 2014-05-20 18:11 GMT+02:00 sunpeng : > I've read examples/osgviewerQt, and written codes: > > int main(int argc, char *argv[]) > > { > > QApplication a(argc, argv); > > > > Window window1; > > > osgViewer::Viewer* viewer = new osgViewer::Viewer(); > osg::Group* root = new osg::Group(); > osg::Node* node = new osg::Node(); > node = osgDB::readNodeFile("cow.osg"); > root->addChild(node); > osgUtil::Optimizer optimizer ; > optimizer.optimize(root) ; > viewer->setSceneData(root); > viewer->setCamera(new osg::Camera()); > osg::Camera* camera = viewer->getCamera(); > osgQt::GraphicsWindowQt* gw = dynamic_cast( > camera->getGraphicsContext() ); > osgQt::GLWidget* widget1 = gw ? gw->getGLWidget() : NULL; > widget1->setGeometry( 100, 100, 800, 600 ); > QGridLayout* grid = new QGridLayout(); > grid->addWidget( widget1, 0, 0 ); > window1.setLayout(grid); > > viewer->realize(); > > window1.show(); > return a.exec(); > } > > but it seems > gw is null, i just want create osg widget( such as osgQt::GraphicsWindowQ ), > and integrate into QT, how to write codes? > > Thanks! > > peng > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG with opensource AMD/NVIDIA Linux driver
2014-04-25 18:40 GMT+02:00 Émeric MASCHINO : > > I was aware that the opensource drivers aren't on par with the closed > ones w.r.t. OpenGL specifications and driver optimizations, but I > didn't knew that what has been implemented there wasn't correct. From > the wiki page [1], Mesa should complies with OpenGL 3.3. Isn't there a > testsuite to ensure correct compliance? > > [1] http://en.wikipedia.org/wiki/Mesa_(computer_graphics) Well, reading Rich Geldreich's blog today (Things that drive me nuts about OpenGL) [1], it seems there's indeed no practical testing from the Khronos group to ensure driver's OpenGL conformance: "This indicates to me that Khronos needs to be more proactive at testing and validating the drivers. GL needs the equivalent of the WHQL process." (taken from #25) Interesting reading BTW, with #19 dealing with OpenGL compatibility and OpenGL "profiles" as recently introduced in OSG. Émeric [1] http://richg42.blogspot.co.uk/2014/05/things-that-drive-me-nuts-about-opengl.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Obsolete osg-users archive search index?
Hi Paul, > FYI, osg-users posts have been reflected to a Google Group for at least the > past six years, so you should just be able to search using Google. The group > is here: > http://groups.google.com/forum/#!forum/osg-users > > I hope people find this helpful. >-Paul That's great news, thanks for pointing this out. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Obsolete osg-users archive search index?
Hi Robert, I'm not a mailman sysadmin at all, but the note says that the index should be refreshed every 24 hours. Is this something hardcoded in mailman or can't find no reference to 24 in the mailman configuration file(s)? BTW, does Saturday, 17 Mar 2012 12:16:45 PDT more or less coincide with the server move? Émeric 2014-05-01 16:51 GMT+02:00 Robert Osfield : > Hi Emeric et. al, > > Curious, I have never noticed that the fact the search index isn't > updated regularly. I don't recall anyone else highlighting this > either so I guess we've all just overlooked it. I have just had a > search through the mailman admin pages and can't find any controls for > how often the search index is updated. I wonder if this went astray > when we moved the mailman server over to dreamhost. > > I have to admit I'm not a mailman expert. Thoughts from others? > > Robert. > > On 1 May 2014 14:48, Émeric MASCHINO wrote: >> Hi, >> >> The osg-users Archives state: >> >> Note:The archive search index was last rebuilt at Saturday, 17 Mar >> 2012 12:16:45 PDT. Any postings after that will not be found by a >> search. Index rebuild is usally done once every 24 hours for this >> list. You can use a "View by date" link below to access more recent >> postings. >> >> Is this note still accurate? >> >> If yes, I'm so sorry for having asked to the list questions that may >> have been answered since March 17th, 2012. >> >> If so, isn't there a way to update the search index? >> >> Thanks, >> >> Emeric >> ___ >> 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] Obsolete osg-users archive search index?
Hi, The osg-users Archives state: Note:The archive search index was last rebuilt at Saturday, 17 Mar 2012 12:16:45 PDT. Any postings after that will not be found by a search. Index rebuild is usally done once every 24 hours for this list. You can use a "View by date" link below to access more recent postings. Is this note still accurate? If yes, I'm so sorry for having asked to the list questions that may have been answered since March 17th, 2012. If so, isn't there a way to update the search index? Thanks, Emeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG with opensource AMD/NVIDIA Linux driver
2014-04-25 15:03 GMT+02:00 Jan Ciger : > > The open source drivers don't have yet the feature parity with the > proprietary ones. Many things simply don't work or are buggy - I am > actually surprised that you have got even that far. I was aware that the opensource drivers aren't on par with the closed ones w.r.t. OpenGL specifications and driver optimizations, but I didn't knew that what has been implemented there wasn't correct. From the wiki page [1], Mesa should complies with OpenGL 3.3. Isn't there a testsuite to ensure correct compliance? For the depth peeling example, only features of OpenGL fixed pipeline are used, so I'm really surprised it works that bad if Mesa is supposed to complies with OpenGL 3.3. Émeric [1] http://en.wikipedia.org/wiki/Mesa_(computer_graphics) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blending and hiding/showing a triangle face of the model
Hi Nick, Thanks for the pointers. > although they are right in the book about colors being vertex attributes I > think You can achieve the effect You are after by using osg::Material and > adjusting the alpha and then use a proper Blending Function. Have a look at > osghud example it has blended quad on top of the screen. If I'm not mistaken, osg::Material is part of a node's StateSet, that's only available starting at the Geode or Geometry level. So, altering the blending function there will impact all the triangle faces of my model, not only the selected one. > If You want to show/hide then probably the best is to use setNodeMask on > Your osg::Geode containing the osg::Geometry Here again, since setNodeMask is only available starting at the Geode level, this would require that I put all the individual triangle faces of the model in separate Geodes in order to individually show/hide them. Indeed, I don't know beforehand which triangle face will be selected by the end-user. Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Calling a ReaderWriter plugin from an other one
Hi, I've written a ReaderWriter plugin that read a custom file format. If you had a quick look at my previous post, you know that the models described in such files can be regionalized. Some of these models are regionalized thanks to topological informations provided by yet other complementary files (same names, just different extensions). At the moment, when I load such models that can be decorated (as I have the strong impression that the eponymous design pattern can be applied here) by regions, I rely upon osgDB::Registry to look for a ReaderWriter able to load the region informations files. So to summarize, I have a ReaderWriter A that directly ask support (through osgDB::Registry) of a ReaderWriter B in order to create a regionalized Geode object. Is it clean to make such a link between ReaderWriters or is there a better solution? Thanks, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry topology serialization
Hi, The OpenSceneGraph 3.0 Beginner's Guide states that "OSG doesn't support algorithmic topology functionalities at present, probably because it seems a little weird for a rendering API to implement this." I'm fine with this. Now, I've written a ReaderWriter plugin to read a custom file format that encompasses such topological informations, e.g. triangle/quad indices of the geometry defining regions on the model. Is osg::Object::set/getUserData adequate to serialize such topological informations in order to later display them (e.g. displaying regions of the model with different colors) or am I better developping my own interface? I've seen the osgUtil::EdgeCollector in OSG documentation, but it seems to do the reverse, i.e. extract topological informations of a geometry (edges, vertices, triangles) whereas I know them beforehand. And this won't tell what's the best practice to later store the results of osgUtil::EdgeCollector. Thanks, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Blending and hiding/showing a triangle face of the model
Hi, In the OpenSceneGraph 3 Cookbook is explained how to highlight the selected triangle face of a model. This is performed by creating a new triangle Geode that overlaps the selected triangle face. As outlined in the book: "Maybe you are still looking for a way to change the face's color to highlight it. Unfortunately it is impossible to modify the face color in OpenGL because color is in fact a vertex attribute. Shaders may help represent a specified face with a different color or transparency, but it seems to make a mountain out of a molehill in this recipe." Now, this is what I'm looking for, so I need to make this mountain in order to display the selected triangle face as a transparent surface. Are there any pointers on how to achieve this with a shader as anticipated in the book? Or is there yet another solution? Rather than blending the selected triangle face, suppose that I want to hide/show it, would I use the same technique than for blending it or not? Thanks, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org