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 ------------------------------------------------------------------------------ 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
