Hi Robert,
final analysis:
In our software we did the following patch to make it run with high fps
in master of 3.4 branch:
osgNormals=newosg::Vec3Array;
+osgNormals->setBinding(osg::Array::BIND_PER_VERTEX);
geometry->setNormalArray(osgNormals.get());
geometry->setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
Obviously we have to set the binding in the array itself and the
setNormalBinding works but has poor performance.
Now we are happy again :-)
- Werner -
Am 31.03.2017 um 13:11 schrieb Werner Modenbach:
Hi Robert,
the 3.4.0 tagged version is OK with the frame rate.
We discovered your commit in the 3.4 branch causing the problem:
From1f1c21772ae0dd10a93cd31ab81bf563802b7b2dMonSep1700:00:002001
From:RobertOsfield<[email protected]>
Date:Thu,3Nov201611:31:07+0000
Subject:Addedcheckagainstbindingtypeofarraytodecidewhetherit's
appropriatetoassignarraytoVBO.
diff--gita/src/osg/Geometry.cppb/src/osg/Geometry.cpp
index779e8cd..244bf25100644
---a/src/osg/Geometry.cpp
+++b/src/osg/Geometry.cpp
@@-445,7+445,7@@boolGeometry::getDrawElementsList(DrawElementsList&drawElementsList)const
voidGeometry::addVertexBufferObjectIfRequired(osg::Array*array)
{
-if(_useVertexBufferObjects)
+if(_useVertexBufferObjects&&array->getBinding()==Array::BIND_PER_VERTEX)
{
if(!array->getVertexBufferObject())
{
The question is: Why is the viewer frame rate OK, even it is built
with the same version we are using?
What are we doing different to the viewer?
Thanks so much for your excellent work!
- Werner -
Am 28.03.2017 um 18:22 schrieb Robert Osfield:
Hi Wener,
On 28 March 2017 at 16:24, Werner Modenbach
<[email protected] <mailto:[email protected]>> wrote:
I know it is actually not your duty giving help here but you are very
familiar with the driver calls and it would help a lot if you can
provide
an idea what kind of setting might cause this issue.
I'm a very occasional Windows user so really don't have much
experience with Windows drivers to be able help with driver settings.
It's a long shot, but have your tried the OSG-3.4 branch or OSG
master as these both contain a range of bug fixes/OSG improvements,
there is chance that something has changed that might fix things.
Whatever the cause is it seems to be some small OpenGL state
difference between OSG-3.2 and OSG-3.4.0, I'm afraid I don't know
what this might be. Perhaps using a 3rd party OpenGL debugging tool
might help here - capture all the GL calls for 3.2.x and 3.4.x and
see what the differences are.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
*TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen*
Phone: +49 241 475757-0
Fax: +49 241 475757-29
Web: http://texion.eu
eMail: [email protected]
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
*TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen*
Phone: +49 241 475757-0
Fax: +49 241 475757-29
Web: http://texion.eu
eMail: [email protected]
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
