From: Gerrit V. <vo...@vo...> - 2010-01-17 03:18:58
|
Hi, On Sat, 2010-01-16 at 10:10 -0600, Carsten Neumann wrote: > Hello Gerrit, > > Gerrit Voß wrote: > > On Tue, 2010-01-12 at 19:52 -0600, Carsten Neumann wrote: > > > >> - 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. ah ok, with 'l' it looks better ;) > >> 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. yes, the whole new handling of passing uniforms/data to shaders is something on my list to look at. > > 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 ;) it was related but not the same. There was a bug in the tree destruction. The last one left is a counting issue which just needs a little time/work to resolve. kind regards gerrit |