Re: [osg-users] Draw Instanced

Yes, it's here: https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/Instancing.vert.glsl Glenn Waldron On Mon, Apr 18, 2016 at 3:49 PM, sam wrote: > Do you have an example of the shader that you used? > > On Mon, Apr 18, 2016 at 12:40 PM, Glenn Waldron

Re: [osg-users] ShaderComposer::releaseGLObjects warning

On 18 April 2016 at 20:30, Robert Osfield wrote: > Hi Jannik and Ulrich, > > You are right it's a bug, the missing const is an error, rather than the > missing virtual. I've fixed this and rewritten the implementation of > ShaderCompose::releaseGLObjects() const. > > I

Re: [osg-users] Draw Instanced

Do you have an example of the shader that you used? On Mon, Apr 18, 2016 at 12:40 PM, Glenn Waldron wrote: > That I do not know. But I do recall that my original DI implementation > tried to use UBOs, and I ditched them in favor of TBOs because of the size > limitations. > >

Re: [osg-users] Draw Instanced

That I do not know. But I do recall that my original DI implementation tried to use UBOs, and I ditched them in favor of TBOs because of the size limitations. Glenn Waldron On Fri, Apr 15, 2016 at 6:09 PM, sam wrote: > Would there be a big performance difference between

Re: [osg-users] ShaderComposer::releaseGLObjects warning

Hi Jannik and Ulrich, You are right it's a bug, the missing const is an error, rather than the missing virtual. I've fixed this and rewritten the implementation of ShaderCompose::releaseGLObjects() const. I need to do a build and test before checking it in. Thankfully ShaderComposer is a not

Re: [osg-users] ShaderComposer::releaseGLObjects warning

Hi guys, On 18/04/2016 20:22, Robert Osfield wrote: > On 18 April 2016 at 17:39, Andy Skinner > wrote: > > We are getting a warning for ShaderComposer::releaseGLObjects: 'void >

Re: [osg-users] ShaderComposer::releaseGLObjects warning

Hi Robert Actually there is a bug here. The ShaderComposer::releaseGLObjects does not override because it is declared without the const specifier. Object::releaseGLObjects is declared const. > osg::Object::releaseGLObjects is virtual, but > osg::ShaderComposer::releaseGLObjects is not. Is

Re: [osg-users] ShaderComposer::releaseGLObjects warning

On 18 April 2016 at 17:39, Andy Skinner wrote: > We are getting a warning for ShaderComposer::releaseGLObjects: 'void > osg::ShaderComposer::releaseGLObjects(osg::State *)' : member function does > not override any base class virtual member function >

Re: [osg-users] OSG 3.4.0/QT 5.5 Warning "QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined"

It quite possibly could be specific to my implementation. I took the code from the osg example , but had to massage it a bit. I might try QT 5.6 to see if it goes away as well. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66872#66872

[osg-users] ShaderComposer::releaseGLObjects warning

We are getting a warning for ShaderComposer::releaseGLObjects: 'void osg::ShaderComposer::releaseGLObjects(osg::State *)' : member function does not override any base class virtual member function osg::Object::releaseGLObjects is virtual, but osg::ShaderComposer::releaseGLObjects is not. Is

[osg-users] Accessing assets from the Android APK

Hi, Currently I'm accessing textures / models for my scene by copying all 3d assets from my Android APK to the external storage. This way, I can refer to the assets via their fully-qualified paths on the system. This works but wastes a lot of space and now we must ask the user for permission

Re: [osg-users] Disappearing text

robertosfield wrote: > Hi Ronny, > > > Where the problem lies will likely be how you are managing the viewer as well > as the graphics context.  My hunch is that you've created the problem with > your "custom" means of managing things. > > > If you can try running your application with a

Re: [osg-users] Disappearing text

Hi Ronny, Where the problem lies will likely be how you are managing the viewer as well as the graphics context. My hunch is that you've created the problem with your "custom" means of managing things. If you can try running your application with a straight osgViewer::Viewer with it creating a

Re: [osg-users] OSG 3.4.0/QT 5.5 Warning "QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined"

Hi Loopy, I moved to OSG 3.4.0 and Qt5.6.0 recently but I didn't get such a warning. It seems a particular case of your implementation. Did you try the osgviewerQt example? Regards, Gianni -- Read this topic online here:

Re: [osg-users] Disappearing text

> That should not be needed at all, and indicative that something somewhere in > your application or it's usage of the OSG is messing up the GL object > management. > > > The resizeGLObjbectBuffer() is only needed when graphics context are created > or destroyed. > > > > As to what is

Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

Am 18.04.2016 um 15:56 schrieb Stuart Mentzer: Thanks Sebastian. Good reminder about /arch:AVX2. I can post a separate binary package built with this for people with newer CPUs if it shows a good performance gain. Ok. Be aware not all modern CPUs support this though. I'll also experiment

Re: [osg-users] Disappearing text

Hi Ronny, On 18 April 2016 at 15:29, Ronny Hatteland wrote: > The issue was fixed using the following after every ->setText(): > > > Code: > > mViewer->getSceneData()->resizeGLObjectBuffers(osg::DisplaySettings::instance()->getMaxNumberOfGraphicsContexts()); > > >

Re: [osg-users] Disappearing text

The issue was fixed using the following after every ->setText(): Code: mViewer->getSceneData()->resizeGLObjectBuffers(osg::DisplaySettings::instance()->getMaxNumberOfGraphicsContexts()); which is called inside of setSceneData(). However, this obviously has a huge performance impact and I

Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

Thanks Sebastian. Good reminder about /arch:AVX2. I can post a separate binary package built with this for people with newer CPUs if it shows a good performance gain. I'll also experiment with /fp:fast and see what the performance gain is, but it sounds like it might not be a good idea for an

Re: [osg-users] set proper size to window manager at startup

Hi Gianni. On 18 April 2016 at 13:48, Gianni Ambrosio wrote: > I can understand you don't have time and you are not the author of > osgWidgets. Anyway the case can be reproduced with osgviewerQt example. > Putting one breakpoint on GLWidget::event(QEvent*) and another

Re: [osg-users] set proper size to window manager at startup

I can understand you don't have time and you are not the author of osgWidgets. Anyway the case can be reproduced with osgviewerQt example. Putting one breakpoint on GLWidget::event(QEvent*) and another breakpoint on ViewerWidget::paintevent() method (the one that calls frame()) you can easily

Re: [osg-users] set proper size to window manager at startup

Hi Gianni, It is appropriate for osgGA::EventQueue::setStartClick() to call clear() as otherwise the queue would end up with inconsistent time stamps, as existing events would have the wrong relative time. The only alternative to this would be to reset all the event in the queue so that their

Re: [osg-users] set proper size to window manager at startup

OK, thanks Robert for the informations. So, just tio summarize the case for Cedric. When a Qt Application starts, most of Qt events (like resize, show, activate, ...) are sent to GLWidget before the OSG code handles them. GLWidget handles those events and queue them into OSG Eventqueue to be

Re: [osg-users] set proper size to window manager at startup

Hi Gianni, As a general note, I'm not the author of osgWidget so not in great position to answer specific questions about this. Unfortuantely, the author Cedric Pinson is now busy with the javascript version of the OSG and Sketchfab so not pitching in my on the osgWidget side these days. On 18

Re: [osg-users] set proper size to window manager at startup

I verified the clear() call has been added to EventQueue::setStartTick() method in OSG 3.1.1. Who did that can explain me please why it was required? Is there a way to move a clear() call outside the method to prevent the regression from OSG 3.1.1 onwards? Cheers, Gianni --

Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

Am 18.04.2016 um 08:59 schrieb Stuart Mentzer: Hi, After some struggle I have managed to make a cookbook for building OSG with Visual C++ 2015. This is very exciting because I should finally be able to build our structural impact modeling application on Windows. There are a few items that

[osg-users] osgWidget update function

Hi, I have the same problem like in this thread: http://forum.openscenegraph.org/viewtopic.php?t=13169=previous. I try to implement mousePressed function for an osgWidget. The solution is easy, but i can't find any "update/frame" function inside osgWidget or parent classes, which i can

Re: [osg-users] Disappearing text

Hi Ronny, Without seeing the artificats first hand is not possible to know what is going on. The best I can suggest is that you look at the near/far planes of the scene, could it be that the near/far planes are clipping the text? Also look at the possibility of state leaking into the text for

[osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015

Hi, After some struggle I have managed to make a cookbook for building OSG with Visual C++ 2015. This is very exciting because I should finally be able to build our structural impact modeling application on Windows. There are a few items that would be great to get some feedback on: For best

Re: [osg-users] TerrainTile and heightfield splitting

Hi Leandro, You can try VPB (Virtual Planet Builder for this). It should take care of splitting and merging of datasets in the result-tiles if they are correctly geo-referenced. Cheers Sebastian Hi, I have a region of terrain represented with 5 datasets. One dataset for elevation (a