Hi, On Wed, 2010-01-27 at 18:42 -0600, Carsten Neumann wrote: > Hello Gerrit, > > Gerrit Voß wrote: > > On Sat, 2010-01-16 at 10:10 -0600, Carsten Neumann wrote: > >> Gerrit Voß wrote: > >>>> 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. > > ok, it's just something one has to be aware of, as the SVarChunk seems > to suggest that it can be shared across materials with different > SProgChunks, which it can not - it must be the same SProgChunk on all > materials.
yes it was the other way round ;) > >>> I have a look how it could be extended. > >>> I have to check what happens if the shader it recompiled anyway. > > hm, reading the extension spec for GL_ARB_uniform_buffer_object and > thinking about this a bit more, it seem that it is in line with what one > can do in OpenGL that the SVarChunk can only be used with *one* > SProgChunk - we'd have to track a uniform's locations in multiple programs. > The spec seems to suggest that the preferred way to share uniform data > across multiple shaders is to use a named uniform block. > > Anyway, given the 'limitations' of the SVarChunk I now have a bit of > trouble seeing what it is good for, i.e. when would it make sense to use > one instead of keeping the variables directly on the SProgChunk? hmm if you want to have the same shader with different variable values, e.g. you have some fancy shader and want to color some objects red and some green. If you have hundreds of these you don't want to create a new shader object for each instance but reuse the same shader object with different variable values (ok for those that don't come down through OpenGL). > Ah, we can not have variables on the SProgChunk only on the > ShaderProgram objects, why is that? > > Would it make more sense to allow variables on SProgChunk (and SProgram) ?? I kept the variables with the individual programs, e.g. ShaderProgram contains a variable store and the interface to set/get uniform variables. So you collect them with the program and not with the chunk. They are merged as the programs are merged. Argg I still have to fix the override strategies that might also be the reason why they aren't in the chunk. > and not have SVarChunk? I still see the use of it. > At least that would avoid the pitfall of attempting to share SVarChunks. Yes, the problem is that in 1.x it was clear due to the direct ShaderChunk reference inside SVarChunk. As an optimization I took this out (1.x tended to activated the shader twice IIRC) this connection is less clear. Let me see if I can change things so that the SVarChunk works in both scenarios. kind regards gerrit ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
