Hello Gerrit,
Gerrit Voß wrote:
> On Tue, 2010-01-12 at 19:52 -0600, Carsten Neumann wrote:
>> - the attached patch fixes a small oversight where we activate a program
>> without updating the draw env. This can result in the SEVarChunk to look
>> up uniforms in the wrong program.
>
> hmm, in general it shouldn't be a problem, only if one calls
> validateGLObject manually. But in this case there is always a way
> to get it wrong. Anyway I applied your patch to the trunk.
maybe it was an interesting interaction with the typo you mention below...
>> - part of the problem seems to be that the cache does not add a
>> destroyed functor to SPVarChunk, so when it dies the entries in the
>> cache are not evicted.
>
> yes, there was a typo, it should have been ifndef instead of ifdef.
> I fixed that one. Now I get the same gun everytime I switch through,
> and I checked as the var chunks is properly destroyed glGetUniform
> is now called correctly because a new VarChunk is found every time.
ok, thanks a lot for tracking this down. I'll merge the change into my
branch and try it.
> Somehow the geometry is not correct, not sure if it should be ?
try hitting 'l' (lower case 'L') to have an animation play, without that
the skeleton is in a more or less undefined pose. With that the only
geometry problem should be at the helmet - there are some
flipped/missing triangles.
>> Defining OSG_SHC_REF_CLEANUP helps a bit, but
>> produces many warnings from Window::validateGLObject:
>> WARNING: Window::validateGLObject: obj with id XXX is NULL! or
>> WARNING: Window::validateGLObject: id is 0!
>>
>> Do you have any info on the status of the code, e.g. what would be the
>> preferred values for the three defines at the top of OSGShaderCache.h
>> (OSG_SHC_USE_REF, OSG_SHC_REF_CLEANUP, OSG_ASSERT_TREE)?
>
> These are really only debug, test and validation defines. They should
> all be off.
ok.
>> I'm not sure I understand how one SEVarChunk can reliably be used with
>> more than one SEChunk, since the uniform locations seem to be stored in
>> the former, but can be different for different SEChunks?
>
> It never could, that followed 1.x which stored the chunk to which the
> variables reference explicitly. I have a look how it could be extended.
> I have to check what happens if the shader it recompiled anyway.
I guess it would only provide a performance advantage when used with
named uniform blocks in 3.2, but it is sometimes quite convenient to use
the same set of uniforms with a bunch of shaders.
> Something else I looked into, the exit crashes of your test program.
> One I could fix, one is still left and needs a little more time. But
> this one could be avoided by destroying the mgr object last instead of
> second.
yeah, I had not looked into those since they seemed to be related to
SEVarChunks in the cache not being cleaned up correctly, at least that
was were I stopped looking further ;)
Thanks,
Carsten
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
