Hi Gerrit,

Gerrit Voss wrote:
> On Tue, 2009-02-10 at 19:05 -0600, Carsten Neumann wrote: 
>>      Hi Gerrit,
>>
>> if I pass the state from a ChunkMaterial with a ShaderProgramChunk to 
>> DrawEnv::activateState, it does not seem to enable the shader (bugle 
>> shows no shader compilation etc. happening).
>> The problem seems to be that RenderPartition::dropFunctor is (partially) 
>> in charge of handling the transition from the front end representation 
>> (ShaderProgramChunk) to the back end representation 
>> (ShaderExecutableChunk) which makes it hard to obtain translated state 
>> for use in e.g. a Stage with mode SimpleCallback [1].
>  
> 
> yes. That was the low level interface part I mentioned earlier in
> the OpenGL 3 thread ;-)

ah, ok ;)

>> I worked around it by just creating a normal partition and using 
>> RenderPartition::dropFunctor, but it looks a bit as if SimpleCallback 
>> partitions are second class citizens?
>  
> Kind of in a sense that they are currently not supporting shader
> composition. All OpenSG internal usage is falling back on using
> a SimpleSHLChunk for this case (e.g. the HDR stage), that's the main
> reason this one is still there. As there wasn't any usage that needed
> the full composition immediately it slipped back a little on my to do
> list. 
> 
> How urgent would you need the composition or would your example work 
> with using SimpleSHLChunks ? If urgent I can take what I have and see if
> I can finalize it quickly.

don't worry about it, if you are going to work on it anyways there is no 
need to rush this in. The workaround with a regular stage works fine.

>> One other implication of the way shaders are handled ATM is that 
>> ShaderProgramChunk behaves different from any other chunk when used in a 
>> ChunkOverrideGroup (COG). Consider:
>>
>>   COG Shader A, with function foo()
>>    |
>>   COG Shader B, with function main()
>>    |
>>    +-----------------------------------------+
>>    |                                         |
>> Geo1                          COG Shader C, with func main()
>>                                              |
>>                                             Geo2
>>
>> Geo1 will render fine using shader B (which may call foo from main), for 
>> Geo2 I'd expect a link error because there are two main functions.
>> Under normal COG semantics Geo1 should fail, because shader A gets 
>> hidden (not what one wants, but consistent) and Geo2 should be fine 
>> rendering just with shader C.
>> I know you said at one point something about adding useful override 
>> semantics, so I suspect this is not the final state of things?
>  
> 
> corect, the override semantics is right now in the making. I hope to
> have it finished before heading of to IEEE VR in March.

nice :)

        Thanks,
                Carsten


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core

Reply via email to