Hi Robert,
thanks for the update.
The issue with ShapeDrawable take us to the wrong way.
So at the end we find the cause of the problem is different.
I will describe it again:
1 - Take a geode (e.g. we loaded "cow.osg") and build a kdtree
2 - Make a clone with DEEP_COPY_ALL
3 - Applying
Hi all,
I've rebuilt osg as suggested by Robert and still getting no GL errors but
nothing shows up.
To sum it up, running a test app which only uses libA (which addresses only
GL3 functions and shaders version 150)
under windows:
- if I link my code to OSG built with GLCORE profile everything
I missed changing one of the getScreen() calls in main, so please use
the attached version.
#include
#include
int main(int argc, char** argv)
{
osg::ArgumentParser arguments(, argv);
osgViewer::Viewer viewer(arguments);
osg::GraphicsContext::WindowingSystemInterface* wsi =
Sorry again
After a lot of bullshit here's a correct answer
for your code you should replace
wsi->getNumScreens()
with
wsi->getNumScreens(osg::GraphicsContext::ScreenIdentifier(1))
to work on DISPLAY=:1.0
mp3butcher wrote:
> Sorry I misinterpreted the code and said bullshit
> there's really
On Wed, 5 Sep 2018 at 15:22, Julien Valentin wrote:
> for your code you should replace
> wsi->getNumScreens()
> with
> wsi->getNumScreens(osg::GraphicsContext::ScreenIdentifier(1))
> to work on DISPLAY=:1.0
Sounds like we are getting to the bottom of things now :-)
FYI,
Okay that's how it works
it would be good to integrate these changes in all examples using
osg::GraphicsContext::WindowingSystemInterface
robertosfield wrote:
> I missed changing one of the getScreen() calls in main, so please use
> the attached version.
>
>
WindowingSystemInterface is an interface implemented in system dependant
osgViewer::XXXWindowingSystemInterface
What may be done is to add a system agnotistic windowInterface in osgviewer
#ifdef SYS
typedef osgViewer::SYSWindowingSystemInterface osgViewer::WindowingInterface
#else if SYS2
Sorry I misinterpreted the code and said bullshit
there's really bug in X11WindowingSystemInterface reporting 0 screens
mp3butcher wrote:
> WindowingSystemInterface is an interface implemented in system dependant
> osgViewer::XXXWindowingSystemInterface
> What may be done is to add a system
Hi Riccardo,
On Wed, 5 Sep 2018 at 15:56, Riccardo Corsi wrote:
> I've rebuilt osg as suggested by Robert and still getting no GL errors but
> nothing shows up.
> To sum it up, running a test app which only uses libA (which addresses only
> GL3 functions and shaders version 150)
> under
Hi Robert,
Your answer almost fixed my issue. There is just one
problem wsi->getScreenSettings(), still queries the wrong session:
1 screen(s) detected
Invalid MIT-MAGIC-COOKIE-1 keyUnable to open display ":0.1".
Screen #0 : 0x0 0Hz 0 bit
The problem is screen_id(screen), since it is not 0.
I've been trying to get a color array to work with my lines primitiveset. But
it is always white, or orange or green, depending on where the camera is. It's
awkward and random.
I've been changing my program to only do the bare minimum, but it's still
buggy. I've been looking through the code
HI Julian,
On Wed, 5 Sep 2018 at 15:10, Julien Valentin wrote:
> WindowingSystemInterface is an interface implemented in system dependant
> osgViewer::XXXWindowingSystemInterface
> What may be done is to add a system agnotistic windowInterface in osgviewer
>
> #ifdef SYS
> typedef
Hi Omar,
On Wed, 5 Sep 2018 at 17:07, Omar Álvarez wrote:
> Thank you very much for your time. If nobody else feels like doing it, I can
> help with updating osg::GraphicsContext::WindowingSystemInterface.
This hasn't looked like an OSG bug too me, just a usage issue. What
specifically do you
Hi Brian,
This might be fixed by:
https://github.com/openscenegraph/OpenSceneGraph/commit/e8b56c5c9735e70
It's documented on the mailing list thread:
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2018-August/008829.html
- Dan
> -Original Message-
> From:
Sorry, I meant the samples that use it. You're right.
On Wed, Sep 5, 2018, 18:37 Robert Osfield wrote:
> Hi Omar,
>
> On Wed, 5 Sep 2018 at 17:07, Omar Álvarez wrote:
> > Thank you very much for your time. If nobody else feels like doing it, I
> can help with updating
HI Brian,
I am not aware of any issues with textured point sprites in 3.6.
If the rendering flickers between states as you move the eye point
then this is an indication that some state hasn't been consistently
set up in your scene graph so that subgraph that is flickering is
inheriting state
Hi,
We recently upgraded OSG from 3.5.6 to 3.6.2 and our textured PointSprites
stopped working.
In a debug build they work fine but in a release build they do not display or,
if they do, they display using a translucent version of the non-textured points
which flash on and off as we navigate
Hi Ale,
Thanks for the updating test program, this illustrates a separate bug
in the KdTree copy constructor. I have added missing copying of the
indices:
~/OpenSceneGraph/src/osg$ git diff
diff --git a/src/osg/KdTree.cpp b/src/osg/KdTree.cpp
index 709c12f99..3f7a4a34a 100644
---
Hello Andrea,10:39, 5 September 2018 г., Andrea Martini :Dear all,i would like to enable Qt5 form Cmake(GUI) 3.8.2 using OSG 3.5.3 on Windows10. I installed QT 5.8.0 in c:\QT\... and i set environment variable QTDIR to C:\Qt\Qt5.8.0\5.8\msvc2013_64My focus consits in get osgQtBrowser and
Dear all,
i would like to enable Qt5 form Cmake(GUI) 3.8.2 using OSG 3.5.3 on Windows10.
I installed QT 5.8.0 in c:\QT\... and i set environment variable QTDIR to
C:\Qt\Qt5.8.0\5.8\msvc2013_64
My focus consits in get osgQtBrowser and osgQtWidgets example projects in osg
solutions (visual
Hi Riccardo,
The OSG_GL*_AVAILABLE flags are the lower level switches, if you want
a core profile with none of the fixed funcion pipeline then the
OSG_GL1 + GL2_AVAILABLE will need to be OFF. There are other controls
as well.
The best way to get everything set correct is to run CMake with
Hello Konstatine,
thank you for your suggestion.
Now CMAKE fills all Qt entries automatically.
But, osgQtWidgets and osgQtBrowser aren't in .sln
Looking into mypath\OpenSceneGraph-3.5.3\examples\CMakeLists.txt i found:
...
IF ( (QT4_FOUND AND QT_QTWEBKIT_FOUND) OR Qt5WebKitWidgets_FOUND )
Hi Riccardo,
On Wed, 5 Sep 2018 at 10:23, Riccardo Corsi wrote:
> Now what I'd like to do (on Win only) is to use libA and libB together.
> To do so I expected it was enough to add the OSG_GL3_AVAILABLE flag to build
> OSG and to request a Compatibility GL context.
> What happens instead is
Hi Robert,
thanks for your reply but I probably didn't explain clearly my issue.
Say I have:
- libA (using only GL Core features, because I want to use this lib also on
Mac)
- libB (using also GL 2.x features, target Win only)
If I compile and use only libA against osg built with GLCORE
Hi Robert,
Thanks for the quick response.
I have created an example:
https://github.com/omaralvarez/osgtest
osgviewer runs fine, no errors in console. But if I use INFO, I can see:
Viewer::realize() - No valid contexts found, setting up view across all
screens.
It may be related, but I'm not
Hi Omar,
What happens when you run osgviewer? Do you get errors output to the console?
Do any of the OSG examples fail?
If we can't see the error in standard OSG examples then it may be
worth creating a small test program so that others can run it on their
own systems to see if we can
Hi Robert,
I thin k Riccardo wants to use both libs (libA glcore, linB non glcore)
in the same app on Windows.
In my understanding this is not possible at all.
- Werner -
Am 05.09.2018 um 11:36 schrieb Robert Osfield:
> Hi Riccardo,
>
> On Wed, 5 Sep 2018 at 10:23, Riccardo Corsi
> wrote:
>>
osg::GraphicsContext::WindowingSystemInterface* wsi =
osg::GraphicsContext::getWindowingSystemInterface();
if ( !wsi ) {
std::cout << "ERROR. Could not access the Windowing System
Interface" << std::endl;
throw -1;
}
std::cout << wsi->getNumScreens() << "
28 matches
Mail list logo
