Re: [osg-users] osglight demo problems with Intel graphics on Windows
Hi Ryan, The osglight example just just the fixed function pipeline and doesn't provide any shaders. What you describe sounds like an Intel driver bug. The best thing you can do is check for latest Intel drivers. Robert. On Mon, 9 Jul 2018 at 21:51, Ryan Thoryk wrote: > > I recently started a project based on the osglight demo. I have a laptop > with switchable graphics, and under Linux the demo works great under both > Intel and Nvidia graphics. Under Windows 10 however, lighting doesn't appear > to work with the Intel driver, even though it works fine in Linux (bad > drivers?). The console also outputs this: > > > > > > Screen 0: > > Vendor: Intel > > Renderer: Intel(R) HD Graphics 3000 > > GL Version: 3.1.0 - Build 9.17.10.4459 > > Warning: detected OpenGL error 'invalid enumerant' at After > > Renderer::compile > > > > which implies that the app is using shaders. I thought that the OSG lights > used the FFP OpenGL lights and not shaders. > > I'm attaching a screenshot of the project. > > Ryan > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=74296#74296 > > > > > Attachments: > http://forum.openscenegraph.org//files/lightmod_173.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] Graphics context issues
Your code works when my laptop is using Intel graphics, but when I switch to Nvidia graphics, the glGetString calls fail for some reason (maybe the GL context isn't switching?). Strange. Switching the whole app to single-threaded works for both. Ryan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74297#74297 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osglight demo problems with Intel graphics on Windows
I recently started a project based on the osglight demo. I have a laptop with switchable graphics, and under Linux the demo works great under both Intel and Nvidia graphics. Under Windows 10 however, lighting doesn't appear to work with the Intel driver, even though it works fine in Linux (bad drivers?). The console also outputs this: > > Screen 0: > Vendor: Intel > Renderer: Intel(R) HD Graphics 3000 > GL Version: 3.1.0 - Build 9.17.10.4459 > Warning: detected OpenGL error 'invalid enumerant' at After Renderer::compile > which implies that the app is using shaders. I thought that the OSG lights used the FFP OpenGL lights and not shaders. I'm attaching a screenshot of the project. Ryan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74296#74296 Attachments: http://forum.openscenegraph.org//files/lightmod_173.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphics context issues
SMesserschmidt wrote: > I guess your interfering with the currently set context. You're not > explaining where/when you call your snippet, but usually this would be > done inside a "realizeOperation". > I'll try your code. I was doing the code snippet right after a "viewer->realize()" call. Ryan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74292#74292 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] massive text rendering.
Hi Igor, You can implement your own texture using osg::Geometry and reuse the osg::Font's ability to generate the texture atlas. It's a bit involved to get all the alignment etc. issues right but it's perfectly doable and does perform very well. However, before you dive off in a complicated but of work I would suggest testing out OSG-3.6.2 if you haven't already, the internal implementation is completely different and uses shaders rather than multi-pass to implement the fonts so should be lightweight. If this doesn't perform well enough then fall back to your own custom solution. Cheers, Robert. On Mon, 9 Jul 2018 at 13:24, Igor Spiridonov wrote: > > Hello. > > Is it possible to render a lot of text in one batch? For polygons we have vbo > which is huge performance improvement for massive geometry. Do we have > anything similar for text? I have about 4000-5000 text messages(same font > but different color) and it's very slow to have 4000-5000 dips. > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=74290#74290 > > > > > > ___ > 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
[osg-users] massive text rendering.
Hello. Is it possible to render a lot of text in one batch? For polygons we have vbo which is huge performance improvement for massive geometry. Do we have anything similar for text? I have about 4000-5000 text messages(same font but different color) and it's very slow to have 4000-5000 dips. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74290#74290 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB XmlParser and localization
Hi again Robert, fast hint: The nodes to be parsed are root->osm->node->tag and their properties contains these non asci codes. But probably fastest is to write recursive parser Thanks again On Mon, Jul 9, 2018 at 1:54 PM Trajce Nikolov NICK < trajce.nikolov.n...@gmail.com> wrote: > Thanks so much Robert !!! Attached is the file > > > > On Mon, Jul 9, 2018 at 1:50 PM Robert Osfield > wrote: > >> Hi Nick, >> >> On Mon, 9 Jul 2018 at 12:26, Trajce Nikolov NICK >> wrote: >> > > are changes for changes sake rather than likely to make any >> > functional difference >> > >> > I knew you will have comments ;-). It works just fine with these >> changes but yes, you are right - quick and somewhat dirty. So can you look >> at it or you want to do a ping-pong code review with my changes by your >> advice? :-) >> >> I might be quicker just to provide a link to or attach an xml file >> that causes problem with the present parser, and then I can look at >> what happens when the present code encounters it, and how your changes >> affect things. >> >> As a general note, PRs/commits should be focused on addressing one >> issue at a time, so bundling a fix for a specific bug along with other >> cosmetic or other changes just confuses what is functional and what is >> not. It's not uncommon to have to go back to various revisions in >> code to see where regressions may have occurred so having commits that >> just wrap up a small set of associated changes is really helpful in >> identifying what has been changed and why. >> >> Robert. >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > -- > trajce nikolov 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] osgDB XmlParser and localization
Hi Nick, On Mon, 9 Jul 2018 at 12:26, Trajce Nikolov NICK wrote: > > are changes for changes sake rather than likely to make any > functional difference > > I knew you will have comments ;-). It works just fine with these changes but > yes, you are right - quick and somewhat dirty. So can you look at it or you > want to do a ping-pong code review with my changes by your advice? :-) I might be quicker just to provide a link to or attach an xml file that causes problem with the present parser, and then I can look at what happens when the present code encounters it, and how your changes affect things. As a general note, PRs/commits should be focused on addressing one issue at a time, so bundling a fix for a specific bug along with other cosmetic or other changes just confuses what is functional and what is not. It's not uncommon to have to go back to various revisions in code to see where regressions may have occurred so having commits that just wrap up a small set of associated changes is really helpful in identifying what has been changed and why. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB XmlParser and localization
hi Robert, > are changes for changes sake rather than likely to make any functional difference I knew you will have comments ;-). It works just fine with these changes but yes, you are right - quick and somewhat dirty. So can you look at it or you want to do a ping-pong code review with my changes by your advice? :-) Please let me know Nick On Mon, Jul 9, 2018 at 1:09 PM Robert Osfield wrote: > Hi Nick, > > I had a quick look at your changes and it seems to be like most of > them are changes for changes sake rather than likely to make any > functional difference. For non ascii char support I think what you'd > actually want to do is change the XmllNode::Input::string _buffer > member var to a std::vector _buffer, and have the > Input::readAllDataIntoBuffer() method be adapted to read the file > accepting only chars greater than 0 rather than limiting to the ascii > 0 to 255 range. > > Robert. > On Mon, 9 Jul 2018 at 11:41, Trajce Nikolov NICK > wrote: > > > > Hi Robert, > > > > I am working with some localized XML files (with chars out of 0-255 > range) and at present the XML Node parsing is not suitable to manage it. > And I think the support for is important - at my case it is OpenStreetMap > with street names containing these chars. > > > > Attached is the modified source (based on the master) that fixes ity, if > you have time and will to review. I can do PR if you want > > > > Thanks and cheers! > > > > Nick > > > > p.s. welcome back > > > > -- > > trajce nikolov nick > > ___ > > 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 > -- 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] Model(s) load ~10 times longer in 3.6.x than 3.4.x series in osgviewer (and my in-house software)
I have other tasks to get on with today so I won't keep pursing this loading speed regression right away, if others want to look at before I come back to it then the way I think it should be tackled is be changing the loader to so it creates a small set of primitives using GL_TRIANGLES rather than many separate DrawArrays GL_TRIANGLE_FAN. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB XmlParser and localization
Hi Nick, I had a quick look at your changes and it seems to be like most of them are changes for changes sake rather than likely to make any functional difference. For non ascii char support I think what you'd actually want to do is change the XmllNode::Input::string _buffer member var to a std::vector _buffer, and have the Input::readAllDataIntoBuffer() method be adapted to read the file accepting only chars greater than 0 rather than limiting to the ascii 0 to 255 range. Robert. On Mon, 9 Jul 2018 at 11:41, Trajce Nikolov NICK wrote: > > Hi Robert, > > I am working with some localized XML files (with chars out of 0-255 range) > and at present the XML Node parsing is not suitable to manage it. And I think > the support for is important - at my case it is OpenStreetMap with street > names containing these chars. > > Attached is the modified source (based on the master) that fixes ity, if you > have time and will to review. I can do PR if you want > > Thanks and cheers! > > Nick > > p.s. welcome back > > -- > trajce nikolov nick > ___ > 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
[osg-users] osgDB XmlParser and localization
Hi Robert,
I am working with some localized XML files (with chars out of 0-255 range)
and at present the XML Node parsing is not suitable to manage it. And I
think the support for is important - at my case it is OpenStreetMap with
street names containing these chars.
Attached is the modified source (based on the master) that fixes ity, if
you have time and will to review. I can do PR if you want
Thanks and cheers!
Nick
p.s. welcome back
--
trajce nikolov nick
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2009 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include
#include
#include
using namespace osgDB;
XmlNode* osgDB::readXmlFile(const std::string& filename,const Options* options)
{
std::string foundFile = osgDB::findDataFile(filename, options);
if (!foundFile.empty())
{
XmlNode::Input input;
input.open(foundFile);
input.readAllDataIntoBuffer();
if (!input)
{
OSG_NOTICE<<"Could not open XML file: "< root = new XmlNode;
root->read(input);
return root.release();
}
else
{
OSG_NOTICE<<"Could not find XML file: "< root = new XmlNode;
root->read(input);
return root.release();
}
XmlNode::ControlMap::ControlMap()
{
setUpControlMappings();
}
void XmlNode::ControlMap::addControlToCharacter(const std::string& control, int
c)
{
_controlToCharacterMap[control] = c;
_characterToControlMap[c] = control;
}
void XmlNode::ControlMap::setUpControlMappings()
{
addControlToCharacter("",'&');
addControlToCharacter("",'<');
addControlToCharacter("",'>');
addControlToCharacter("",'"');
addControlToCharacter("",'\'');
addControlToCharacter("",'\n');
}
XmlNode::Input::Input():
_currentPos(0)
{
}
XmlNode::Input::Input(const Input&):
ControlMap(),
_currentPos(0)
{
}
XmlNode::Input::~Input()
{
}
void XmlNode::Input::open(const std::string& filename)
{
_fin.open(filename.c_str());
}
void XmlNode::Input::attach(std::istream& fin)
{
std::ios = _fin;
fios.rdbuf(fin.rdbuf());
}
void XmlNode::Input::readAllDataIntoBuffer()
{
while(_fin)
{
int c = _fin.get();
//if (c>=0 && c<=255)
{
_buffer.push_back(c);
}
}
}
void XmlNode::Input::skipWhiteSpace()
{
while(_currentPos<_buffer.size() && (_buffer[_currentPos]==' ' ||
_buffer[_currentPos]=='\t' || _buffer[_currentPos]=='\n' ||
_buffer[_currentPos]=='\r'))
{
//OSG_NOTICE<<"_currentPos="<<_currentPos<<"_buffer.size()="<<_buffer.size()<<"
v="");
commentNode->contents = input.substr(0, end);
if (end!=std::string::npos)
{
OSG_INFO<<"Valid Comment record
["");
commentNode->contents = input.substr(0, end);
if (end!=std::string::npos)
{
OSG_INFO<<"Valid information record
["");
commentNode->contents = input.substr(0, end);
if (end!=std::string::npos)
{
OSG_INFO<<"Valid information record
["");
commentNode->contents = input.substr(0, end);
if (end!=std::string::npos)
{
OSG_INFO<<"Valid information record
["name.push_back(c);
Re: [osg-users] Model(s) load ~10 times longer in 3.6.x than 3.4.x series in osgviewer (and my in-house software)
I have established it's the osgUtil::optimizeMesh(geometry); call in
the 3.6 obj plugin that is causing the slow down in .obj loading.
When writing the model out to .osgt without the optimization you can
see the likely reason why this dataset might be triggering issues:
PrimitiveSetList 265486 {
osg::DrawArrays {
UniqueID 6
Mode TRIANGLE_FAN
Count 4
}
osg::DrawArrays {
UniqueID 7
Mode TRIANGLE_FAN
First 4
Count 4
}
..
So we have 265 thousand triangle fan DrawArrays that loader has
created. That's about as inefficient as you can get as it not only is
using lots separate primitives but also implies that non of the vertex
data is being shared either.
I'm not the author of the obj plugin so can't immediately pinpoint
what bit of code is responsible for creating this poorly structured
dataset. The .obj format presents the individual primitives one by
one so is the root cause of this, but the loader should probably not
be happing this verbatim.
At this point I don't have a clear suggestion of solution, I'm
inclined to think that the plugin shouldn't load the data verbatim as
it's doing right now, then trying to fix the problems this causes
after the fact.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Model(s) load ~10 times longer in 3.6.x than 3.4.x series in osgviewer (and my in-house software)
Now tested the model with 3.4 - much faster: $ time osgconv SquareTest.obj test_34.osgb Data written to 'test_34.osgb'. real0m3.842s user0m3.112s sys 0m0.728s I've looked at the diffs between 3.4 and 3.6 for the obj plugin, the only difference that stands out as a possible cause is the use of mesh optimzer instead of the tri strip visitor. Mesh optimizer works much better for modern graphics cards, I wouldn't have expected such a slow down though, there must be something in the presentation of this particular dataset that is cause issues. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Model(s) load ~10 times longer in 3.6.x than 3.4.x series in osgviewer (and my in-house software)
Hi James, The file was too big to distribute on the osg-users mailing list that mirrors the forum so I pulled down the data from the forum and can see the loading performance issue when using OpenSceneGraph-3.6.2: $ time osgconv SquareTest.obj test.osgb Data written to 'test.osgb'. real5m2.443s user5m2.352s sys 0m0.068s The resulting test.osgb loads quickly and runs fine. I will do a build of the OSG-3.4 branch and see what happens. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] osgOcean - Render to Texture Camera
Hi Rob, I am afraid that osgOcean is a 3rd party NodeKit that was written a long time ago and as far as I'm aware has seen active development or widespread use across the OSG community, so the chances of having others that have the knowledge to help will be quite low. I don't know if the original authors are still active, they would be the best ones to ask. It might be that if you want to use osgOcean you'll need to work how it works and maintain it yourself. Best of luck, Robert. On Fri, 6 Jul 2018 at 13:44, Rob Ewbank wrote: > > Hi, > > I'm building an interactive projection mapping using osgOcean to simulate the > sea, for this I need to render to texture. The RTT camera I'm using works > fine on other scenes, however, when using osgOcean, it does not render > properly: see attached images. > > I've tried setting the render order to pre, nested and post, none of these > work. When using a slave camera rather than main I get the results in images, > without that it's even worse. > > Changing glare on the scene seems to have a big impact on the result and I've > tried turning on / off all other features, such as reflection, refraction, > etc. with no luck. > > What steps should I take in order to successfully render this scene to > texture? > > > Thank you! > > Cheers, > Rob > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=74256#74256 > > > > > Attachments: > http://forum.openscenegraph.org//files/ocean_rtt_glare_130.png > http://forum.openscenegraph.org//files/ocean_rtt_no_glare_110.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] Updating scene properties instead of recreation it each frame.
Hi Igor,
The OSG uses OpenGL display lists by default, or
VertexBufferObjects/VertexArrayObjects when enabled via
osg::Geometry::setUserVertexBufferObjects(true) +
setUserVertexArrayObject(true). These GL objects cache the vertex
data within GL, so if you want to update the vertex data you need to
call geometry->dirtyGLObjects() to force the objects to update. You
can also call array->dirty() if you are using VBO/VAO.
If the bounding volume of the geometry changes you'll also want to
force the bounding volume to update by calling Geometry::dirtyBound();
Robert.
On Mon, 2 Jul 2018 at 06:44, Igor Spiridonov wrote:
>
> Hi. I'm wandering if it's ok what i'm doing and how to do it properly.
>
> I have data of primitives which comes from source periodically. These
> primitives are points, lines, polygons. They have different sizes, colors,
> vertices, etc. My first approach was to create a new subscene each time i
> receive new data and replace a current node to a new one. But to create a new
> scene each frame is not very fast operation(a lot of allocation
> /deallocation). So instead of that I've decided to update existing scene by
> changing vertices, primitive types, etc. But I'v noticed that some data
> somewhat cached. For example.
>
>
> Code:
>
> osg::Vec3Array& vertices =
> static_cast(*geometry.getVertexArray());
> vertices.clear();
> for (int i = 0; i < logPolygon.points.size(); i++)
>{
> auto& point = logPolygon.points[i];
> vertices.push_back(osg::Vec3(point.X / 100.f, point.Y / 100.f, 0.f));
>}
>
>geometry.setVertexArray(); // i need to do that otherwise scene
> is incorrect.
>
>
>
>
> My first question is why do I need to set vertex array again?
> "geometry.setVertexArray();"
>
> The second question is it ok to do such update of all properties instead of
> full scene recreation? What other drawbacks can be? Is there a better
> approach?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74235#74235
>
>
>
>
>
> ___
> 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] Graphics context issues
Hi Ryan,
I guess your interfering with the currently set context. You're not
explaining where/when you call your snippet, but usually this would be
done inside a "realizeOperation".
A small example operation:
class TestSupportOperation: public osg::GraphicsOperation
{
public:
TestSupportOperation()
: osg::GraphicsOperation("TestSupportOperation",false){}
virtual void operator () (osg::GraphicsContext* gc)
{
OpenThreads::ScopedLock lock(mMutex);
unsigned int contextID =gc->getState()->getContextID();
osg::GLExtensions* glext = osg::GLExtensions::Get(contextID,
true);
if (!glext->isOpenGL20Supported)
{
std::cerr << No 2.0++ suppport available\n";
}
}
OpenThreads::Mutex mMutex;
};
In your viewer you simply add:
viewer->setRealizeOperation(new TestSupportOperation);
Hope that helps,
Sebastian
Hi,
I'm trying to query GL parameters such as GL_VENDOR, which require an active
graphics context to work. I looked another thread on this forum which explains
how to do it, but it only works for a single-threaded viewer. I'm running the
viewer in multithreaded mode, and am getting crashes due to context issues.
Does anyone have an idea on how to do this?
Thanks
Example code. Usually crashes at the makeCurrent() line:
Code:
//get renderer information
osgViewer::ViewerBase::Contexts contexts;
viewer->getContexts(contexts, true);
contexts[0]->makeCurrent();
std::string vendor = (const char*)glGetString(GL_VENDOR);
Report("Vendor: " + vendor);
contexts[0]->releaseContext();
Ryan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74276#74276
___
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
[osg-users] Graphics context issues
Hi,
I'm trying to query GL parameters such as GL_VENDOR, which require an active
graphics context to work. I looked another thread on this forum which explains
how to do it, but it only works for a single-threaded viewer. I'm running the
viewer in multithreaded mode, and am getting crashes due to context issues.
Does anyone have an idea on how to do this?
Thanks
Example code. Usually crashes at the makeCurrent() line:
Code:
//get renderer information
osgViewer::ViewerBase::Contexts contexts;
viewer->getContexts(contexts, true);
contexts[0]->makeCurrent();
std::string vendor = (const char*)glGetString(GL_VENDOR);
Report("Vendor: " + vendor);
contexts[0]->releaseContext();
Ryan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74276#74276
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
