Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight
Hi Robert, Thank you for your reply,it is a tricky way to use 'vao' in 'RenderLeaf'. > Furthermore, the strongest affinity that VAO's have is with vertex arrays and > vertex buffer objects, which in the OSG's case are tied to osg::Geometry. I think it is a little rigid,there may be the situation that we use 'vbo' out of the Geometry,for example,'arrays' of 'status information'(maybe we can use 'uniform',but I think more choices could be better,then we can do a lot of expansion),or user's custom data which is not suitable in Geometry. In order to increase its expansibility,I'd like to add an extension layer above Geometry(Drawable).'RenderLeaf' act as the role in my previous work,of course I extended many classes and changed their usage to support my work. Many of my ideas and my words may be wrong or lack of consideration,so I hope you can point out my mistakes. I would be very happy to contribute my strength to osg. ... Thank you! Cheers, wang -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68411#68411 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShapeDrawable refactored, now subclasses from osg::Geometry
Hi All, As part of the Vertex Array Object support work that I have been doing on the git vertex_array_object branch I have tackled a long time issue with ShapeDrawable. I have refactored ShapeDrawable so that it now subclasses from osg::Geometry and builds all the vertex, normal, texcoord and color arrays and primitives that are required to render the attached osg::Shape. This means fast paths are all used for the first with ShapeDrawable. To do the building of the required vertex array and primitive sets I have created an osg::BuildShapeGeometryVisitor that can now be found in the include/osg/Shape header. The ShapeDrawable uses this visitor to do it's work. This visitor is a ShapeVisitor rather than a NodeVisitor, so it's something you give to a shape to visitor i.e. osg::ref_ptr geometry = new osg::Geometry; osg::BuildShapeGeometryVisitor dsv(geometry, tessellationHints); shape->accept(dsv); This fills in the geometry so it can then be attached to the scene graph and render, intersected etc. The visitor can be run on multiple Shape objects passing once it's initialized with it's geometry pointer so can place multiple Shape's into a single geometry. The ShapeDrawable also support CompositeShape so you can do the multiple shapes in a singel osg::Geometry via this route as well. The advantage with this new osg::Geometry based ShapeDrawable and BuildShapeGeometryVisitor is that nothing needs to be computed on the fly anymore so intersections and rendering are all faster. It's also fully compatible with VBO's and VAO's. So... for the first time the OSG will be able to render shape efficiently. This is all checked in the vertex_array_object branch, once this branch is stable and tested out in the community I'll merge with git master and will then be part of the up coming OSG-3.6 release. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture is ovelapped with previous instance
Hi Manish, There are too many unkowns for us 3rd parties to be able to guess what you might be doing wrong, so I can't see how others will be aim to help you with the information given so far. Perhaps the best thing to do would be to create a small example that illustrates what you are doing in a simple way such that it recreates the problem you are seeing. Then others can look at this code and spot what the mistake is. Robert. On 17 August 2016 at 12:49, manish Choudhary wrote: > Hi, > > i am using texture mapping in my application and it work fine. > But when I delete the current osg scenegraph view and then display new osg > scenegraph view, then on updating texture using callback it showing > merging/overlaaping of previous texture as well as current texture. > > Why overlapping/merging of texture occuring even though i have delete all the > previous memory reference. > > ... > > Thank you! > > Cheers, > manish > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=68404#68404 > > > > > > ___ > 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] Texture is ovelapped with previous instance
Hi, memory is release using auto garbage collection only.. and for image used USE_NEW_DELETE ... Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68408#68408 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with osgFX::Outline node
Hi All,
I found at least two problems related to osgFX::Outline.
First of all, turning off lightning on a child node then the outline seems
inheriting that option.
Here is basically the code:
Code:
void ControlPoints::insertMarker(size_t iIndex, const
viframework::vimath::Point& iPoint)
{
osg::ref_ptr transform = new osg::AutoTransform();
transform->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
transform->setAutoScaleToScreen(true);
transform->setMinimumScale(0.0);
transform->setMaximumScale(FLT_MAX);
transform->setPosition(osg::Vec3(iPoint.x(), iPoint.y(), iPoint.z()));
transform->addChild(buildFlagWithOutlineEffect(30.0));
root->addChild(transform);
viroad::viosg::SceneManager::instance().setDirty();
}
osg::Node* ControlPoints::buildFlagWithOutlineEffect(float height)
{
osgFX::Outline* outline = new osgFX::Outline;
outline->setWidth(5);
outline->setColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));
Flag* flag = new Flag(height);
//flag->getOrCreateStateSet()->setMode(GL_LIGHTING,
osg::StateAttribute::OFF);
outline->addChild(flag);
return outline;
}
In attachment you can see the different behaviour.
I would like to disable lightning on the flag but have a red outline.
About the second problem I will open a different topic.
Cheers,
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68407#68407
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight
Hi Jannik, On 17 August 2016 at 14:52, Jannik Heller wrote: > I have tested out the VAO branch on my Nvidia graphics card. As you said, > VAO+VBO is slightly faster than VBO but not as fast as display lists. Would > be curious on the performance results with AMD cards. > > Unfortunately, I am unable to use VAO for animated meshes because you've > introduced a new meaning of the dataVariance flag. > https://github.com/openscenegraph/OpenSceneGraph/blob/vertex_array_object/include/osg/Drawable#L523 I haven't introduced a new meaning to DataVariance, all I have done it utilize it for knowing whether the VAO needs updating or not. I have done this to avoid the extra checks required against the individual arrays to see if they are dirty or not - I have done it for performance reasons as I want to keep the CPU overhead for draw dispatch as low as possible. > I do *not* set the dataVariance to DYNAMIC for all my animated meshes because > the performance overhead of DYNAMIC is not acceptable for me. If Drawables > are set to DYNAMIC, OSG would not break frame until all the draws are > submitted. I manage the updates using a double buffering scheme that prevents > the buffer from being modified while the draw thread is using it. So > essentially I don't need the DYNAMIC flag, but now I'm forced to use it (and > incur the performance overhead associated with it) because OSG won't update > the arrays if I don't. :( Previously it was sufficient to dirty() the vertex > arrays to get OSG to update things. Hopefully that can be fixed. This is a sticky one. Your mesh *is* dynamic, the correct way to label the geometry is DYNAMIC. In your usage case you are taking advantage of the fact that in certain circumstances you ignore the threading issues associated with dynamically updating whilst it's being dispatched by the drawing thread, however, this is a dangerous game to play that you have to be really careful to do without introducing a race condition. Whether you are just getting lucky in your code or it's genuinely safe I can't say as I don't have the code. In your case you are wanting a DataVariance of DYNAMIC_BUT_DRAW_TRAVERSAL_PLEASE_DONT_TREAT_ME_AS_SUCH. I guess the special case where modifying the data is safe would be STATIC_ALLOCATION_DYNAMIC_UPDATE or something along those line. Perhaps STREAM might be terminology that might fit this. However, even with the STREAM case if you are updating in the update or cull traversal while the draw thread is reading that same data you could get corrupted data sent to OpenGL driver, here you really should be double buffering. I'll ponder on this issue, but for now strictly speaking the VAO implementation is perfectly correct, requiring that the DataVariance be DYNAMIC is a correct interpretation of what the DataVariance is. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight
Hi, I have tested out the VAO branch on my Nvidia graphics card. As you said, VAO+VBO is slightly faster than VBO but not as fast as display lists. Would be curious on the performance results with AMD cards. Unfortunately, I am unable to use VAO for animated meshes because you've introduced a new meaning of the dataVariance flag. https://github.com/openscenegraph/OpenSceneGraph/blob/vertex_array_object/include/osg/Drawable#L523 I do *not* set the dataVariance to DYNAMIC for all my animated meshes because the performance overhead of DYNAMIC is not acceptable for me. If Drawables are set to DYNAMIC, OSG would not break frame until all the draws are submitted. I manage the updates using a double buffering scheme that prevents the buffer from being modified while the draw thread is using it. So essentially I don't need the DYNAMIC flag, but now I'm forced to use it (and incur the performance overhead associated with it) because OSG won't update the arrays if I don't. :( Previously it was sufficient to dirty() the vertex arrays to get OSG to update things. Hopefully that can be fixed. Cheers, Jannik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68405#68405 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture is ovelapped with previous instance
Hi, i am using texture mapping in my application and it work fine. But when I delete the current osg scenegraph view and then display new osg scenegraph view, then on updating texture using callback it showing merging/overlaaping of previous texture as well as current texture. Why overlapping/merging of texture occuring even though i have delete all the previous memory reference. ... Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68404#68404 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight
Hi Wang, The RenderLeaf is a object that is dynamically allocated and reused, it doesn't have a lifetime linked to any specific drawable let alone the vertex arrays or buffer objects objects associated with them. The RenderLeaf only exists to help the cull traversal specify what parts of the scene graph should be rendered and when, it isn't and shouldn't be directly linked to the scene graph as there is the mapping is entirely dynamic and deliberately separated from the scene graph i.e. the scene graph itself knows nothing about what RenderLeafs might reference it. Vertex array objects are very much the domain of the scene graph and have a natural affinity to the other OpenGL objects that the scene graph maintains. Furthermore, the strongest affinity that VAO's have is with vertex arrays and vertex buffer objects, which in the OSG's case are tied to osg::Geometry. this means the natural place to manage VAO's is with Drawable/Geometry. The only open question I see is whether we enable/encourage sharing of VAO's between osg::Geoemetry. For most OSG users osg::Geometry will all have their own osg::Array's for vertex arrays etc. and each of these would have their own VBO's, so in turn this would map to each Geometry having their own VAO. This implementation is supported right now in the OSG' vertex_array_object branch. All the OSG plugins that load 3rd party data create models such that each osg::Geometry has it's own vertex arrays etc, without sharing. In special cases users could create their own vertex arrays and share these between osg::Geometry, or have separate vertex arrays but share the osg::VertexBufferObject between them. I don't know how many end users do this, over the years it's not something that has been discussed much. The OSG has been written to support this sharing but how much potential benefit there might be from building your scene graphs this way I can't say as I haven't tested it. >From what I understand Julian is proposing is for those sharing vertex arrays then sharing VAO's also would be valuable. Right now my focus is on getting the vertex_array_object branch working well across the full range of OSG usage models, this is far from trivial task. The sharing of VAO's might be interesting to a small number of users so I'm open to it, but it's always going to be niche feature given how sharing of vertex arrays hasn't historically been a hot topic in the OSG community. What is really important for the OSG right now is that end users actually have a look at the vertex_array_object branch and test it out on their models. Robert. On 17 August 2016 at 05:43, wang dexing wrote: > Hi Julien, > > Thank you for your reply,I think there is no separation between user level > and system level,since the development of OpenGL also exposes more low-level > implementation. > the reason why I didn't use 'vao' in 'drawable' is that I think 'vao' is > used to manage 'vbos',but 'vbos' is not only from 'drawables' ,but also from > somwhere else,for example,'instance arrays' of 'status information' .It's > rigid to put 'vao' in 'drawable'.So I'd like to find a better place using > 'vao'.I think 'RenderLeaf' can be a good place because it has the member > '_drawable' and its parent is 'stategraph', it can be closely linked to the > two. > I know that cullvisitor isn't fit for instance culling,so I didn't change the > original structure,only calculated 'instance data' when cullvisitor traverse > 'instance node' which I signed.just as I wrote,I didn't want to give up osg's > 'cull' function,I only add some extra features when cullvisitor traversing.I > extended some classes to support it. > > Thank you! > > Cheers, > wang > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=68399#68399 > > > > > > ___ > 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] [About VertexArrayObject Branch] FeedBack and Insight
Hi Julien, Thanks for the link to the model. I've tried it on my iCore7+Geforce760 system and get 113fps with VBO, 130fps with the VAO implementation in the vertex_array_object branch. I would agree it's not a good model for testing, it doesn't have any textures, the buildings are unrealistic in layout, nothing close to what a real city looks like. I haven't looked at how the scene graph is structured so can't comment on how well it's structured. Unfortunately I can't shared the city models. As a general note, the final VAO implementations has to work well across a wide range of usage models, ideally work better in all situations. So far the vertex_array_object branch looks to be better than using VBO for all the models I've tried, but how much different depends upon the model, the more separate geometries there are the greater the advantage that the VAO has. Have you tested the vertex_array_object branch implementation on your models? Robert. On 16 August 2016 at 23:53, Julien Valentin wrote: > I wanted to give us a common test scene so I seek on blendswap an found > bigcity by chriddi1 I converted to ive > https://drive.google.com/file/d/0BxIH-jcsgYDdTG5ha21HZE1jX1E/view?usp=sharing > > However benchmarks I've done with this scene doesn't exhibit the same gaps in > performance I had with my other scene :( > I only noticed few gain in draw stage with my differents scenarii: > Shared BOs no VAO:8 > Shared BOs 1VAO/Geom:10 > Shared BOs Shared VAOs:6 > All runs at 90 FPS on my GTX640:/ > Perhaps this scene is not fitted for this test...My guess is it's because it > has been excessively fragmented (too much small geoms)..A scene with a wider > variety of index sizes would be a far better test subject... > > So sad I can't share the copyrighted scene there's a lot of large building > with variety of shapes (and so index sizes).. > > > > mp3butcher wrote: >> Hi Robert >> I would rather you to give the test scene for benchmark, mine is >> not-by-me-copyrighted >> An you're right in my VAO system I have to force reaffectation of >> bufferobjects when useVertexArrays is set (in order to be drawable without >> basevertex drawcall) to false and doing so i discard user bos, and this is a >> bad... >> however if I'd force the use of basevertex draw call in all cases It >> wouldn't be necessary >> >> >> > adding an extra layer of complexity is something that most users would >> > really struggle with. >> > >> >> I don't understand what you refer to with this sentence...my only user >> interface is the usevertexArrayObject flag..?! user don't have to know about >> underlying stuff as the bo affectation pattern is the only fitting osg (no >> interleaved case) >> >> >> >> robertosfield wrote: >> > Hi Julien, >> > >> > On 16 August 2016 at 18:37, Julien Valentin <> wrote: >> > >> > > Hello all >> > > @scraw : geometries doesn't have to share vertex arrays but >> > > bufferobjects..this is not the same: >> > > The pattern that maximize vao reutilization is the followed >> > > Geom1 >> > > G1VertAttrib1->BO1 G1VertAttrib2->BO2...and a Unique IndexArray->BON >> > > Geom2 >> > > G2VertAttrib1->BO1 G2VertAttrib2->BO2...and a Unique IndexArray->BON >> > > >> > > With this pattern and vao sharing I have not only draw stage drop but >> > > also a huge gpu charge decrease >> > > The only problem is that you should use glDrawXXBaseVertex or >> > > offsetIndices of your IndexArray >> > > >> > > My bench in release this time >> > > .. Cull >> > > DrawGPU FPS >> > > Pattern on all geometries with 1VAO/Geom 24 >> > > 1.37160 >> > > Pattern on all geometries with shared VAOs 22 >> > > 0.47200 >> > > >> > > So I think there's interest in sharing vaos >> > > >> > >> > If you have a usage case please create an example that we can share >> > and use when benchmarking. >> > >> > FYI, The VertexArrayState class that wraps up vertex array dispatch >> > and vertex array objects when enabled is capable of enabling sharing >> > between osg::Drawable. In fact it's possible to share a single >> > VertexArrayState between the whole scene graph just relying upon the >> > VertexArrayState object in osg::State. When VAO is not enabled >> > osg::State maintains a single VertexArrayState object that handles all >> > the vertex array dispatch. >> > >> > Currently I haven't exposed the local osg::Drawable VertexArrayState >> > object as publicly accessing able in osg::Drawable but this could be >> > done easily. I'm not yet convinced that this is good idea and don't >> > yet know of the consequence that might unfold. >> > >> > Please remember the VAO system has to work well with the non VAO >> > usage, performance overheads have to be kept to a minimum and the >> > usage for end users has to be kept simple, adding an extra layer of >> > complexity is something that m
Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)
HI James, On 17 August 2016 at 10:16, James Turner wrote: >> Would this change not modify the ABI? > > Yes, it would - I didn’t realise ABI compatibility was a goal of the stable > branches. If we can maintain the ABI through stable branches then this is what I aim to do. We can't always maintain it as bug fixes sometimes require fixes to member/methods that break the ABI. I'm working to get OSG-3.6 out as soon as I can so hopefully this can wrap up the fix for end users. The only major feature I have left to nail down for 3.6 is VAO support. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Potential fix for osgDB MSVC linkage issues (FORCE:MULTIPLE needed)
> On 16 Aug 2016, at 13:26, Robert Osfield wrote: > > Would this change not modify the ABI? Yes, it would - I didn’t realise ABI compatibility was a goal of the stable branches. Kind regards, James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
