[osg-users] [About VertexArrayObject Branch] FeedBack and Insight

Julien Valentin julienvalentin51 at gmail.com
Sat Sep 3 07:09:27 PDT 2016


Hi Robert,
I think I understand what Jannik wanna means:
Dynamic meshes doesn't require the vao to be "recompiled" on arrays changes. The only case when vao have to be redefined/"recompiled" is when vas change (in case of arrays adding/removing)
So the datavariance of arrays is DYNAMIC but in order not to force the vao to be redifined at each frame (and the loossing all advantages of using vao) ones should set datavariance of the geometry to STATIC.
So it leads to datavariance semantic violation...

What I think of is making VAS a component of Drawable with that kind of code:
class VAS : Object {
void setVertexArray(Array);
void setNormalArray(Array);
protected:
mutable bufferred_object<PCVAS> percontextVAS;
}

With this kind of stuff ones could control the data variance of the VAS itself and not the drawable:
For the case of dynamic meshes:
-geometry and arrays dattavariance would be DYNAMIC 
-but geometry vas datavariance would be STATIC
(Further it would allow to share VAO  between Drawables at compile time)
...and everyone would be happy...No?

I'm currently trying to implement it but I would rather have your opinion first (to avoid coding for nothing)

Cheers


robertosfield wrote:
> 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
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  ------------------
> Post generated by Mail2Forum


------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68509#68509








More information about the osg-users mailing list