Hello Carsten,
the problem is solved but actually I'm not sure why. glCreateProgram was called twice by OSGSimpleSHLChunk::handleGL. Seems that the uiProgram value that handleGL() retrieves from pWin was no ok.
I solved it by calling frameInit() and frameExit() around renderAllViewports(). In that case I did not call render() as I do not what the window to swap() as I have the FBO as target.
Can you tell me what frameInit() is doing?
Thanks,
Michael
Gesendet: Mittwoch, 08. Oktober 2014 um 16:59 Uhr
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] FBO cleanup
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] FBO cleanup
Hello Michael,
On 10/07/2014 05:10 PM, Michael Raab wrote:
> Am 07.10.2014 16:39 schrieb Carsten Neumann <carsten.p.neum...@gmail.com>:
>>> In the usual scene rendering the timed shader behavior stops until the
>>> video capturing gets stopped. I checked with gDebugger and in case of
>>> capturing the video the GLContext receives a copy of the initial shading
>>> program and the variable update seems to affect only this.
>>
>> Hmm, here I'm not sure I can follow: my understanding was that your
>> setup now only has one GL context (Window) that is used for both
>> rendering to the FBO as well as the regular back buffer and so there
>> should only be one instance of the shader program? Do you think you can
>> track down where that copy comes from, because I have a feeling that
>> there should not be a copy in the first place - that way there would
>> also not be any confusion which program's uniform value gets updated.
>>
>
> Yes there is one context and the shader program instance should be there once. Actually I have no clue where and why it is constructed. Do have an idea where to start looking for it?
hmm, not sure if it's helpful, but there is essentially just one place
that calls glCreateProgram: OSGShaderExecutableChunk.cpp:260, so that
may be a starting point?
Cheers,
Carsten
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
On 10/07/2014 05:10 PM, Michael Raab wrote:
> Am 07.10.2014 16:39 schrieb Carsten Neumann <carsten.p.neum...@gmail.com>:
>>> In the usual scene rendering the timed shader behavior stops until the
>>> video capturing gets stopped. I checked with gDebugger and in case of
>>> capturing the video the GLContext receives a copy of the initial shading
>>> program and the variable update seems to affect only this.
>>
>> Hmm, here I'm not sure I can follow: my understanding was that your
>> setup now only has one GL context (Window) that is used for both
>> rendering to the FBO as well as the regular back buffer and so there
>> should only be one instance of the shader program? Do you think you can
>> track down where that copy comes from, because I have a feeling that
>> there should not be a copy in the first place - that way there would
>> also not be any confusion which program's uniform value gets updated.
>>
>
> Yes there is one context and the shader program instance should be there once. Actually I have no clue where and why it is constructed. Do have an idea where to start looking for it?
hmm, not sure if it's helpful, but there is essentially just one place
that calls glCreateProgram: OSGShaderExecutableChunk.cpp:260, so that
may be a starting point?
Cheers,
Carsten
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
