Re: [osg-users] [forum] My questions are stuck on [Topic is awaiting approval]?
Hi, As mentioned in this thread http://forum.openscenegraph.org/viewtopic.php?t=2525 you need to change your username to something human-readable. Unfortunately many people including yourself don't register with a email address they don't check on a regular base. Else they would get my emails reminding them to change their names before getting approved. ... Thank you! Cheers[ur, Sebastian[/url] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74412#74412 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Joshua, I fully agree with you. We are developing commercial software and started with plenty of years ago. About 10 years ago we started to use osg and embedded osg view into a qt widget based on the osg-qt project at that time. It worked smoothly since then. Now we are on the latest releases of osg and qt and we never had to touch our embedding class. The only thing I am missing is the compatibility of threading. But we can live with that and I'm not limited in threading inside qt. Qt is great for development of cross platform user interfaces and frees me of Microsoft related usage of system interfaces. During all those many years there were only 2 cases where something didn't work as expected. But we could debug and fix it due to open source. So we are happy with the combination of qt and osg. Both are reliable, stable and have excellent features in their field. Werner On 27. Juli 2018 19:19:17 MESZ, Joshua Tree wrote: >I have to chip in here. Qt is the most reliable, industry standard UI >for C++, period. In part this success is due to the moc >autogeneration, which could get you out of SFINAE madness. > >Now, there are huge firms that adopted Qt for decades and run multi >billion dollars systems on it. > >That said, the Qt source is online and you can modify it as you wish to >test a solution. It is puzzling to me how this is still a pending and >recurrent issue for over a decade and a half I follow OSG. > > > I have used Qt and OSG back in 2003, 15 years ago with success. > >> On Jul 27, 2018, at 12:03 PM, Robert Osfield > wrote: >> >> Hi Andrew, >> >>> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham >wrote: >>> I would agree QT is not perfect but on the flip-side >>> - It is the 'last man standing' of x-platform UI's. >> >> This is down to the weakness of the alternatives rather as much as >the >> strength of Qt. >> >>> - It's actively developed using the latest C++11/14 standards and >supported by both a commercial organization and a robust LGPL community >> >> Will they get rid of the non standard C++ extensions and >pre-compiling nonsense? >> >>> - Is has a new lease of life through PyQT5 and PySide being the >'de-facto' way to build Python based desktop UI's. >>> - QML is quite interesting >> >> There is simply too much pushed into Qt over the years. The lack of >> focus on the core functionality hurts it. >> >> I say this from experience, we've pushed too much functionality into >> the OpenSceneGraph distribution over the years, I can see the >> mistakes, but with backwards compatibility being an important factor >> for end users it's not easy to just make radical changes. >> >> What the computer industry is a nice neat, small C++11 UI library >with >> good hooks to building scripting integration on top of. >> >>> I don't know why QT and OSG seem to fight each other so much, but it >seems a PITA to get things working properly as the OP and I have both >found mysterious issues popping up that require trips into the debugger >and the QT and OSG source. I had to advocate for OSG as other >developers were keen to use QT3D instead. >> >> OSG integration with 3rd party windowing toolkits has generally been >> pretty straight forward - once the basics have been written it >doesn't >> take much to update and keep things working. >> >> Our experience with Qt is not like this at all. X11, Win32 they've >> been pretty rock solid for way over a decade now. OSX has required >> jumping through a hoops because Apple doesn't care about developers >as >> much as it cares about vendor lock-in. >> >> Over the years the OSG hasn't added extra burden on the 3rd party >> windowing toolkits, it's exactly the same as it has always been, just >> create a GL context and allow the OSG to call makeCurrent() and >> swapBuffers and we are pretty well done. It *should* be simple. It >> is requires is the 3rd party windowing toolkit not to screw around >> with things. It's Qt screwing around with things that is breaking >> things, they have lost sight of what the Windowing API should be >doing >> and trading on the toes of application develop codes/3rd party SDK's >> like the OSG. >> >> Qt *is* broken in this respect. It really should be down to the Qt >> support to help you work out how to fix this. >> >> -- >> >> It terms of thinking about migrating away from OpenSceneGraph to >Qt3D, >> this might solve the Qt integration issue, but it just further >cements >> the lock-in to Qt, you'll end up tied to their future success or >> failures. >> >> The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if >> you really want to migrate to another scene graph then it should be >> Vulkan based if you want it to be future proofed. Qt3D might be >> ported to Vulkan, but it'll still be tied to Qt and all the baggage >> that goes with it. >> >> Modern computing should be based around well designed and >> functionality focused components that can be mixed and matched as to >> the
[osg-users] [forum] My questions are stuck on [Topic is awaiting approval]?
Hi, I've posted a couple of questions, one more than ten days ago and they are awaiting approval. How long does this process exactly take??? Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74402#74402 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi, I have just investigated the issue with OSG view set in QT window and osgEarth REX engine which resulted in completely black screen. This was probably different problem, but it sounds bit like yours so I decided I will share my observations. Maybe it will help someone. What I found to be an issue in our case was a missing call when setting our main view camera : main_camera->setDrawBuffer( GL_BACK ) This call makes sure the glDrawBuffer is set to main window BACK buffer before drawing main view frames. In my case REX engine was setting up RTT camera (without Color attachment) which swtiched DrawBuffer to GL_NONE. And main window was not restoring it before drawing the frame. So the effect was a completely black screen. I suspect similar problem may happen not only with osgEearth REX but with any RTT camera (without color attachments like shadowmap cameras). When I added above line while setting main camera problem vanished. I hope this may help somebody. With classic OSG Viewer this call is made inside SceneView ctor when setting up the camera. I believe our app also set up SceneView with QT window at startup but somehow DrawBuffer setting was later reverted/discarded. You may check if this hints helps you. Cheers, Wojtek Lewandowski sob., 28 lip 2018 o 11:51 Robert Osfield napisał(a): > ?!?! gmail just sent the email mid sentence > > > That exactly the same can be said for the OSG. Doesn't mean > > Mean't to say: > > On Sat, 28 Jul 2018 at 10:20, Robert Osfield > wrote: > > > Now, there are huge firms that adopted Qt for decades and run multi > billion dollars systems on it. > > The exactly the same can be said about the OSG. It's widely used for > decades on serious extensive kit. > > However, this doesn't mean that OSG isn't flawless and can't be improved > upon. > > With modern C++ with have opportunities to do a number of things far > more cleanly that previously possible. This applies to the scene > graphs just as much UI's. > > The future of C++ application development will be better served by > successors to the OSG and Qt. > > Right now such successors are just embryonic ideas, or nuggets of > prototypes. For current application development which need cross > platform widgets may be best served by Qt, same as the graphics > application development may be bested served by the OSG. Current > applications will be around for many years to come so Qt and OSG will > need to be maintained. > > For my own part I'm committed to maintaining the OSG. For 3.6.x I > moved osgQt out of the core to allow members of the OSG community who > have the need for Qt support and the expertise to know how to maintain > it the ability to make decisions, implementation solutions and provide > proper maintenance for it - something I can't do personally as I don't > have the Qt expertise, nor the time. > > This thread is a bit worrying as despite me handing the keys over to > osgQt development to the community doesn't yet seem to be able to > resolve all the problems by themselves. Yes the source code to both > Qt, osgQt and the OSG are all available, but unless developers step up > things don't happen. This suggest perhaps we need a bit more > motivated manpower from the Qt/OSG community to help push osgQt > forward. So if you feel passionate about Qt then please step forward > and help out. > > -- > > As a little prod for the long term future. With UI's and 2D rendering > API adopting scene graph internally (by this I don't mean Qt3D) and > more UI/2D rendering being done down on the GPU there is a possible > convergence. Could one have a scene graph that is general purpose > enough to be used directly to do 2D UI's as well as 3D real-time > graphics? Could one implement the UI as an add on to the core scene > graph, just a you'd made a game engine or image generator that builds > ontop of a scene graph?? > > So... I'm writing a new scene graph, yes I'm focused on it being used > for 3D, but I'm aware that Vulkan does compute just as nicely as it > does 3D, and it also works just fine for 2D too. If you can have a > scene graph just work as a compute graph, as well as 3D rendering > graph then 2D rendering is also just another subset. Could an > enterprising engineer build a fully function UI ontop of it? Maybe. > > Even if it doesn't come to pass for my VSG work, this is how I feel we > should all be thinking about the future - we should be thinking out of > the box, thinking about where we could get it if we strive for it, > rather than settling for the status quo. Yes yes the OSG and Qt are > impressive in a number of ways, but they have but of all encompassing > monsters that are at there peak. Better solutions will follow on, if > they don't the computer industry is failing to progress as it should. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org >
Re: [osg-users] osgQt + OSG 3.6.2 Status
?!?! gmail just sent the email mid sentence > That exactly the same can be said for the OSG. Doesn't mean Mean't to say: On Sat, 28 Jul 2018 at 10:20, Robert Osfield wrote: > > Now, there are huge firms that adopted Qt for decades and run multi billion > > dollars systems on it. The exactly the same can be said about the OSG. It's widely used for decades on serious extensive kit. However, this doesn't mean that OSG isn't flawless and can't be improved upon. With modern C++ with have opportunities to do a number of things far more cleanly that previously possible. This applies to the scene graphs just as much UI's. The future of C++ application development will be better served by successors to the OSG and Qt. Right now such successors are just embryonic ideas, or nuggets of prototypes. For current application development which need cross platform widgets may be best served by Qt, same as the graphics application development may be bested served by the OSG. Current applications will be around for many years to come so Qt and OSG will need to be maintained. For my own part I'm committed to maintaining the OSG. For 3.6.x I moved osgQt out of the core to allow members of the OSG community who have the need for Qt support and the expertise to know how to maintain it the ability to make decisions, implementation solutions and provide proper maintenance for it - something I can't do personally as I don't have the Qt expertise, nor the time. This thread is a bit worrying as despite me handing the keys over to osgQt development to the community doesn't yet seem to be able to resolve all the problems by themselves. Yes the source code to both Qt, osgQt and the OSG are all available, but unless developers step up things don't happen. This suggest perhaps we need a bit more motivated manpower from the Qt/OSG community to help push osgQt forward. So if you feel passionate about Qt then please step forward and help out. -- As a little prod for the long term future. With UI's and 2D rendering API adopting scene graph internally (by this I don't mean Qt3D) and more UI/2D rendering being done down on the GPU there is a possible convergence. Could one have a scene graph that is general purpose enough to be used directly to do 2D UI's as well as 3D real-time graphics? Could one implement the UI as an add on to the core scene graph, just a you'd made a game engine or image generator that builds ontop of a scene graph?? So... I'm writing a new scene graph, yes I'm focused on it being used for 3D, but I'm aware that Vulkan does compute just as nicely as it does 3D, and it also works just fine for 2D too. If you can have a scene graph just work as a compute graph, as well as 3D rendering graph then 2D rendering is also just another subset. Could an enterprising engineer build a fully function UI ontop of it? Maybe. Even if it doesn't come to pass for my VSG work, this is how I feel we should all be thinking about the future - we should be thinking out of the box, thinking about where we could get it if we strive for it, rather than settling for the status quo. Yes yes the OSG and Qt are impressive in a number of ways, but they have but of all encompassing monsters that are at there peak. Better solutions will follow on, if they don't the computer industry is failing to progress as it should. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
On Fri, 27 Jul 2018 at 18:19, Joshua Tree wrote: > > I have to chip in here. Qt is the most reliable, industry standard UI for > C++, period. In part this success is due to the moc autogeneration, which > could get you out of SFINAE madness. > > Now, there are huge firms that adopted Qt for decades and run multi billion > dollars systems on it. That exactly the same can be said for the OSG. Doesn't mean > That said, the Qt source is online and you can modify it as you wish to test > a solution. It is puzzling to me how this is still a pending and recurrent > issue for over a decade and a half I follow OSG. > > > I have used Qt and OSG back in 2003, 15 years ago with success. > > > On Jul 27, 2018, at 12:03 PM, Robert Osfield > > wrote: > > > > Hi Andrew, > > > >> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham wrote: > >> I would agree QT is not perfect but on the flip-side > >> - It is the 'last man standing' of x-platform UI's. > > > > This is down to the weakness of the alternatives rather as much as the > > strength of Qt. > > > >> - It's actively developed using the latest C++11/14 standards and > >> supported by both a commercial organization and a robust LGPL community > > > > Will they get rid of the non standard C++ extensions and pre-compiling > > nonsense? > > > >> - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' > >> way to build Python based desktop UI's. > >> - QML is quite interesting > > > > There is simply too much pushed into Qt over the years. The lack of > > focus on the core functionality hurts it. > > > > I say this from experience, we've pushed too much functionality into > > the OpenSceneGraph distribution over the years, I can see the > > mistakes, but with backwards compatibility being an important factor > > for end users it's not easy to just make radical changes. > > > > What the computer industry is a nice neat, small C++11 UI library with > > good hooks to building scripting integration on top of. > > > >> I don't know why QT and OSG seem to fight each other so much, but it seems > >> a PITA to get things working properly as the OP and I have both found > >> mysterious issues popping up that require trips into the debugger and the > >> QT and OSG source. I had to advocate for OSG as other developers were keen > >> to use QT3D instead. > > > > OSG integration with 3rd party windowing toolkits has generally been > > pretty straight forward - once the basics have been written it doesn't > > take much to update and keep things working. > > > > Our experience with Qt is not like this at all. X11, Win32 they've > > been pretty rock solid for way over a decade now. OSX has required > > jumping through a hoops because Apple doesn't care about developers as > > much as it cares about vendor lock-in. > > > > Over the years the OSG hasn't added extra burden on the 3rd party > > windowing toolkits, it's exactly the same as it has always been, just > > create a GL context and allow the OSG to call makeCurrent() and > > swapBuffers and we are pretty well done. It *should* be simple. It > > is requires is the 3rd party windowing toolkit not to screw around > > with things. It's Qt screwing around with things that is breaking > > things, they have lost sight of what the Windowing API should be doing > > and trading on the toes of application develop codes/3rd party SDK's > > like the OSG. > > > > Qt *is* broken in this respect. It really should be down to the Qt > > support to help you work out how to fix this. > > > > -- > > > > It terms of thinking about migrating away from OpenSceneGraph to Qt3D, > > this might solve the Qt integration issue, but it just further cements > > the lock-in to Qt, you'll end up tied to their future success or > > failures. > > > > The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if > > you really want to migrate to another scene graph then it should be > > Vulkan based if you want it to be future proofed. Qt3D might be > > ported to Vulkan, but it'll still be tied to Qt and all the baggage > > that goes with it. > > > > Modern computing should be based around well designed and > > functionality focused components that can be mixed and matched as to > > the needs of the applications. One stop shop SDK's and vendors that > > try to give you solutions for a wide range of functionality will give > > you lowest common denominator solutions rather than best of breed. > > > > This philosophy isn't Qt specific, but is something that I feel > > developers should bare in mind when considering what tools to use and > > deeply they should tie themselves to them. > > > > Robert. > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org >
Re: [osg-users] missing color for simple model with GLCORE
Hi Andreas, When you use GLCORE you have to provide your own shaders to do rendering. Unless you really have to use GLCORE for portability reasons - such as OSX or to avoid crappy driver issues, I would recommend just sticking with the default build of the OSG where you can mix and match old fixed funciton pipeline and new shader code when you want, without having to go all in with shaders. Robert. On Fri, 27 Jul 2018 at 21:29, Andreas Roth wrote: > > Hi, > > i'm trying to get a model with colors and GLCORE (in OSG 3.6.2). > > If i build OSG with the standard build options using GL2 the model shows some > color (see osg_gl2.png). When i buildOSG with GLCORE the load does not show > any colors (see osg_glcore.png). > > The model does not contain any textures, only a geometry with a color array. > How can i enable the colors for GLCORE? > > > Thank you! > > Andreas[/img] > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=74403#74403 > > > > ___ > 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
