Hello Carsten, On 13.03.2013 21:40, Carsten Neumann wrote: > > hmm, it seems to me MaterialChunkOverrideGroup should iterate over the > chunks of the State returned by PrimeMaterial::getState(). That would > also make it work with materials not derived from ChunkMaterial.
sounds great. > This is made a bit tricky by the fact that State does not allow easy > iteration over it's contained chunks. > why is that? State does provide an index access to its _mfChunks container. However, I found no access to the size of the container. > > Originally the idea was that there are many different types derived from > Material (not ChunkMaterial!) each maintaining a State object (per > pass). ChunkMaterial was intended for one off cases where a specific > combination of OpenGL states was needed and it was not worth the effort > to write a separate material. > In a strict sense SimpleMaterial should not derive from ChunkMaterial; > it does so because it is occasionally convenient to extend a > SimpleMaterial with one more extra chunk to achieve a desired effect, > but the chunks SimpleMaterial creates internally are not meant to leak > to the outside (which they would if added to ChunkMaterial's chunk list). > I have now understood. I'm now convinced that the problem actually not stems from the SimpleMaterial but from the implementation and assumptions of the MaterialChunkOverrideGroup. Is it possible to let it work on the Material State chunks, or are there more problems despite of the State's interface? Best, Johannes ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
