Re: [osg-users] Bug with applying global default attributes?

I have determined that the problem is exercised if the first node sets the blend for FBO 1: stateset->setAttribute(new osg::Enablei(GL_BLEND, 1)); osg::BlendEquationi* blendEq = new osg::BlendEquationi(1, osg::BlendEquation::RGBA_MAX); osg::BlendFunci* blendFunc

Re: [osg-users] Bug with applying global default attributes?

I can confirm the bug also exists on 3.6.5-rc3 branch. I don't know if it pre-existed that. I have too many dependencies to be able to share a model. Simplistic models do not seem to exhibit the same behavior. I'll keep trying to debug. When is applyGlobalDefaultAttribute supposed to be

Re: [osg-users] Bug with applying global default attributes?

Hi Rob, Have you tried the 3.6 branch? Is the issue a regression? Could you provide a test model and screenshot of the results your are getting vs expecting if possible. Cheers, Robert. On Wed, 29 Jan 2020 at 19:41, OpenSceneGraph Users < osg-users@lists.openscenegraph.org> wrote: > > I have

[osg-users] Bug with applying global default attributes?

I have been testing with trunk and have only come across one problem so far (this might not be a new issue). I have a simple viewer set up with two nodes.  The first is loaded from an osgb.  Internally it sets the glBlendFunci(0, GL_MAX) via osg::BlendFunci. The second node also sets

Re: [osg-users] Bug in Cull Visitor

On 13 May 2018 at 18:48, Robert Osfield wrote: > On 13 May 2018 at 17:01, Gedalia Pasternak wrote: >> Does that mean it’s used incorrectly in >> OcclusionQueryNode::getPassed()? That was what I was basing my understanding >> on. > > I'm not the

Re: [osg-users] Bug in Cull Visitor

Hi Gedalia, On 13 May 2018 at 17:01, Gedalia Pasternak wrote: > Does that mean it’s used incorrectly in > OcclusionQueryNode::getPassed()? That was what I was basing my understanding > on. I'm not the author of OcclisionQueyNode so I have to look it up, jikes, yep it

Re: [osg-users] Bug in Cull Visitor

Does that mean it’s used incorrectly in OcclusionQueryNode::getPassed()? That was what I was basing my understanding on. Gedalia On Sun, May 13, 2018 at 10:57 AM Robert Osfield wrote: > Hi Gedalia, > > On 13 May 2018 at 15:27, Gedalia Pasternak

Re: [osg-users] Bug in Cull Visitor

Hi Gedalia, On 13 May 2018 at 15:27, Gedalia Pasternak wrote: >But won’t just simply removing it mean that adding a render leaf will be > changing what the current frame is? TraversalNumber is local value to a visitor it isn't a the frame number, this is retrieved with

Re: [osg-users] Bug in Cull Visitor

Thanks Robert, But won’t just simply removing it mean that adding a render leaf will be changing what the current frame is? For occlusion nodes I’ve realized that it’s not currently possible to use them within instanced hierarchy without tracking which traversal generated a given query, the

Re: [osg-users] Bug in Cull Visitor

Hi Gedalia, Well spotted, this issue has been in the code for almost two decades without anyone noticing. I've removed the duplicate from CullVisitor and checked this into OSG master and the 3.6 branch. Robert. On 12 May 2018 at 21:34, Gedalia Pasternak wrote: > Both

[osg-users] Bug in Cull Visitor

Both CullVisitor and it's base class NodeVisitor have members named _traversalNumber. Yielding duplicate member variables with the same name, and inconsistent behavior depending on how you access the class. Cull visitor's should be renamed, maybe to _cullTraversalNumber or something that wouldn't

Re: [osg-users] Bug with new BaseUniform

trying to isolate min requirement to reproduce I ran in an other bug concerning removeTextureAttribute : attribute->getTypeMemberPair() is not found for texture bound to other tu than 0. as TexAttrs are grouped by tu in ss , I believe that TextureAttribute::getMember should be removed(default 0

Re: [osg-users] Bug with new BaseUniform

Hi Julien, On 30 March 2018 at 13:10, Julien Valentin wrote: > Since I merged with osg master the 03/22, I encountered a bug: > I don't understand it yet but it crashes in optimizer l614 comparing a > baseUniform(which should be a uniform) with a uniform. > > This

[osg-users] Bug with new BaseUniform

Hi, Since I merged with osg master the 03/22, I encountered a bug: I don't understand it yet but it crashes in optimizer l614 comparing a baseUniform(which should be a uniform) with a uniform. This silly baseuniform seams to be instanciated via osgb file reading Will give more lead but Robert

Re: [osg-users] Bug in osgDB::findFileInDirectory

​Thanks Robert​ *Riccardo Corsi* sw engineering & co-founder *Kairos3D srl* Via Agostino da Montefeltro 2, 10134 Torino Italy *T* +390113157111 *M* +393288522785 *Check out our ground-breaking 3D CAD-to-VR toolchain: www.kairos3d.it * On Wed, Mar 28, 2018 at 12:50 PM,

Re: [osg-users] Bug in osgDB::findFileInDirectory

Hi Ricardo, On 27 March 2018 at 19:42, Robert Osfield wrote: > ./test --dir ~/OpenSceneGraph/include/osg/ --file version > Result with findFileInDirectory(): 0 > Result with fileExists(): 0 > concatenated=/home/robert/OpenSceneGraph/include/osg/version > > Which

Re: [osg-users] Bug in osgDB::findFileInDirectory

Hi Ricardo, I have just tried with and wihtout the trailing slash and these are the results I get under Linux, ./test --dir ~/OpenSceneGraph/include/osg --file version Result with findFileInDirectory(): 1 /home/robert/OpenSceneGraph/include/osg/Version ./test --dir ~/OpenSceneGraph/include/osg/

Re: [osg-users] Bug in osgDB::findFileInDirectory

Hi Robert, thanks for the tests. You're right I was not concatenating the paths correctly, but the concatenation was ok in the default case, as the directory path contains a final slash. Now I've realised THAT is the case when the issue comes up: if you use a directory path which has the final

Re: [osg-users] Bug in osgDB::findFileInDirectory

I have just run the test case with a file with the wrong case to see what would happen, the results look 100% correct: $ ./test --dir ~/OpenSceneGraph/include/osg --file version Result with findFileInDirectory(): 1 /home/robert/OpenSceneGraph/include/osg/Version Result with fileExists(): 0

Re: [osg-users] Bug in osgDB::findFileInDirectory

Hi Riccardo, On 27 March 2018 at 17:14, Riccardo Corsi wrote: > I found a bug in osgDB::findFileInDirectory() which does not return the > expected result on MacOS (and I guess under Linux, but I cannot verify), > while it works as expected under Windows. > > I'm

[osg-users] Bug in osgDB::findFileInDirectory

Hi Robert and all, I found a bug in osgDB::findFileInDirectory() which does not return the expected result on MacOS (and I guess under Linux, but I cannot verify), while it works as expected under Windows. I'm attaching a modified osgversion.cpp which reproduces the issue. Tested with: osg

Re: [osg-users] Bug in 3.4.0 when exporting .osgx file?

Hi Werner, As I explained in my previous post, the method should find the wrappers if the plugin has been already loaded, so it shouldn't be trying to reload a plugin as there would be no beneft - the code will have already checked all the possible wrappers. You haven't provided any guidance on

Re: [osg-users] Bug in 3.4.0 when exporting .osgx file?

Hi Robert, the problem is here: if (osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED) return findWrapper(name); return NULL; The loadLibrary() returns PREVIOUSLY_LOADED and not LOADED. So NULL gets returned instead of a wrapper pointer and thus the node

Re: [osg-users] Bug in 3.4.0 when exporting .osgx file?

Hi Werner, I can't work out what might be wrong form the description. In general the ObjectWrapperManager::findWrapper() checks wrappers that have been registered with it first, then if it fails to find one then attempts to load plugins that may be able to provide that wrapper. If the code is

[osg-users] Bug in 3.4.0 when exporting .osgx file?

Hi Robert, I think I catched another problem in version 3.4.0. I try exporting my scene as .osgx file. But except the xml header nothing is written. I debuged it and found the following sequence of calls: osg::ref_ptrrw=osgDB::Registry::instance()->getReaderWriterForExtension(

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Remo, On 14 March 2017 at 18:16, Remo Eichenberger wrote: > The env variable doesn't help. I see such errors: > > With subloading enabled i see this: > > before Glyph::subload(): detected OpenGL error: invalid enumerant > Glyph::subload(): texture sub-image width and/or

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

The env variable doesn't help. I see such errors: With subloading enabled i see this: before Glyph::subload(): detected OpenGL error: invalid enumerant Glyph::subload(): texture sub-image width and/or height of 0, ignoring operation. I've posted the log on the github issue. Remo

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

On 14 March 2017 at 17:38, Remo Eichenberger wrote: > Without this setting I see only a blue screen/window without any text. Do you get any GL errors reported on the console? Could you try disabling the incremental subloading of the glyph texture by setting the env var

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Without this setting I see only a blue screen/window without any text. Remo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70491#70491 ___ osg-users mailing list osg-users@lists.openscenegraph.org

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

On 14 March 2017 at 17:01, Remo Eichenberger wrote: > Update: Stock sample "examples_osgtext" partial works with: > > font->setMinFilterHint(osg::Texture::LINEAR); > > on MacOSX GL3 Core Profile This will be disabling mipmapping. Surely OSX GL3 core profile supports

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Update: Stock sample "examples_osgtext" partial works with: font->setMinFilterHint(osg::Texture::LINEAR); on MacOSX GL3 Core Profile -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70487#70487 ___

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Robert I've tested the latest branch on MacOSX 10.11.6: https://github.com/openscenegraph/OpenSceneGraph/commit/f1f6d23eebda16a9d4560a0a130580d65edf7401 Non of the stock samples works because of not applied shader. MacOSX needs a default shader. But simple text works when i add a shader on

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Remo, As a first step to resolving the osgText issues with VAO I have created a text_refactor branch off OSG master. All I have done so far is add the ability of osgText::TextBase to have NodeList _children that it traverses automatically, this _children list is intended for the Text and

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

HI Remo, On 27 January 2017 at 14:29, Remo Eichenberger wrote: > OSG_VERTEX_BUFFER_HINT=VAO > OSG_GEOMETRY_IMPLEMENTATION=VAO Oh well, that exhausts one possibility of a fix. I don't really know if it's worth trying to fix osgText::Text, when I made the changes to support VAO

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

yes, OSG_VERTEX_BUFFER_HINT=VAO OSG_GEOMETRY_IMPLEMENTATION=VAO -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70065#70065 ___ osg-users mailing list osg-users@lists.openscenegraph.org

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

On 27 January 2017 at 14:15, Remo Eichenberger wrote: > I use OSG master 255a86cbe22ba436ab162bd2a2e7cc0341140050 Have you enabled the new VAO support? The env var OSG_VERTEX_BUFFER_HINT should be used and set to VAO. Robert. ___

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Robert I use OSG master 255a86cbe22ba436ab162bd2a2e7cc0341140050 Cheers, Remo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70063#70063 ___ osg-users mailing list

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Remo, On 27 January 2017 at 13:59, Remo Eichenberger wrote: > I've tried a lot of things to get osgText working on MacOSX with VAO. GL3 on > OSX Core Profile requires VAOs. I don't have an OSX system so can't comment on the specifics of VAO support on MacOSX, I have rely

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi (Robert :) I've tried a lot of things to get osgText working on MacOSX with VAO. GL3 on OSX Core Profile requires VAOs. osgText doesn't setup the VAO path correctly on MacOSX. I can show glyphs when I use a osg::Geometry as a Wrapper to draw geometries from text glyphs like so: Code:

Re: [osg-users] Bug while updating geometry in Linux

Thanks, Robert! Adding vertices->dirty(); worked perfect. I even removed geometry->dirtyBound(); - I suppose I don't need it? Because my example works without that call. It is strange why it is only noticable on Linux. Nikita robertosfield wrote: > HI Nikita, > > I don't have time to try

Re: [osg-users] Bug while updating geometry in Linux

HI Nikita, I don't have time to try and the example problem right now, my best guide having had a quick read through is that perhaps you need to a a vertices->dirty() after you've done the vertices->push_back(). For a straight GL vertex array this won't be required, but if you are using VBO's

[osg-users] Bug while updating geometry in Linux

Hi, I am trying to port my app from Windows to Linux. I have a ribbon, which is updated dynamically. I add 2 points to vertices and I use GL_TRIANGLE_STRIP to create a ribbon. On Windows everything works fine. But on Linux all new vertices go to coordinates (0,0,0) after calling

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Remo Hi Sebastian I'm wondering if you have a running osgText on MacOSX Core Profile. Your shader-code is not compatible with it. I've written a partial working version of this shader. I also found that the Glyph Texture is created with red. But i think something is wrong with the

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Sebastian, Sorry, please ignore my post. The code is wrong. I need to test it first :) Cheers, Remo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70027#70027 ___ osg-users mailing list

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Sebastian Thank you for your help. Yes i don't see the glyphs. I use osgEarth, but this should not be a problem :) I've tried the following according your sample: Code: ControlCanvas* canvas = ControlCanvas::getOrCreate( view );

Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi Remo, A more detailed description on how it fails would be helpful. If you're seeing non-textures quads instead of your glyphs you need to adapt your shader as the text-rendering isn't using a normal blending. I've attached my default core-profile shader which uses pre-multiplied alpha.

[osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO

Hi, I can't render osgText on MacOSX Core Profile: text->setTextBackdropType(osgText::Text::BackdropType::NONE); text->setTextBackdropImplementation(osgText::Text::BackdropImplementation::DELAYED_DEPTH_WRITES); text->setBackColor( Color( Color::Black, 0.8 ) ); text->setHorizAlign(

Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...

I can suggest three possible fixes in order of descending "cleanliness" 1) You can tag your application using an application manifest that tells Windows that the application is DPI aware and handles all the scaling itself. 2) Another possible fix is to force compatibility scaling individually

Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...

Hi Li, I'm not a Windows expert so can't provide answers on Windows specific issues like this. My guess Windows 10 has introduced some form of window scaling that the osgViewer isn't yet aware of so doesn't take account of. To resolve this issue will require a Windows 10 dev to dive in an

Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...

Hi, I tested the newest code, it works perfectly, thank you very much. Just another problem: Under the windows 10 OS (may be other OS has the same result), when screen's TEXT SIZE isn't 100% (my computer's setting is 150%), the osgViewer.exe's full screen mode works a little odd. It just like

Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...

HI Li, Thanks for the stack trace. I've spotted the bug. The osg::Camera::setCameraThread() method was setting attempting to set the camera thread affinity even when the thread pointer was reset to null. I have just checked in a fix for this. Could you try out the OSG git master to double

Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...

Hi, I just tested standard osgviewer, all things seems good, not errors happed. CompositeViewer Crash Stack Trace Here: ot20-OpenThreadsd.dll!OpenThreads::Thread::setProcessorAffinity(const OpenThreads::Affinity & affinity) Row 617 C++

Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...

Hi Li, Could you post the stack trace for the crash? Does it happen with when you run standard osgviewer? Robert. On 7 October 2016 at 22:50, Li Chi wrote: > Hi, > > Running the attached source, when press 'ESC' key on a window to quit the > program, then the program

[osg-users] bug: new OpenSceneGraph-3.5.5 threading...

Hi, Running the attached source, when press 'ESC' key on a window to quit the program, then the program crash down. Error In Win32Thread.cpp : setProcessorAffinity function Environment: Windows 10 / Visual Studio 2015 Thank you! Cheers, Li -- Read this topic online here:

Re: [osg-users] bug: Openscenegraph-3.4 branch install error with debug dll's on VS2013

Hi Remo, Could you please test OSG git master or the up coming 3.5.5 dev release as they include a fix for the install error issue with VS. Cheers, Robert. On 29 September 2016 at 15:57, Remo Eichenberger wrote: > > > -- > Read this topic online here: >

[osg-users] bug: Openscenegraph-3.4 branch install error with debug dll's on VS2013

-- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68827#68827 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug touch point in win32

Thanks Nguyen, fix merged and submitted git master. On 25 April 2016 at 17:40, Nguyen Van Truong wrote: > I Use two touch screen in my App. I had a bug touch point in secondary > screen ( the touch point not same mouse push point). My code repair > > case WM_TOUCH: >

[osg-users] bug in primitiveset.cpp?

Hello all I notice strange code at l231 of PrimitiveSet.cpp: Code: if (useVertexBufferObjects) { GLBufferObject* ebo = getOrCreateGLBufferObject(state.getContextID()); state.bindElementBufferObject(ebo); if (ebo) { if (_numInstances>=1)

Re: [osg-users] bug in primitiveset.cpp?

Yes, it's a crash changing usevertexbufferobject at runtime that leads me to this observation: bindElementBufferObject(0) crashes at if(ebo->isDirty()) Code: inline void bindElementBufferObject(osg::GLBufferObject* ebo) { if (ebo == _currentEBO) return; if

Re: [osg-users] bug in primitiveset.cpp?

Hi Julien, I've just looked at the State::bindElementBufferObject(..) implementation and it looks like it attempts to access the ebo even if the ptr is 0 which will cause a crash. I'm guess this probably doesn't happen if the osg::Geometry is set up correctly as the EBO should be created, as if

Re: [osg-users] Bug in Viewer::setReferenceTime

Hi Benjamin, Well spotted, can't believe how long that bug will have been lurking without being picked up. I've applied your suggested fix to CompositeViewer and Viewer in OSG-svn/trunk and the OSG-3.2 branch. Cheers, Robert. On 6 June 2015 at 21:44, Benjamin Richter b...@waldteufel.eu wrote:

[osg-users] Bug in Viewer::setReferenceTime

Hi everybody. I was having some trouble with Viewer::setReferenceTime today and while debugging found the issue in the following line [1] double delta_ticks = (time-currentTime)*(osg::Timer::instance()-getSecondsPerTick()); As currentTime and time are given in seconds (see link below for

Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state

Hi Dan, It was never my intention that the osgGA::CameraManipualtor would become THE way to manage cameras in OSG users applications, just a convenient tool for most OSG examples and basic OSG applications. They have kinda taken on a bit of life of their own, beyond what really the merit they

Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state

For now, existing manipulators does fit. Well... almost :) I have an idea to write my own, but for quick-n-dirty concept existing will be ok. Cheers, Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62623#62623

Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state

Thanx, Robert! Get it. I suppose, the most convenient way then - is to subclass KeySwitchMatrixManipulator and override handle() method. My app knows, what manipulators will be added to KeySwitcher, and will perform all required additional settings during switch. Cheers, Dan

Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state

Hi Dan, The getMatrix/setByMatrix methods in the CamaraManipulators might be convinient and sufficient for switching between some manipulators but there are too many settings in some of the manipulators to be able to set it purely from a 4x4 matrix so the manipulator has to make a guess at what

[osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state

I have discovered, that when working with manipulators, it is not enough to call getMatrix() and setByMatrix(), when switching between manipulators, say, with KeySwitchManipulator. You can try it: run osgsimulation example and try to switch between manipulators with '1' and '2' keys. The

Re: [osg-users] Bug in Collada reader

Hi Mark, Thanks for the rest model. I have finally had the time to look into this issue and have resolved it by added a fallback of reading the color array as a Vec3Array if only rgb colours are available. The fix is checked into svn/trunk. Cheers, Robert. On 27 March 2014 at 14:35, Bolstad,

Re: [osg-users] BUG: osgGA::GUIEventAdapter returns wrong mouse ranges on android

Hi Paul, The osgGA::GUIEventAdapter has an MouseYOrientation value that provides information on which way up the Y axis is. OpenGL has Y going up, while most UI toolkits have Y going down, to handle this discrepency osgGA::GUIEventAdapter provides the MouseYOrigentation and other utilities adapt

Re: [osg-users] BUG: osgGA::GUIEventAdapter returns wrong mouse ranges on android

I can confirm this issue. For android I use setUpViewerAsEmbeddedInWindow(0, 0, width, height) and then setMouseInputRange(0, 0, width, height). I then send the input via getEventQueue()-mouseButtonPress(x, y, button); The input coordinates from android seem to be correct at this point,

Re: [osg-users] [BUG?] OSG traits without window decoration

Hi, Guys, I got the solution. Thanks a lot for all your help! The code is right now like this: Code: void init_viewer(osgViewer::Viewer* Viewer, int x, int y, int width, int height) { scene = osgDB::readNodeFile(d:/OpenSceneGraph-Data/cessna.osg); Viewer-setSceneData(scene);

Re: [osg-users] [BUG?] OSG traits without window decoration

Trajce Nikolov NICK wrote: Hi So when the window is not visible, I would prefer to pause the rendering of the model instead of destroying it. You can control the rendering loop by calling viewer-frame() whenever you need. In some sort of similar application in the past I

Re: [osg-users] [BUG?] OSG traits without window decoration

Hi Marco, But how do I get a HWND of the viewer? if (_viewer.valid()) { osgViewer::CompositeViewer::Windows wins; _viewer-getWindows(wins); #ifdef WIN32 if (wins.size()) { osgViewer::GraphicsHandleWin32 *hdl = dynamic_castosgViewer::GraphicsHandleWin32*(wins.at(0)); if(hdl) { MSG* message =

[osg-users] [BUG?]

Hi everybody, I have found a possible bug in OSG. But maybe I am using OSG wrong. Hopefully someone can help me finding a solution. Here's the case: I want to use OSG for 3D rendering a model that I use in my own software programm. To embed the OSG window in my program, I want to put it on top

Re: [osg-users] [BUG?] OSG traits without window decoration

Hello Robert, Thanks for your quick reply! I really appreciate it! :D Could you please tell me where (or on which line) I destroy the graphics window? (Just to prevent I make the same mistake in the future...) Ok, let me explain what the situation is. I have a software application that needs

Re: [osg-users] [BUG?] OSG traits without window decoration

Hi Marco, On Tue, May 27, 2014 at 10:11:32AM +0200, Marco Kliko wrote: As our applcation has multiple pages, the OSG window only should be visible when the page is active that needs to show the 3D-model. I had in mind to put the osg window on top of the apllication page. Combining this

Re: [osg-users] [BUG?] OSG traits without window decoration

Hi Marco, On Tue, May 27, 2014 at 11:01:36AM +0200, Marco Kliko wrote: I think I understand what you mean but I have no idea what to search for. Could you be so kind to give me a link to an example describing your proposal? Or some keywords to search for? I would directly search for OpenGL

Re: [osg-users] [BUG?] OSG traits without window decoration

Daniel, Thanks for sharing your thought. But these widgets are implemented inside a Qt-enivronment application. Am I right? The environment of the application I am working with doesn't allow adding a widget in the window. It's a sort of selfmade environment that's why I want to put the

Re: [osg-users] [BUG?] OSG traits without window decoration

Hi So when the window is not visible, I would prefer to pause the rendering of the model instead of destroying it. You can control the rendering loop by calling viewer-frame() whenever you need. In some sort of similar application in the past I used timer to render the frame and when not needed

[osg-users] BUG: osgGA::GUIEventAdapter returns wrong mouse ranges on android

Dear OSG users, the methods GUIEventAdapter.getXmin, GUIEventAdapter.getXmax, GUIEventAdapter.getYmin, GUIEventAdapter.getYmax ... always return mouse input ranges of -1...1 instead of e.g. 0...1280, 0...800. Because of this bug, the standard picking handler is not working. The viewer is created

[osg-users] Bug in Collada reader

While trying to map some functionality to color per vertex, I came across a bug in that colors aren’t loaded properly. At daeReader::resolveMeshArrays:931 (daeRGeometry.cpp) it calls out to createGeometryArrays with types of Vec4Array. If you trace this down into the daeSourceReader call to

Re: [osg-users] Bug in Collada reader

from what you are stating if the color array is Vec4Array in creation you should cast to the same in the reading portion - I guess the 4th component is alpha of the color which is the proper way to have the colors stored. So the fix would be casting to Vec4array in the reading part to get valid

Re: [osg-users] Bug in Collada reader

I read the code fast, actually it is the other way around I think. In the reader it should read Vec4Array. Can you point me to the reading part (file:line) where to look? Nick On Thu, Mar 27, 2014 at 4:21 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: from what you are stating

Re: [osg-users] Bug in initial renderer compile?

Hi Michael, On 24 January 2014 07:08, Michael Jensen mich...@ifad.dk wrote: Yes you may suggest upgrading to 3.2 ;-). It is indeed a good time since we have shipped our product to the customer and it will be a while until the next release. We are using osgEarth, osgBullet (and thus osgWorks)

Re: [osg-users] Bug in initial renderer compile?

Ok. I will do that. Michael On Fri, Jan 24, 2014 at 9:55 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Michael, On 24 January 2014 07:08, Michael Jensen mich...@ifad.dk wrote: Yes you may suggest upgrading to 3.2 ;-). It is indeed a good time since we have shipped our product to

Re: [osg-users] Bug in initial renderer compile?

Thanks for the example Michael. Using this example I recreated the problem with svn/trunk and fixed it by adding a clean up of an osg::Program that are applied during the GLObjectVisitor traversal. I have checked the fix into svn/trunk and OSG-3.2 branch. I have also attached a diff file of the

Re: [osg-users] Bug in initial renderer compile?

You are welcome, Robert. And thank you for providing a patch. It worked like a charm! :-) Yes you may suggest upgrading to 3.2 ;-). It is indeed a good time since we have shipped our product to the customer and it will be a while until the next release. We are using osgEarth, osgBullet (and thus

[osg-users] Bug in initial renderer compile?

Hi, During development of a new shader-based point-rendering system I started getting INVALID_OPERATION at start of State::apply(StateSet*) for the first rendered frame (subsequent frames are OK). The scene consists of a geode, shapedrawable box (no stateset/fixed function pipeline) and the

Re: [osg-users] Bug in initial renderer compile?

Hi Micahel, It could be a big with the GLCompileVisitor not cleaning up on the state it's compiling. Could you create a small example that illustrates this problem - such as modifiying one the OSG examples such as osgshape so it can reproduce the error. With such an example I can then step

Re: [osg-users] Bug in initial renderer compile?

Hi, I have the same issue on my ATI laptop but it is not happening on NVIDIA machines Nick On Wed, Jan 22, 2014 at 1:58 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Micahel, It could be a big with the GLCompileVisitor not cleaning up on the state it's compiling. Could you create

Re: [osg-users] Bug in initial renderer compile?

Hi Robert and Nick, It does very much look like a missing cleanup after compilation. The following things need to be present: - a geometry shader - a uniform - rendering the node using the above after an object that is not compatible with the shader program. I have attached a modified version

Re: [osg-users] Bug in initial renderer compile?

Hi again, I should mention that I am currently on OpenSceneGraph 3.1.4. :-) Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57962#57962 ___ osg-users mailing list

[osg-users] Bug in trunk with Intersector epsilon

Hi, I think there is a bug in the trunk : the epsilon used for osgUtil::Intersector class is not initialized. Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55692#55692

Re: [osg-users] Bug in trunk with Intersector epsilon

Hi Aurelien, On 1 August 2013 16:09, Aurelien Albert aurelien.alb...@alyotech.fr wrote: I think there is a bug in the trunk : the epsilon used for osgUtil::Intersector class is not initialized. Opps, I did originally have a initializer for _epsilon when it was initially implemented in

Re: [osg-users] Bug in Qt thread integration

Hi, I have run into the same problem with the application I'm working on. Since it seems to me that it was not corrected yet (or am I mistaken?), i'm writing here. I suggest that at least the static_cast is replaced with the dynamic_cast: Code: QtThreadPrivateData* pd =

[osg-users] Bug in osgGA::GUIEventHandler in OSG 3.0.1 release (fixed in current trunk).

Hi guys, Our software uses OSG for displaying a modelview for our muscular-skeletal simulation software. In our latest beta-version we have switched to OSG 3.0.1, but we just yesterday found a bug related to osgGA::GUIEventHandler, which we use for handling mouse events in our modelview. If we

Re: [osg-users] Bug in osgGA::GUIEventHandler in OSG 3.0.1 release (fixed in current trunk).

Hi Jesper, I'm just wrapping up some work and plan to make a developer release this week. I don't have an schedule for the next stable release, but would like to get one out in the next few months. Robert. On 22 January 2013 14:32, Jesper D. Thomsen j...@anybodytech.com wrote: Hi guys,

[osg-users] bug in GraphicsWindowQt

Hi, it seems there is a bug in GraphWidget::keyPressEvent( QKeyEvent* event ) at least in OSG 2.9.14 with Qt 4.8.2. I guess the problem is here: int remapKey(QKeyEvent* event) { KeyMap::iterator itr = mKeyMap.find(event-key()); if (itr == mKeyMap.end()) {

Re: [osg-users] Bug in Qt thread integration

Hi, Thanks for the replies and suggestions. I think I might not have explained the issue as well as I thought, so I'll try again. QThread::currentThread does return a value with static type QThread*. However, it might not point to a QThread instance, but an instance of a subclass of QThread.

Re: [osg-users] Bug in Qt thread integration

Hi, In fact QThread::currentThread returns a QThread. maybe you want to use qobject_cast instead of other casts, it is has some other advantages (http://lists.qt.nokia.com/pipermail/qt-interest/2010-October/028327.html). Cheers, Torben -- Read this topic online here:

  1   2   3   4   >