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] 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 osgfo...@tevs.eu: 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] 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 clement@csiro.au: 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 a...@online.de: 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_ptrosgViewer::Viewer
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
Hi, 2015-01-09 23:58 GMT+01:00 Andrew Cunningham andr...@mac.com: Hi, I finally got around to resolving these MFC/Aero issues using the following . snip 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
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
[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 michael.conn...@gmail.com: 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 robert.osfi...@gmail.com: 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 emeric.masch...@gmail.com: 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 emeric.masch...@gmail.com: 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
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
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 emeric.masch...@gmail.com: 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] 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 robert.osfi...@gmail.com:
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 emeric.masch...@gmail.com
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 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
[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
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 xe...@alphapixel.com: 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 emeric.masch...@gmail.com 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 xe...@alphapixel.com: 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 emeric.masch...@gmail.com 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 fla...@gmail.com: 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 emeric.masch...@gmail.com 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 -- 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
[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 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] 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:
67osgDB.lib(osg100-osgDB.dll) : error LNK2005: public: void __cdecl
std::basic_ifstreamchar,struct std::char_traitschar ::`vbase
destructor'(void)
(??_D?$basic_ifstream@DU?$char_traits@D@std@@@std@@QEAAXXZ) already
defined in dcmimgle.lib(didispfn.obj)
67osgDB.lib(osg100-osgDB.dll) : error LNK2005: public: __cdecl
std::basic_ifstreamchar,struct std::char_traitschar
::basic_ifstreamchar,struct std::char_traitschar (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
67C:\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
[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
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 fla...@gmail.com: 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 emeric.masch...@gmail.com 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
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 xe...@alphapixel.com: 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 emeric.masch...@gmail.com 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 fla...@gmail.com: 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 emeric.masch...@gmail.com 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
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 fla...@gmail.com: 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 emeric.masch...@gmail.com 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 fla...@gmail.com: 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 emeric.masch...@gmail.com 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] 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 modly.n...@gmail.com: 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
[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 PlatformToolsetWindows7.1SDK/PlatformToolset
from the project files;
- Remove any entry IncludePath
Condition='$(Configuration)|$(Platform)'=='{Debug|Release}|x64'C:\Boost\include\boost-1_43;$(IncludePath)/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
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 jtorresfa...@gmail.com:
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 emeric.masch...@gmail.com:
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 PlatformToolsetWindows7.1SDK/PlatformToolset
from the project files;
- Remove any entry IncludePath
Condition='$(Configuration)|$(Platform)'=='{Debug|Release}|x64'C:\Boost\include\boost-1_43;$(IncludePath)/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
[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] osgscreencapture yields invalid pixel format error on Windows with --pbuffer argument
Hi Robert, 2014-08-19 16:37 GMT+02:00 Robert Osfield robert.osfi...@gmail.com: 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
2014-08-21 18:52 GMT+02:00 Robert Osfield robert.osfi...@gmail.com: 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 and the list, 2014-08-18 21:51 GMT+02:00 Robert Osfield robert.osfi...@gmail.com: 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 blueva...@gmail.com:
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_castosgQt::GraphicsWindowQt*(
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 emeric.masch...@gmail.com: 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
[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] 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 robert.osfi...@gmail.com: 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 emeric.masch...@gmail.com 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
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] OSG with opensource AMD/NVIDIA Linux driver
2014-04-25 15:03 GMT+02:00 Jan Ciger jan.ci...@gmail.com: 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] 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
[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] 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
