[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!
Hi All, I am delighted to say that today I began work on VulkanSceneGraph, an all new scene graph that builds upon Vulkan and modern C++. This new project can be thought of a new family member, the child of OpenSceneGraph project. As it's a family member I've created the project repository alongside the OpenSceneGraph within the github openscenegraph account: https://github.com/openscenegraph/VulkanSceneGraph Please have a read through the README.md on the above repo as this will explain a little about the project and where my focus will be for the next three months work wise conducting an Exploration Phase to scope out the technology and techniques that will go into project once we start coding the scene graph itself. This new project will co-exist with the OpenSceneGraph for years to come. I will remain as project lead of the OpenSceneGraph, I will fix bugs, push out releases, generally chase everybody to test things and also help out with general support here - continue to do what I've done for nearly two decades. Like OpenGL the OpenSceneGraph is still relevant to many application developers and I expect it to remain a corner stone of many application for years to come. Both OpenGL and OpenSceneGraph are very mature bits of software now so there isn't a need to keep pushing hard on new features, so I planning for a stable period when maintenance is increasingly the focus rather new new bells and whistles. You no doubt will have lots of questions, but at this point I can't provide too many answers on the technical front as we are so early in the project the technical details are yet to solidified - this is what my next three months work will be all about. I'll be learning everything I can about Vulkan, working out how best to encapsulate it's features them in a scene graph. I also will be looking into what features of modern C++ can bring to the table to make our lives as graphics developers easier and more productive, C++11, 14 and 17 are all under consideration. There also all the scene graph design elements that have been bubbling around in my head for the last five years that I'd like to try out to see what might be possible. Once this Exploration Phase is complete I will have a more concrete idea of what needs to be done next and will write a design document to share with the community to give everyone a clearer idea of where we are going next. During this phase I will spend most of my time working quietly away learning, testing, thinking, learning, testing, thinking. It's not a period that I am looking for lots of external input on, the best software designs don't come from committees but from a coherent and calm contemplation. I guess I need to go find myself a mediation rock on Skellig Michael :-) If you are keen to help out VulkanSceneGraph then this is something you can help out with right away, without needing me to complete any design docs or to publish any code. What all good software needs during development and through into maintenance phase are unit tests that test features and performance. To this end I can created a new SceneGraphTestBed repository to collect together in one place a set of data and test programs that we can run to test out features and performance of both the OpenSceneGraph and the VulkanSceneGraph once it starts becoming usable. https://github.com/openscenegraph/SceneGraphTestBed I don't have any data or test programs written at this point, so this repo is an empty room waiting to be filled. My thought is that we would initially just create OpenSceneGraph based test data and programs that test various features and performance of the OpenSceneGraph. If you have a particular tests that illustrate the problems areas that you have in performance, or things that are awkward to implement but shouldn't be then you could submit this as unit tests that stress the OpenSceneGraph. As the VulkanSceneGraph project evolves we tackle recreating these OpenSceneGraph test programs using the new scene graph and the have an ability to compare OpenGL/OpenSceneGraph with Vulkan/VulkanSceneGraph, as well as have a set of unit tests that we can run prior to each release of the OpenScenGraph or VulkanSceneGraph. I don't have any specific plans of how to layout or manage the SceneGraphTestBed, if you feel like it's something you'd like to pick up the lead on then let us know - I'm already have plenty to juggle myself so being able to let others manage sub projects is great way of helping us all be as productive as we can be. Thanks for your support and patience - cause I know we all want it yesterday! Robert Osfield Newly minted VulkanSceneGraph Project Lead :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Could this be why I'm not getting my colors? Cheers, Brad On Fri, Jun 1, 2018 at 8:51 AM, Robert Osfield wrote: > Hi Dan, > > Thanks for the explanation and example to reproduce the bug... Guess > it looks like we'll need to make 3.6.2 rather sooner than I was > hoping, it'll be one a month at this rate... > > Robert. > > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773 > wrote: > > Hi Robert, > > > > Oops -- I sent this earlier today but apparently to the bounces list; > that explains the confusion on GitHub -- my mistake. This was supposedly > sent right before I posted the PR. Here's the original text: > > > > > > I think I found a bug in 3.6.1. I am loading a FLT model and it's > causing a crash in my application to draw it. The same model does not > crash in OSG 3.4. I think I've finally tracked down the cause and have a > candidate solution too. > > > > A few weeks back I saw a similar crash in my own code, and figured it > was due to incorrect usage of the binding flags on osg::Array. Much of our > code was using osg::Geometry::setNormalBinding() (and related methods). > During debugging, I was able to determine my normals were crashing in 3.6, > and the problem went away when I used the osg::Array(osg::Array::Binding) > signature -- i.e. assigning a binding on construction. At the time I > thought it was something I was doing wrong and moved on. > > > > The problem showed up again earlier this week but not in my code, and > not manifesting in exactly the same way. Here's the run-down of what's > going on: > > > > - Loading FLT model > > - FLT model loads a face, which has vertices, textures, and normals > > - FLT uses getOrCreateNormalArray(), which allocates an array > (BIND_UNDEFINED) and sets it on the geometry > > - Geometry::addVertexBufferObjectIfRequired() is called on the normals, > but nothing done due to BIND_UNDEFINED > > - FLT later sets normals to BIND_PER_VERTEX appropriately, which is a > direct set and does not do anything to the Geometry's VBOs > > - First frame starts to render > > - Geometry::drawVAImpl calls vas->setNormalArray() > > - VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(), > which returns 0. This is the first major problem. > > - Because vbo is NULL, unbindindVertexBufferObject() is called, leading > to GL_ARRAY_BUFFER to go to 0 > > - vad->enable_and_dispatch() gets called and does > glVertexAttribPointer() with a non-NULL data ptr, which is a GL error > because array buffer is 0 > > > > Unwinding the error: > > - enable_and_dispatch() shouldn't be called if ptr is non-NULL and no > GL_ARRAY_BUFFER is 0 > > - GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the > normal array > > - There is no normal array because the only place it seems to be created > is in setNormalArray(), which fails because at that time, it is > BIND_UNDEFINED > > - Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after > setNormalArray(), leading to the error > > > > There are several possible solutions I can see. You can probably see > more: > > 1) Change FLT plugin to assign array binding per vertex on construction > of array. Seems poor because invariably this bug is crashing other code -- > maybe it's the cause of the DXF that Brian Hutchison reported earlier this > week? > > 2) Update Array::setBinding() to create the VBO if needed. I do not > know if this is possible nor how to do it. > > 3) "Lazily" detect this issue somewhere in the rendering calls and > create VBO there if necessary > > > > > > > > PR 554 was an attempt at approach #3 but I agree with your assessment on > GitHub. It does not solve the problem in all cases. > > > > Attached is a demo of the problem that generates a console warning. > More complex scenes can cause crashes. The red triangle has the problem, > but the green one does not. > > > > - Dan > > > > > > ___ > > 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Dan, Thanks for the explanation and example to reproduce the bug... Guess it looks like we'll need to make 3.6.2 rather sooner than I was hoping, it'll be one a month at this rate... Robert. On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773 wrote: > Hi Robert, > > Oops -- I sent this earlier today but apparently to the bounces list; that > explains the confusion on GitHub -- my mistake. This was supposedly sent > right before I posted the PR. Here's the original text: > > > I think I found a bug in 3.6.1. I am loading a FLT model and it's causing a > crash in my application to draw it. The same model does not crash in OSG > 3.4. I think I've finally tracked down the cause and have a candidate > solution too. > > A few weeks back I saw a similar crash in my own code, and figured it was due > to incorrect usage of the binding flags on osg::Array. Much of our code was > using osg::Geometry::setNormalBinding() (and related methods). During > debugging, I was able to determine my normals were crashing in 3.6, and the > problem went away when I used the osg::Array(osg::Array::Binding) signature > -- i.e. assigning a binding on construction. At the time I thought it was > something I was doing wrong and moved on. > > The problem showed up again earlier this week but not in my code, and not > manifesting in exactly the same way. Here's the run-down of what's going on: > > - Loading FLT model > - FLT model loads a face, which has vertices, textures, and normals > - FLT uses getOrCreateNormalArray(), which allocates an array > (BIND_UNDEFINED) and sets it on the geometry > - Geometry::addVertexBufferObjectIfRequired() is called on the normals, but > nothing done due to BIND_UNDEFINED > - FLT later sets normals to BIND_PER_VERTEX appropriately, which is a direct > set and does not do anything to the Geometry's VBOs > - First frame starts to render > - Geometry::drawVAImpl calls vas->setNormalArray() > - VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(), > which returns 0. This is the first major problem. > - Because vbo is NULL, unbindindVertexBufferObject() is called, leading to > GL_ARRAY_BUFFER to go to 0 > - vad->enable_and_dispatch() gets called and does glVertexAttribPointer() > with a non-NULL data ptr, which is a GL error because array buffer is 0 > > Unwinding the error: > - enable_and_dispatch() shouldn't be called if ptr is non-NULL and no > GL_ARRAY_BUFFER is 0 > - GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the normal > array > - There is no normal array because the only place it seems to be created is > in setNormalArray(), which fails because at that time, it is BIND_UNDEFINED > - Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after > setNormalArray(), leading to the error > > There are several possible solutions I can see. You can probably see more: > 1) Change FLT plugin to assign array binding per vertex on construction of > array. Seems poor because invariably this bug is crashing other code -- > maybe it's the cause of the DXF that Brian Hutchison reported earlier this > week? > 2) Update Array::setBinding() to create the VBO if needed. I do not know if > this is possible nor how to do it. > 3) "Lazily" detect this issue somewhere in the rendering calls and create VBO > there if necessary > > > > PR 554 was an attempt at approach #3 but I agree with your assessment on > GitHub. It does not solve the problem in all cases. > > Attached is a demo of the problem that generates a console warning. More > complex scenes can cause crashes. The red triangle has the problem, but the > green one does not. > > - Dan > > > ___ > 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 VBO's during runtime
Hi Brad, On 1 June 2018 at 16:26, Brad Colbert wrote: > Hah! Daniel, that was it. Darnit! Good to hear it's fixed. > BTW, I used to work at Code 5580. WAY back in the day. > > Thanks! > > Robert, sorry, I meant to mention version 3.6.0. Definitely recommend updating to 3.6.1. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Large number of occluder nodes
Hi David, Your cars could probably by simplified, such as by putting an LOD above them and have one instance for far away with no, one just one transparent part and a higher quality version. Using a texture atlas is another trick you can use to enable you to merge separate geometries. Robert. On 1 June 2018 at 15:40, David Heitbrink wrote: > We do have a city scene at ground levels with lots of cars, pedestrian, > construction zone clutter. The cars tend to be the worst as they can have up > to 8 transparent object each from them. Large parking lots can have 500+ > vehicles. > > OK so it sounds like what we need to do is to try to combine occluder nodes > the best we can. These were generated via a script and placed in the center > of each building...we just have lots of building with alleys between them. > > It also sounds like we will need to come up with some sort of paging/LOD > scheme ourselves to remove nodes more than say 2500m from the camera. > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=73909#73909 > > > > > > ___ > 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 VBO's during runtime
Hah! Daniel, that was it. Darnit!
BTW, I used to work at Code 5580. WAY back in the day.
Thanks!
Robert, sorry, I meant to mention version 3.6.0.
Cheers,
Brad
On Fri, Jun 1, 2018 at 7:39 AM, Daniel Emminizer, Code 5773 <
dan.emmini...@nrl.navy.mil> wrote:
> Hi Brad,
>
>
>
> Check to make sure your Geometry has setDataVariance(osg::Object::DYNAMIC).
> That solved the problem for most of our similar cases.
>
>
>
> - Dan
>
>
>
>
>
> *From:* osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] *On
> Behalf Of *Brad Colbert
> *Sent:* Friday, June 01, 2018 10:20 AM
> *To:* osg-users@lists.openscenegraph.org
> *Subject:* [osg-users] Updating VBO's during runtime
>
>
>
> I'm updating my vertices at runtime. I've found a few posts that discuss
> this:
>
>
>
> (a couple are:)
>
> http://forum.openscenegraph.org/viewtopic.php?t=14826
>
> http://forum.openscenegraph.org/viewtopic.php?t=15782
>
>
>
> Let me first mention that I've compiled OSG with GL3 support, so no
> display lists. That said, I'm still calling:
>
>
>
> pointsGeom->setUseDisplayList(false);
>
> pointsGeom->setUseVertexBufferObjects(true);
>
>
>
> Here is a snippet of my call to update the vertices (v_ = vertices, c_ =
> colors, n_ = normals, da_ = DrawArrays, g_ = Geometry):
>
>
>
> for (int i = 0; i < numVertices; i++) {
>
> // Verticies
>
> v_.at(i)[0] = 500.f * (0.0f + (3.0f * float(rand() % 1000) / 1000.f)
> - 1.5f);
>
> v_.at(i)[1] = 500.f * (0.0f + (4.0f * float(rand() % 1000) / 1000.f)
> - 2.f);
>
> v_.at(i)[2] = 500.f * (1.5f + (0.1f * float(rand() % 1000) / 1000.f)
> - 0.05f);
>
>
>
> // Colors
>
> c_.at(i)[0] = 1.f;
>
> c_.at(i)[1] = 1.f;
>
> c_.at(i)[2] = 1.f;
>
> c_.at(i)[3] = 1.f;
>
>
>
> // Normals
>
> n_.at(i)[0] = 0.f;
>
> n_.at(i)[1] = 1.f;
>
> n_.at(i)[2] = 0.f;
>
> }
>
>
>
> v_.dirty();
>
> c_.dirty();
>
> n_.dirty();
>
>
>
> da_.setCount(numVertices);
>
> da_.dirty();
>
>
>
> *// *** The dirty() calls above are supposed to tell OSG to update the
> VBO's. For*
>
> *// some reason this isn't happening. We are going to force it here.
> Not sure of the*
>
> *// performance implications but hopefully this is temporary.*
>
> *g_.setVertexArray(_);*
>
> *g_.setColorArray(_);*
>
> *g_.setNormalArray(_);*
>
>
>
> g_.dirtyBound();
>
>
>
> The update just doesn't happen unless I call the *setVertexArray*,
> *setColorArray*, *setNormalArray* methods which doesn't match what the
> previous posts about this topic.
>
>
>
> Is this because of GL3 or something else?
>
>
>
> Thanks,
>
> Brad
>
> ___
> 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] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert,
Oops -- I sent this earlier today but apparently to the bounces list; that
explains the confusion on GitHub -- my mistake. This was supposedly sent right
before I posted the PR. Here's the original text:
I think I found a bug in 3.6.1. I am loading a FLT model and it's causing a
crash in my application to draw it. The same model does not crash in OSG 3.4.
I think I've finally tracked down the cause and have a candidate solution too.
A few weeks back I saw a similar crash in my own code, and figured it was due
to incorrect usage of the binding flags on osg::Array. Much of our code was
using osg::Geometry::setNormalBinding() (and related methods). During
debugging, I was able to determine my normals were crashing in 3.6, and the
problem went away when I used the osg::Array(osg::Array::Binding) signature --
i.e. assigning a binding on construction. At the time I thought it was
something I was doing wrong and moved on.
The problem showed up again earlier this week but not in my code, and not
manifesting in exactly the same way. Here's the run-down of what's going on:
- Loading FLT model
- FLT model loads a face, which has vertices, textures, and normals
- FLT uses getOrCreateNormalArray(), which allocates an array (BIND_UNDEFINED)
and sets it on the geometry
- Geometry::addVertexBufferObjectIfRequired() is called on the normals, but
nothing done due to BIND_UNDEFINED
- FLT later sets normals to BIND_PER_VERTEX appropriately, which is a direct
set and does not do anything to the Geometry's VBOs
- First frame starts to render
- Geometry::drawVAImpl calls vas->setNormalArray()
- VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(),
which returns 0. This is the first major problem.
- Because vbo is NULL, unbindindVertexBufferObject() is called, leading to
GL_ARRAY_BUFFER to go to 0
- vad->enable_and_dispatch() gets called and does glVertexAttribPointer() with
a non-NULL data ptr, which is a GL error because array buffer is 0
Unwinding the error:
- enable_and_dispatch() shouldn't be called if ptr is non-NULL and no
GL_ARRAY_BUFFER is 0
- GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the normal
array
- There is no normal array because the only place it seems to be created is in
setNormalArray(), which fails because at that time, it is BIND_UNDEFINED
- Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after
setNormalArray(), leading to the error
There are several possible solutions I can see. You can probably see more:
1) Change FLT plugin to assign array binding per vertex on construction of
array. Seems poor because invariably this bug is crashing other code -- maybe
it's the cause of the DXF that Brian Hutchison reported earlier this week?
2) Update Array::setBinding() to create the VBO if needed. I do not know if
this is possible nor how to do it.
3) "Lazily" detect this issue somewhere in the rendering calls and create VBO
there if necessary
PR 554 was an attempt at approach #3 but I agree with your assessment on
GitHub. It does not solve the problem in all cases.
Attached is a demo of the problem that generates a console warning. More
complex scenes can cause crashes. The red triangle has the problem, but the
green one does not.
- Dan
cmake_minimum_required(VERSION 2.6)
SET(PROJECT_NAME arraybug)
PROJECT(${PROJECT_NAME})
FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgViewer)
FIND_PACKAGE(osgText)
SET(SOURCES
main.cpp
)
INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})
LINK_DIRECTORIES(${OSG_LIB_DIR})
ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})
TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${OSG_LIBRARIES} ${OSGVIEWER_LIBRARIES}
${OSGUTIL_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGGA_LIBRARIES} ${OSGTEXT_LIBRARIES}
${OPENTHREADS_LIBRARIES})
#include
#include
#include
#include
osg::Node* createTriangle(float x, bool earlyBinding, const osg::Vec4f& color)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);
osg::Vec3Array* vertices = new osg::Vec3Array();
vertices->push_back(osg::Vec3(x - 100, 0, -100));
vertices->push_back(osg::Vec3(x, 0, 100));
vertices->push_back(osg::Vec3(x, 0, -100));
osg::Vec3Array* normals = new osg::Vec3Array;
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
if (earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);
osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_OVERALL);
colors->push_back(color);
geom->addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLES, 0, 3));
geom->setVertexArray(vertices);
geom->setNormalArray(normals);
geom->setColorArray(colors);
geode->addDrawable(geom);
// Warning
Re: [osg-users] Large number of occluder nodes
We do have a city scene at ground levels with lots of cars, pedestrian, construction zone clutter. The cars tend to be the worst as they can have up to 8 transparent object each from them. Large parking lots can have 500+ vehicles. OK so it sounds like what we need to do is to try to combine occluder nodes the best we can. These were generated via a script and placed in the center of each building...we just have lots of building with alleys between them. It also sounds like we will need to come up with some sort of paging/LOD scheme ourselves to remove nodes more than say 2500m from the camera. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73909#73909 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Updating VBO's during runtime
Hi Brad,
Check to make sure your Geometry has setDataVariance(osg::Object::DYNAMIC).
That solved the problem for most of our similar cases.
- Dan
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf
Of Brad Colbert
Sent: Friday, June 01, 2018 10:20 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Updating VBO's during runtime
I'm updating my vertices at runtime. I've found a few posts that discuss this:
(a couple are:)
http://forum.openscenegraph.org/viewtopic.php?t=14826
http://forum.openscenegraph.org/viewtopic.php?t=15782
Let me first mention that I've compiled OSG with GL3 support, so no display
lists. That said, I'm still calling:
pointsGeom->setUseDisplayList(false);
pointsGeom->setUseVertexBufferObjects(true);
Here is a snippet of my call to update the vertices (v_ = vertices, c_ =
colors, n_ = normals, da_ = DrawArrays, g_ = Geometry):
for (int i = 0; i < numVertices; i++) {
// Verticies
v_.at(i)[0] = 500.f * (0.0f + (3.0f * float(rand() % 1000) / 1000.f) -
1.5f);
v_.at(i)[1] = 500.f * (0.0f + (4.0f * float(rand() % 1000) / 1000.f) -
2.f);
v_.at(i)[2] = 500.f * (1.5f + (0.1f * float(rand() % 1000) / 1000.f) -
0.05f);
// Colors
c_.at(i)[0] = 1.f;
c_.at(i)[1] = 1.f;
c_.at(i)[2] = 1.f;
c_.at(i)[3] = 1.f;
// Normals
n_.at(i)[0] = 0.f;
n_.at(i)[1] = 1.f;
n_.at(i)[2] = 0.f;
}
v_.dirty();
c_.dirty();
n_.dirty();
da_.setCount(numVertices);
da_.dirty();
// *** The dirty() calls above are supposed to tell OSG to update the
VBO's. For
// some reason this isn't happening. We are going to force it here. Not
sure of the
// performance implications but hopefully this is temporary.
g_.setVertexArray(_);
g_.setColorArray(_);
g_.setNormalArray(_);
g_.dirtyBound();
The update just doesn't happen unless I call the setVertexArray, setColorArray,
setNormalArray methods which doesn't match what the previous posts about this
topic.
Is this because of GL3 or something else?
Thanks,
Brad
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Updating VBO's during runtime
Hi Brad,
In principle calling array->dirty(); should be enough to get the data
to update, though the underlying code has seen a lot of changes
between 3.4 and 3.6. Which version of the OSG are you using?
When setting up the arrays you need either specify the binding on the
osg::Array, or pass the binding in with the set*Array(array, binding)
call.
If the problem presists when using OSG-3.6.1 could you create a
compilable example program so we can test it and see the problem first
hand, if there is bug in the OSG we'll need to track it down and fix
it, if it's a problem in your code then we'll also be able to spot
this and recommend how you can do things better.
Cheers,
Robert.
On 1 June 2018 at 15:20, Brad Colbert wrote:
> I'm updating my vertices at runtime. I've found a few posts that discuss
> this:
>
> (a couple are:)
> http://forum.openscenegraph.org/viewtopic.php?t=14826
> http://forum.openscenegraph.org/viewtopic.php?t=15782
>
> Let me first mention that I've compiled OSG with GL3 support, so no display
> lists. That said, I'm still calling:
>
> pointsGeom->setUseDisplayList(false);
> pointsGeom->setUseVertexBufferObjects(true);
>
> Here is a snippet of my call to update the vertices (v_ = vertices, c_ =
> colors, n_ = normals, da_ = DrawArrays, g_ = Geometry):
>
> for (int i = 0; i < numVertices; i++) {
> // Verticies
> v_.at(i)[0] = 500.f * (0.0f + (3.0f * float(rand() % 1000) / 1000.f) -
> 1.5f);
> v_.at(i)[1] = 500.f * (0.0f + (4.0f * float(rand() % 1000) / 1000.f) -
> 2.f);
> v_.at(i)[2] = 500.f * (1.5f + (0.1f * float(rand() % 1000) / 1000.f) -
> 0.05f);
>
> // Colors
> c_.at(i)[0] = 1.f;
> c_.at(i)[1] = 1.f;
> c_.at(i)[2] = 1.f;
> c_.at(i)[3] = 1.f;
>
> // Normals
> n_.at(i)[0] = 0.f;
> n_.at(i)[1] = 1.f;
> n_.at(i)[2] = 0.f;
> }
>
> v_.dirty();
> c_.dirty();
> n_.dirty();
>
> da_.setCount(numVertices);
> da_.dirty();
>
> // *** The dirty() calls above are supposed to tell OSG to update the
> VBO's. For
> // some reason this isn't happening. We are going to force it here.
> Not sure of the
> // performance implications but hopefully this is temporary.
> g_.setVertexArray(_);
> g_.setColorArray(_);
> g_.setNormalArray(_);
>
> g_.dirtyBound();
>
> The update just doesn't happen unless I call the setVertexArray,
> setColorArray, setNormalArray methods which doesn't match what the previous
> posts about this topic.
>
> Is this because of GL3 or something else?
>
> Thanks,
> Brad
>
> ___
> 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] Updating VBO's during runtime
I'm updating my vertices at runtime. I've found a few posts that discuss
this:
(a couple are:)
http://forum.openscenegraph.org/viewtopic.php?t=14826
http://forum.openscenegraph.org/viewtopic.php?t=15782
Let me first mention that I've compiled OSG with GL3 support, so no display
lists. That said, I'm still calling:
pointsGeom->setUseDisplayList(false);
pointsGeom->setUseVertexBufferObjects(true);
Here is a snippet of my call to update the vertices (v_ = vertices, c_ =
colors, n_ = normals, da_ = DrawArrays, g_ = Geometry):
for (int i = 0; i < numVertices; i++) {
// Verticies
v_.at(i)[0] = 500.f * (0.0f + (3.0f * float(rand() % 1000) / 1000.f)
- 1.5f);
v_.at(i)[1] = 500.f * (0.0f + (4.0f * float(rand() % 1000) / 1000.f)
- 2.f);
v_.at(i)[2] = 500.f * (1.5f + (0.1f * float(rand() % 1000) / 1000.f)
- 0.05f);
// Colors
c_.at(i)[0] = 1.f;
c_.at(i)[1] = 1.f;
c_.at(i)[2] = 1.f;
c_.at(i)[3] = 1.f;
// Normals
n_.at(i)[0] = 0.f;
n_.at(i)[1] = 1.f;
n_.at(i)[2] = 0.f;
}
v_.dirty();
c_.dirty();
n_.dirty();
da_.setCount(numVertices);
da_.dirty();
*// *** The dirty() calls above are supposed to tell OSG to update the
VBO's. For*
*// some reason this isn't happening. We are going to force it here.
Not sure of the*
*// performance implications but hopefully this is temporary.*
*g_.setVertexArray(_);*
*g_.setColorArray(_);*
*g_.setNormalArray(_);*
g_.dirtyBound();
The update just doesn't happen unless I call the *setVertexArray*,
*setColorArray*, *setNormalArray* methods which doesn't match what the
previous posts about this topic.
Is this because of GL3 or something else?
Thanks,
Brad
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ANGLE/UWP support checked into OSG github
Hi All, I have created a branch off OSG master for merging ANGLE/UWP support that has been provided my members of the OSG community. The branch is: https://github.com/openscenegraph/OpenSceneGraph/tree/donvito-illogic-osg-illogic-github If you want to see what changes were required the commit of the PR is: https://github.com/openscenegraph/OpenSceneGraph/commit/a60cd972f62818d63d2198eec7dcf10fe7909d18 I am not a Windows user myself so can't test out personally, it would be useful interested Windows users could try out the branch and if everything works well we can merge it with OSG master. Let us know how you get on in this thread. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Where can i find the windows binaries
Hi, Stuart. I found a typo at your OSG page: > The default OpenQL GL2 level was used You probably wanted to say 'OpenGL' instead of 'OpenQL' ;) On 1 June 2018 at 05:33, Stuart Mentzer wrote: > Hi Peter, > > My company, Objexx (http://objexx.com), is providing Windows binaries at this > page: http://objexx.com/OpenSceneGraph.html. > > We have 3.4.0 and 3.4.1 and we'll be doing 3.6.1 with Qt 5.11 soon. If you > have special requirements or you need 3.6.1 ASAP let me know. > > Cheers, > Stuart > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=73905#73905 > > > > > > ___ > 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
