Hello Carsten and Gerrit,
I'm really happy to hear from you again :-)
Allow me to answer all the questions and remarks in this answer.
> - For OSGComputeShaderAlgorithm is it possible to combine the
> useMemoryBarrier and memoryBarrier fields, i.e. if memoryBarrier
> is GL_NONE that means no memory barrier? That would allow
> controlling the barrier with a single field instead of requiring
> the setting of two.
Hmm, I don't think so. GL_NONE is not a valid (better listed of allowed)
parameters to the glMemoryBarrier API. I wouldn't try this.
> - Can you imagine a situation where a barrier is needed/useful
> before the compute shader? If so, should we have
> preMemoryBarrier/postMemoryBarrier fields instead?
I can't come up with a good scenario. Maybe if you would like to do some
post processing of the buffer/image written by the fragment shader. I
would wait until someone has a real need for that.
> - In OSGGeo{Integral/Vector}BufferRefProperty you add getOpenGLId
> helper functions, but then they appear to not be used. Did I
> miss something?
Let me explain how I came up with this modification first.
I was writing example 'computeshader5.cpp' and have had the need to
transport data from the compute shader to the fragment shader. In the
compute shader I can modify either a shader storage buffer object or a
texture image.
In this particular example, however, I have the need to use the written
data from the compute shader in form of an array buffer in order to use
them as input data into the vertex/fragment pipeline. I did see two
possibilities for that scenario. Either setup a geo property and tell
the compute shader that this buffer is basically a shader storage buffer
object or the other way around, that is, to setup a shader storage
buffer object and to tell the pipeline shaders that it is basically an
array buffer.
Firstly, I did go with the second approach and I was positively
surprised to find the GeoVectorBufferRefProperty that seemed to be
invented for my scenario. That is, setup the shader storage buffer
object and to provide the GL id to the GeoVectorBufferRefProperty
object. Then I discovered that the Id provided to the property interface
is taken directly instead of going the route over the
pWin->getGLObjectId(getGLId()). At this point I thought that this is
probably an implementation error or that it is simply not finished yet.
So I changed it and went on with the example. It worked well this way.
Then I thought about the first approach, that is to setup the geo
property in the first place and to reference that buffer as a shader
storage buffer object. So I wrote the ShaderStorageBufferObjRefChunk and
adapted the example accordingly. That also worked well and I leaved it
in this final state.
> small comment, the *Ref* classes are meant to refer to/reference
> OpenSG external OpenGL objects, so validating them through OpenSG
> and translating them to an OpenSG managed OpenGL Id is not the
> intended behavior.
So I misinterpreted the idea of these guys. My scenario is referencing
within OpenSG.
> I'll revert that part right away. If Johannes has a
> scenario where the previous behavior is not doing the right thing
> we can figure out a correct change with more calm.
As the example currently works not with the GeoVectorBufferRefProperty
but with the ShaderStorageBufferObjRefChunk the revert is not hurting.
But I think that the scenario that I describe above is a valid and
important one. So we should support it. Additionally, now we have a
semantically interface break between the 'Ref' classes. We should find a
solution that supports both scenarios equally.
> There is one example actually using 2 ids, OSGTextureObjRefChunk.
I do not know this one and have to look it up.
> This one has a oglGlId and an osgGlId if the OSG id is set the
> normal OSG validation/mapping is done. If the oglGlId is set
> only the GL calls are made. If both are set, the OpenSG id wins
>
> If there is a need to reference OpenSG internal properties this
> might be the way to go.
This sounds promising. But I we would transfer that into the geo
property ref classes we would still break backward compatibility because
of API naming.
It is good that you have still interest in OpenSG. I have worked a lot
recently on OpenSG. The last thing that I have finished is to write an
ClusterShading example in the line of:
Ola Olsson, Markus Billeter, and Ulf Assarsson
High Performance Graphics (2012), pp. 1–10
C. Dachsbacher, J. Munkberg, and J. Pantaleoni (Editors)
http://efficientshading.com/wp-content/uploads/clustered_shading_preprint.pdf
http://efficientshading.com/2013/08/01/practical-clustered-deferred-and-forward-shading/
This example works quite well and I will send it to the list in the near
future. I have to do some polishing to get it upload ready. The next
step that I plan is to write a Stage class that wraps the implementation
of this example so that the user only has to add this stage to its scene
in order to take credit from the clustered light arrangement in the
fragment shader in a simple way.
What I have learned with this example is that you can do modern OpenGL
with OpenSG quite well.
So please stay tuned,
Best,
Johannes
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
