Hello Johannes,
On 02/29/2012 06:19 AM, Johannes Brunen wrote:
> I would like to ask for some clarification about the management of
> shaders in a multiple window environment.
>
> In my application, I have the following setup, and I'm unsure if this is
> the right way to do it. Additionally, I'm facing problems...
>
> I have multiple windows which renders OpenSG scenes (handled by scene
> managers one for each scene). In each scene manager, I have created a
> ShaderProgramChunk for my silhouettes rendering task, which is shared by
> all concerned materials in the scene. Additionally, some windows can
> also render the same scene with the same ShaderProgramChunk.
>
> Is this a valid setup? I.e. is it allowed to share ShaderProgramChunks
> between multiple materials and to share one scene graph containing such
> materials between different windows (i.e. OpenGL contexts)?
it does sound reasonable to me and my expectation would be that this is
doable.
This may be related to the other problem with Shaders you have run into.
One way to exclude the ShaderCache as problem source would be if you
recompile OpenSG with the cmake variable OSG_SHADER_CACHE_MODE set to 0
(default is 5). It will then use a trivial (but slow) implementation.
> I have then tested the following. Just before redraw I added the
> following to my code:
>
> ShaderProgramChunk* shl =
> view->getSceneManager()->getSilhouetteShaderChunk();
> ShaderProgram* vertShader = shl->getVertexShader(0);
> ShaderProgram* geomShader = shl->getGeometryShader(0);
> ShaderProgram* fragShader = shl->getFragmentShader(0);
> if (_win->getGLObjectId(vertShader->getGLId()) == 0)
> int test = 2354;
> if (_win->getGLObjectId(geomShader->getGLId()) == 0)
> int test = 2354;
> if (_win->getGLObjectId(fragShader->getGLId()) == 0)
> int test = 2354;
If this code is before _win->render(_action) it may not necessarily
indicate a problem. When modifying shaders the underlying OpenGL object
is only marked as dirty and updated as part of the rendering (when we
are sure to have an active OpenGL context).
_win->validateGLObject(shader->getGLId(), pDrawEnv) triggers the update
(in this case recompile) of the OpenGL resource if necessary.
> After that, I have added a validateAllGLObjects() call. But that leads
> to a program crash with the call stack shown below
>
>> OSGSystemD.dll!OSG::ShaderExecutableChunkBase::getGLId() Line
> 182 + 0x11 bytes C++
> OSGSystemD.dll!OSG::ShaderExecutableChunk::handleGL(OSG::DrawEnv
> * pEnv=0x0000000014365920, unsigned int id=413,
> OSG::Window::GLObjectStatusE mode=needrefresh, unsigned int uiOptions=0)
> Line 212 + 0xd bytes C++
hmm, looks almost as if the ShaderExecutableChunk has been deleted; I
don't see how it could crash on getGLId() otherwise...
> So, I suspect, that I do something fundamentally wrong here and hope to
> get some insight into a proper handling of my application scenario.
>
> After destroying of my dialog window, should the ShaderProgramChunk
> contained in my main scene and hold by my main SceneManager be valid and
> functioning?
Yes, it's my understanding that shaders should basically behave like
textures here: we (re)create them on any OpenGL context that uses them.
From your descriptions I don't see anything obviously wrong in the way
your application uses shaders.
Cheers,
Carsten
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
