Re: [osg-users] osgViewer::Viewer fullscreen dual monitor issue

[Björn Blissing]

akaisora wrote:
> Hi,
> 
> I am still new around here, I've got the book "OpenSceneGraph 3.0 Beginner's 
> Guide" and learning step by step. But I have dual monitors and running any 
> osg::Viewer example I got fullscreen window on both monitors, and a splitted 
> view as demonstrated in the attached screenshot.
> 
> Bascially it swaps the two monitors, the left render should have been on the 
> right and vice versa. 
> 
> Any idea how to fix it? Except using only one monitor :)
> 
> 
> Thank you!
> 
> Cheers,
> Soulaymen


Hi Soulaymen,

This is because you have your monitors setup in the wrong order in your windows 
settings. Windows enumerates your monitors, which can be seen in the displays 
settings. Make sure that your leftmost monitor have id 1 and the one to the 
right have id 2. (Note that this have nothing to do with which monitor is set 
to be primary or secondary, it is quite possible to make monitor 2 the primary 
monitor.).

I suspect that if you open the display settings you will currently have 
something that looks like this (Note the numbers on the displays and their 
location):
http://i.stack.imgur.com/SQzT8.png

You will need to change this so the numbers are in order left to right.

Regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67031#67031





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] Can't build documentation

[Alberto Luaces]

Hi Goj,

I think you are almost there: you don't use BUILD_DOCUMENTATION as a
make target, but you have to set it in CMake instead.

You can either activate the BUILD_DOCUMENTATION variable inside CMake
(using ccmake or cmake-gui), or just in the command line with

cmake -DBUILD_DOCUMENTATION=ON

After that, the target doc_openscenegraph should be available.

-- 
Alberto

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] Can't build documentation

[Goj Ames]

Hi Alberto, 
Thanks for chiming in.  
I have no 'doc_' targets in my top level makefile, but I see the bits in 
CMakeLists.txt, so I tried:
cmake BUILD_DOCUMENTATION .

I get several messages about missing packages, (Freetype, JPEG, Jasper, ... ) 
which I will fix, but it gives no errors.  After this, I still have no doc_ 
targets in the Makefile.


-- Could NOT find PNG (missing:  PNG_LIBRARY PNG_PNG_INCLUDE_DIR) 
-- Could NOT find TIFF (missing:  TIFF_LIBRARY TIFF_INCLUDE_DIR) 
-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE) 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/gjames/OpenSceneGraph

make doc_openscenegraph
  make: *** No rule to make target 'doc_openscenegraph'.  Stop.
grep doc_ Makefile


I'm up to date with:
commit a83a59fffe65e28ce110f542122dbf4137b93255
Merge: f013961 89fe663
Date:   Thu Mar 31 19:22:03 2016 +0100

Thanks for getting me a bit farther along, and thanks again for any other tips.
-G

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67029#67029





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to properly update a Geometry

[Daniel Neos]

gwaldron wrote:
> If you're just updating an existing array, you don't need to call 
> setVertexArray (etc); but you need to mark it dirty by calling
> 
>   m_vertices->dirty();
> 
> 
> That applies also to your other buffer objects (color array, elements, etc.)
> 
> 
> 
> Glenn Waldron
> 
> 


Hi Glenn, 

thanks for your solution, I somehow came up with a solution which calls 
setVertexArray() anyway,
because I am not feeling confident when updating a geometry with dynamically 
changing 
size of vertices each frame.

In my numbercrunching class, I create a geometry which I pass to
the visiualization class.


Code:

osg::ref_ptr vertices(new osg::Vec3Array());
osg::ref_ptr colors(new osg::Vec4Array());

for (int i = 0; i < nPixel; i++)
{
  // Fill in vertices and colors...
  // 
  //
}

m_geometry->setVertexArray(vertices.get());
m_geometry->setColorArray(colors.get());
m_geometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
if (firstTimecall)
{
m_geometry->addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::POINTS, 0, vertices->size()));
this->attachGeometry(m_geometry);
}
else
{
this->updateGeometry(m_geometry, nPixel);
}




Then I update the geometry of my visualization class like this


Code:

void OSGWidget::updateGeometry(osg::ref_ptr geometry, const int 
nPixel)
{
m_geometry->setVertexArray(geometry->getVertexArray());
m_geometry->setColorArray(geometry->getColorArray());

osg::DrawArrays* drawArrays = 
static_cast(m_geometry->getPrimitiveSet(0));
drawArrays->setCount(nPixel);
drawArrays->dirty();

// ensures update of scene
this->update();
}




This seems to work, but eventually there is a more efficient and elegant 
solution to exchange/ update vertice and colors.
I hope my issue is clear and small piece of samplecode will be appreciated. 
Thanks!

Cheers,
Daniel Neos

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67028#67028





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer::Viewer fullscreen dual monitor issue

[akaisora]

Hello Rebert,
Thank you very much for your explanation, as I am knew to OSG, this really 
helps a lot :)
My monitors' order is exactly as you mentioned.
Since I am just getting started, I don't really need multi-monitor rendering, 
so after toying with the viewer class, I found out about 
 "Viewer::setUpViewOnSingleScreen" and I set it up to my primary display.
Oh, I tried to look into Windows API to figure out how to fix it (within OSG) 
but realized it's more advanced than I thought. 
...
Thanks again!

Cheers,
Soulaymen
--
Envoi sécurisé avec Tutanota. Obtenez votre adresse email chiffrée 
aujourd'hui!
https://tutanota.com

29. Avr 2016 08:46 de robert.osfi...@gmail.com:


> Hi Soulaymen,
>
> By default the osgViewer::Viewer calls View::setUpViewAcrossAllScreens() as 
> a fallback if no windows have been assigned to viewer when viewer.realize() 
> or viewer.run() is called.  The setUpViewAcrossAllScreen() detects how many 
> screens you have on your system and then opens up a window on each one, if 
> there are more than one then it assumes that screen 0 is to the left, 
> screen 1 is directly to it's right and so on for all your screens.  On you 
> system it looks like you have screen 1 to the left of screen 0.
>
> I think there may be a way to configure Windows to use a different ordering 
> of screens, so you could look at the display/driver settings for a 
> solution.
>
> The other route would be to explicitly tell the viewer what display 
> configuration you want to use.  There are various ways you can do this, 
> rather than go through all the possible combinations could you give us an 
> idea of what you'd like to see as your default setup?
>
> Robert.
>
> On 28 April 2016 at 19:32, Soulaymen Chouri <> akais...@tuta.io> > wrote:
>
>> Hi,
>>
>> I am still new around here, I've got the book "OpenSceneGraph 3.0 
>> Beginner's Guide" and learning step by step. But I have dual monitors and 
>> running any osg::Viewer example I got fullscreen window on both monitors, 
>> and a splitted view as demonstrated in the attached screenshot.
>>
>> Bascially it swaps the two monitors, the left render should have been on 
>> the right and vice versa.
>>
>> Any idea how to fix it? Except using only one monitor :)
>>
>> ...
>>
>> Thank you!
>>
>> Cheers,
>> Soulaymen
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=67010#67010
>>
>>
>>
>>
>> Attachments:
>> http://forum.openscenegraph.org//files/osg_209.png
>>
>>
>> ___
>> 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] osgVolume::MultipassTechnique use

[Alex Taylor]

Robert,

The issue was I was setting a tileLocator, but I wasn't setting a
layerLocator. That was problematic in the following block of code:

Locator* layerLocator =
_volumeTile->getLayer()->getLocator();
if (tileLocator==layerLocator)
{

tileData->tileToImageUniform->set(osg::Matrixf::identity());
}
else
{
osg::Matrixd tileToImage(tileLocator->getTransform() *
osg::Matrixd::inverse(layerLocator->getTransform()));

tileData->tileToImageUniform->set(osg::Matrixf(tileToImage));
}

layerLocator->getTransform() was returning a NULL.

Still don't have things rendering correctly, but at least things aren't
crashing, so that's progress.

Thanks,

- Alex


On Fri, Apr 29, 2016 at 2:58 AM Robert Osfield 
wrote:

> Hi Alex,
>
> I haven't heard of the invert throwing a seg fault before.  The stack
> trace doesn't have any info about line numbers so we can't say what
> specifically was amiss.
>
> The only code in MultipassTechnique.cpp that calls Matrixd::invert() is:
>
>
>Locator* tileLocator = _volumeTile->getLocator();
> osg::Matrixd tileToEye = tileLocator->getTransform() *
> (*(cv->getModelViewMatrix()));
> osg::Matrixd eyeToTile;
> eyeToTile.invert(tileToEye);
>
> Both matrices are created on the stack so will exist so there won't be any
> direct memory issue such as trying to work against a null pointer.
>
> The part that may provide somewhere to look are the
> tileLocator->getTransform() and cv->getModelViewMatrix() calls, if
> tileLocator is NULL then the Matrix the getTransform() method will get will
> be corrupted at best, similar with the cv->getModelViewMatrix().
>
> Both these *should* be valid at this point.  My suggestion would be to
> check the value of tileLocator, any chance that you haven't assgned a
> osgVolume::Locator to the VolumeTile?  The Locator is needed to place the
> unit cube of the 3d texture into model coordinates.
>
> Robert.
>
>
> On 28 April 2016 at 21:12, Alex Taylor  wrote:
>
>> Robert,
>>
>> Here is a better looking stack trace on Linux. (I believe this stack
>> trace has gdb debug symbols enabled, it was a bit tricky to create and
>> integrate a build with DEBUG symbols in my environment here, apologies if I
>> got it wrong).
>>
>> My guess is that the Matrixd object being inverted after the call to
>> MultipassTechnique::cull is a NULL pointer or something like that...is
>> there perhaps a property or something I'm failing to setup when using
>> MultipassTechnique that might cause that to happen?
>>
>> No, I don't know whether the example works. My use of MultipassTechnique
>> is failing on a Mac and a Linux box within the software stack where I am,
>> and the stack trace looks the same on Mac and Linux.  I can try to build
>> the example. In the build harness where I work, I'd have to do a bit of
>> work or else just build OSG from scratch to use the volume example.
>>
>> Any thoughts at all based on this seg fault trace? Any leads would be
>> much appreciated, feeling stuck.
>>
>> - Alex
>>
>> Stack Trace (from fault):
>> [  0] 0x7f565ccdf968 osg::Matrixd::invert(osg::Matrixd const&) at
>> /sandbox/ataylor/Bmlhg_task1.j377265/matlab/src/osgserver/../../../3p_mirror/glnxa64/openscenegraph/include/osg/Matrixd:235
>> (in
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libmwosgserver.so)
>> [  1] 0x7f565a335b04
>> osgVolume::MultipassTechnique::cull(osgUtil::CullVisitor*) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgVolume.so.130+281343
>> [  2] 0x7f565a3449bc
>> osgVolume::VolumeScene::traverse(osg::NodeVisitor&) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgVolume.so.130+342455
>> [  3] 0x7f565a9491bb osgUtil::CullVisitor::apply(osg::Group&) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgUtil.so.130+868790
>> [  4] 0x7f565a348330
>> osgVolume::VolumeScene::accept(osg::NodeVisitor&) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgVolume.so.130+357163
>> [  5] 0x7f565c4ed503 osg::Group::traverse(osg::NodeVisitor&) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1537278
>> [  6] 0x7f565a94aa86 osgUtil::CullVisitor::apply(osg::Transform&) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgUtil.so.130+875137
>> [  7] 0x7f565c525a48 osg::MatrixTransform::accept(osg::NodeVisitor&)
>> at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1768003
>> [  8] 0x7f565c4ed503 osg::Group::traverse(osg::NodeVisitor&) at
>> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1537278
>> [  9] 

Re: [osg-users] How to properly update a Geometry

[Glenn Waldron]

If you're just updating an existing array, you don't need to call
setVertexArray (etc); but you need to mark it dirty by calling

  m_vertices->dirty();

That applies also to your other buffer objects (color array, elements, etc.)


Glenn Waldron

On Thu, Apr 28, 2016 at 3:51 PM, Daniel Neos  wrote:

> Greetings everyone,
>
> I am trying to display a point cloud, consisting of vertices and color
> with OpenSceneGraph. A static point cloud to display is rather easy with
> this guide.
> But I am not capable of updating such a point cloud. My intention is to
> create a geometry and attach it to my viewer class once.
> This is the mentioned method which is called once in the beginning.
>
> The OSGWidget strongly depends on this OpenGLWidget based approach.
>
>
> Code:
>
> void OSGWidget::attachGeometry(osg::ref_ptr geom)
> {
> osg::Geode* geode = new osg::Geode;
>
> geom->setDataVariance(osg::Object::DYNAMIC);
> geom->setUseDisplayList(false);
> geom->setUseVertexBufferObjects(true);
> bool addDrawSuccess = geode->addDrawable(geom.get()); // Adding Drawable
> Shape to the geometry node
>
>
> if (!addDrawSuccess)
> {
> throw "Adding Drawable failed!";
> }
>
> osg::StateSet* stateSet = geode->getOrCreateStateSet();
> stateSet->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
>
>
> float aspectRatio = static_cast(this->width()) /
> static_cast(this->height());
>
> // Setting up the camera
> osg::Camera* camera = new osg::Camera;
> camera->setViewport(0, 0, this->width(), this->height());
> camera->setClearColor(osg::Vec4(0.f, 0.f, 0.f, 1.f)); // Kind of
> Backgroundcolor, clears the buffer and sets the default color (RGBA)
> camera->setProjectionMatrixAsPerspective(30.f, aspectRatio, 1.f, 1000.f);
> // Create perspective projection
> camera->setGraphicsContext(graphicsWindow_); // embed
>
> osgViewer::View* view = new osgViewer::View;
> view->setCamera(camera); // Set the defined camera
> view->setSceneData(geode); // Set the geometry
> view->addEventHandler(new osgViewer::StatsHandler);
>
>
> osgGA::TrackballManipulator* manipulator = new osgGA::TrackballManipulator;
> manipulator->setAllowThrow(false);
>
> view->setCameraManipulator(manipulator);
>
> ///
> // Set the viewer
> //
> viewer_->addView(view);
> viewer_->setThreadingModel(osgViewer::CompositeViewer::SingleThreaded);
> viewer_->realize();
>
> this->setFocusPolicy(Qt::StrongFocus);
> this->setMinimumSize(100, 100);
>
> this->setMouseTracking(true);
> }
>
>
>
>
>
> This method gets set once and shall set up the camera, interactor settings
> and the overall scene which only consists of one geode containing the
> geometry which shall be updated continiously.
> And after I have 'attached' the geometry, I am trying to update the
> geometry like this
>
>
> Code:
>
> void PointCloudViewOSG::processData(DepthDataSet depthData)
> {
> if (depthData.points()->empty())
> {
> return; // empty cloud, cannot do anything
> }
>
> const DepthDataSet::IndexPtr::element_type& index = *depthData.index();
> const size_t nPixel = depthData.points().get()->points.size();
>
> if (depthData.intensity().isValid() && !index.empty() )
> {
> for (int i = 0; i < nPixel; i++)
> {
> float x = depthData.points().get()->points[i].x;
> float y = depthData.points().get()->points[i].y;
> float z = depthData.points().get()->points[i].z;
> m_vertices->push_back(osg::Vec3(x
> , y
> , z));
>
> // 32 bit integer variable containing the rgb (8 bit per channel)
> value
> uint32_t rgb_val_;
> memcpy(_val_, &(depthData.points().get()->points[i].rgb),
> sizeof(uint32_t));
>
> uint32_t red, green, blue;
> blue = rgb_val_ & 0x00ff;
>
> rgb_val_ = rgb_val_ >> 8;
> green = rgb_val_ & 0x00ff;
>
> rgb_val_ = rgb_val_ >> 8;
> red = rgb_val_ & 0x00ff;
>
> m_colors->push_back(
> osg::Vec4f((float)red / 255.0f,
> (float)green / 255.0f,
> (float)blue / 255.0f,
> 1.0f)
> );
> }
>
> m_geometry->setVertexArray(m_vertices.get());
>
> m_geometry->setColorArray(m_colors.get());
>
> m_geometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
>
> m_geometry->addPrimitiveSet(new
> osg::DrawArrays(osg::PrimitiveSet::POINTS, 0, m_vertices->size()));
> }
> }
>
>
>
>
> (Apperantly the code tag can somehow not handle the whitespaces but i will
> let it be since it is more readable than if everything is aligned)
>
> So my guess is that the  addPrimitiveSet(...)  shall not be called
> everytime I update the geometry, since it will push_back
> the primitive set everytime the geometry gets updated?
>
> Do I have to reattach my geometry after every update? Or do I have to
> rewrite my update method?
> So it boils down to the question  What steps are necessary to update my

[osg-users] How to properly update a Geometry

[Daniel Neos]

Greetings everyone,

I am trying to display a point cloud, consisting of vertices and color with 
OpenSceneGraph. A static point cloud to display is rather easy with this guide. 
But I am not capable of updating such a point cloud. My intention is to create 
a geometry and attach it to my viewer class once.
This is the mentioned method which is called once in the beginning.

The OSGWidget strongly depends on this OpenGLWidget based approach. 


Code:

void OSGWidget::attachGeometry(osg::ref_ptr geom)
{
osg::Geode* geode = new osg::Geode;

geom->setDataVariance(osg::Object::DYNAMIC);
geom->setUseDisplayList(false);
geom->setUseVertexBufferObjects(true);
bool addDrawSuccess = geode->addDrawable(geom.get()); // Adding Drawable Shape 
to the geometry node


if (!addDrawSuccess)
{
throw "Adding Drawable failed!";
}

osg::StateSet* stateSet = geode->getOrCreateStateSet();
stateSet->setMode(GL_LIGHTING, osg::StateAttribute::OFF);


float aspectRatio = static_cast(this->width()) / 
static_cast(this->height());

// Setting up the camera
osg::Camera* camera = new osg::Camera;
camera->setViewport(0, 0, this->width(), this->height());
camera->setClearColor(osg::Vec4(0.f, 0.f, 0.f, 1.f)); // Kind of 
Backgroundcolor, clears the buffer and sets the default color (RGBA)
camera->setProjectionMatrixAsPerspective(30.f, aspectRatio, 1.f, 1000.f); // 
Create perspective projection
camera->setGraphicsContext(graphicsWindow_); // embed 

osgViewer::View* view = new osgViewer::View;
view->setCamera(camera); // Set the defined camera
view->setSceneData(geode); // Set the geometry
view->addEventHandler(new osgViewer::StatsHandler);


osgGA::TrackballManipulator* manipulator = new osgGA::TrackballManipulator;
manipulator->setAllowThrow(false);

view->setCameraManipulator(manipulator);

///
// Set the viewer
//
viewer_->addView(view);
viewer_->setThreadingModel(osgViewer::CompositeViewer::SingleThreaded);
viewer_->realize();

this->setFocusPolicy(Qt::StrongFocus);
this->setMinimumSize(100, 100);

this->setMouseTracking(true);
}





This method gets set once and shall set up the camera, interactor settings and 
the overall scene which only consists of one geode containing the geometry 
which shall be updated continiously.
And after I have 'attached' the geometry, I am trying to update the geometry 
like this


Code:

void PointCloudViewOSG::processData(DepthDataSet depthData)
{
if (depthData.points()->empty())
{
return; // empty cloud, cannot do anything
}

const DepthDataSet::IndexPtr::element_type& index = *depthData.index();
const size_t nPixel = depthData.points().get()->points.size();

if (depthData.intensity().isValid() && !index.empty() )
{
for (int i = 0; i < nPixel; i++)
{
float x = depthData.points().get()->points[i].x;
float y = depthData.points().get()->points[i].y;
float z = depthData.points().get()->points[i].z;
m_vertices->push_back(osg::Vec3(x
, y
, z));

// 32 bit integer variable containing the rgb (8 bit per channel) value
uint32_t rgb_val_;
memcpy(_val_, &(depthData.points().get()->points[i].rgb), 
sizeof(uint32_t));

uint32_t red, green, blue;
blue = rgb_val_ & 0x00ff;

rgb_val_ = rgb_val_ >> 8;
green = rgb_val_ & 0x00ff;

rgb_val_ = rgb_val_ >> 8;
red = rgb_val_ & 0x00ff;

m_colors->push_back(
osg::Vec4f((float)red / 255.0f,
(float)green / 255.0f,
(float)blue / 255.0f,
1.0f)
);
}

m_geometry->setVertexArray(m_vertices.get());

m_geometry->setColorArray(m_colors.get());

m_geometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);

m_geometry->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POINTS, 
0, m_vertices->size()));  
}
}




(Apperantly the code tag can somehow not handle the whitespaces but i will let 
it be since it is more readable than if everything is aligned)

So my guess is that the  addPrimitiveSet(...)  shall not be called everytime I 
update the geometry, since it will push_back 
the primitive set everytime the geometry gets updated?

Do I have to reattach my geometry after every update? Or do I have to rewrite 
my update method?
So it boils down to the question  What steps are necessary to update my 
underlying geometry with new vertices and colors

I have read the basic tutorials and looked for similar questions in this forum 
and the only thing that I could adapt is the use of VBO for performance gain

PointCloudlibrary (PCL) is unfortunately not an alternative since of some 
incompatibilities with my application.




Thank you!

Cheers,
Daniel

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67011#67011





___
osg-users mailing list

[osg-users] support for double precission in shaders for INTEL board

[Trajce Nikolov NICK]

Hi Community,

I am aware that this question is not that much related to OSG (maybe?) but
I count that on the list there are good GLSL engineers.

I am facing issues with enabling this extension ''GL_ARB_gpu_shader_fp64".
It is enabled in my shaders '#extension GL_ARB_gpu_shader_fp64 : enable',
but for some reason I get this following error:

'GL_ARB_gpu_shader_fp64' : extension is disable or not available

Using GLview I see the extension present and enabled - did some tests with
other applications and all works, just can not make it work with OSG

Any clue?

Thanks a bunch as always !!!

Cheers,
Nick

-- 
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgVolume::MultipassTechnique use

[Robert Osfield]

Hi Alex,

I haven't heard of the invert throwing a seg fault before.  The stack trace
doesn't have any info about line numbers so we can't say what specifically
was amiss.

The only code in MultipassTechnique.cpp that calls Matrixd::invert() is:

   Locator* tileLocator = _volumeTile->getLocator();
osg::Matrixd tileToEye = tileLocator->getTransform() *
(*(cv->getModelViewMatrix()));
osg::Matrixd eyeToTile;
eyeToTile.invert(tileToEye);

Both matrices are created on the stack so will exist so there won't be any
direct memory issue such as trying to work against a null pointer.

The part that may provide somewhere to look are the
tileLocator->getTransform() and cv->getModelViewMatrix() calls, if
tileLocator is NULL then the Matrix the getTransform() method will get will
be corrupted at best, similar with the cv->getModelViewMatrix().

Both these *should* be valid at this point.  My suggestion would be to
check the value of tileLocator, any chance that you haven't assgned a
osgVolume::Locator to the VolumeTile?  The Locator is needed to place the
unit cube of the 3d texture into model coordinates.

Robert.


On 28 April 2016 at 21:12, Alex Taylor  wrote:

> Robert,
>
> Here is a better looking stack trace on Linux. (I believe this stack trace
> has gdb debug symbols enabled, it was a bit tricky to create and integrate
> a build with DEBUG symbols in my environment here, apologies if I got it
> wrong).
>
> My guess is that the Matrixd object being inverted after the call to
> MultipassTechnique::cull is a NULL pointer or something like that...is
> there perhaps a property or something I'm failing to setup when using
> MultipassTechnique that might cause that to happen?
>
> No, I don't know whether the example works. My use of MultipassTechnique
> is failing on a Mac and a Linux box within the software stack where I am,
> and the stack trace looks the same on Mac and Linux.  I can try to build
> the example. In the build harness where I work, I'd have to do a bit of
> work or else just build OSG from scratch to use the volume example.
>
> Any thoughts at all based on this seg fault trace? Any leads would be much
> appreciated, feeling stuck.
>
> - Alex
>
> Stack Trace (from fault):
> [  0] 0x7f565ccdf968 osg::Matrixd::invert(osg::Matrixd const&) at
> /sandbox/ataylor/Bmlhg_task1.j377265/matlab/src/osgserver/../../../3p_mirror/glnxa64/openscenegraph/include/osg/Matrixd:235
> (in
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libmwosgserver.so)
> [  1] 0x7f565a335b04
> osgVolume::MultipassTechnique::cull(osgUtil::CullVisitor*) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgVolume.so.130+281343
> [  2] 0x7f565a3449bc
> osgVolume::VolumeScene::traverse(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgVolume.so.130+342455
> [  3] 0x7f565a9491bb osgUtil::CullVisitor::apply(osg::Group&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgUtil.so.130+868790
> [  4] 0x7f565a348330 osgVolume::VolumeScene::accept(osg::NodeVisitor&)
> at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgVolume.so.130+357163
> [  5] 0x7f565c4ed503 osg::Group::traverse(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1537278
> [  6] 0x7f565a94aa86 osgUtil::CullVisitor::apply(osg::Transform&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgUtil.so.130+875137
> [  7] 0x7f565c525a48 osg::MatrixTransform::accept(osg::NodeVisitor&)
> at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1768003
> [  8] 0x7f565c4ed503 osg::Group::traverse(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1537278
> [  9] 0x7f565a9491bb osgUtil::CullVisitor::apply(osg::Group&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgUtil.so.130+868790
> [ 10] 0x7f565c4eecb8 osg::Group::accept(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1543347
> [ 11] 0x7f565c4ed503 osg::Group::traverse(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1537278
> [ 12] 0x7f565a94a278 osgUtil::CullVisitor::apply(osg::Camera&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosgUtil.so.130+873075
> [ 13] 0x7f565c4968f8 osg::Camera::accept(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1181939
> [ 14] 0x7f565c4ed503 osg::Group::traverse(osg::NodeVisitor&) at
> /mathworks/devel/sbs/28/ataylor.Bmlhg_task1.j377265/matlab/bin/glnxa64/libosg.so.130+1537278
> [ 

Re: [osg-users] osgViewer::Viewer fullscreen dual monitor issue

[Robert Osfield]

Hi Soulaymen,

By default the osgViewer::Viewer calls View::setUpViewAcrossAllScreens() as
a fallback if no windows have been assigned to viewer when viewer.realize()
or viewer.run() is called.  The setUpViewAcrossAllScreen() detects how many
screens you have on your system and then opens up a window on each one, if
there are more than one then it assumes that screen 0 is to the left,
screen 1 is directly to it's right and so on for all your screens.  On you
system it looks like you have screen 1 to the left of screen 0.

I think there may be a way to configure Windows to use a different ordering
of screens, so you could look at the display/driver settings for a solution.

The other route would be to explicitly tell the viewer what display
configuration you want to use.  There are various ways you can do this,
rather than go through all the possible combinations could you give us an
idea of what you'd like to see as your default setup?

Robert.

On 28 April 2016 at 19:32, Soulaymen Chouri  wrote:

> Hi,
>
> I am still new around here, I've got the book "OpenSceneGraph 3.0
> Beginner's Guide" and learning step by step. But I have dual monitors and
> running any osg::Viewer example I got fullscreen window on both monitors,
> and a splitted view as demonstrated in the attached screenshot.
>
> Bascially it swaps the two monitors, the left render should have been on
> the right and vice versa.
>
> Any idea how to fix it? Except using only one monitor :)
>
> ...
>
> Thank you!
>
> Cheers,
> Soulaymen
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=67010#67010
>
>
>
>
> Attachments:
> http://forum.openscenegraph.org//files/osg_209.png
>
>
> ___
> 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