Hi, On Fri, 2010-04-23 at 11:01 -0500, Carsten Neumann wrote: > Hello Gerrit, > > I've been looking a bit at the details of Material and State (originally > while analysing Micheal Raab's cluster problem [1]).
ok. Short question, does this relate to the items below ?. I'm just not sure. 1.x is inherently broken in this respect and I don't see it getting properly fixed. We rewrote a lot of the basics for 2.x for exactly this reason, so they do not have much in common any more. > One thing I've stumbled over is the ChunkBlock, which seems to behave > very similar to State (i.e. different types of StateChunks end up at > indices determined by their type). What is the difference between the two? State is the old 1.x structure, ChunkBlock is part of a highly unfinished rewrite / extension of the material structure. Right now it is the storage of the chunk override group. As this is highly incomplete really ignore it. These parts are still subject to change. Storing the chunks like inside the state was at that point the fastest way to do it but it is on my long list to revisit and re-evaluate. > I've also been wondering if it would make sense to make State not a > FieldContainer - it mostly seems to be used as a cache for chunks in > internal parts and especially in Material the multi buffering from being > a FC is wasted because every aspect creates its very own State object. > Any objections if I give this a try or reasons why this is a bad idea? I'm not sure I quite understand why. The states of the materials are thread and cluster local so the overhead should not be that big. If a material state ever syncs something is wrong and it should be a filed as a bug and fixed. So changing this would only save the aspect store, plus some bookkeeping data the container itself keeps. I'm currently very short on time (exam period) but after this is over (next week) I have to sit down an sort through a lot of my stuff and reorganize things and prioritize and plan. I know I wanted to revised the stage/material/state/override/shader structure as there are still things in there I wanted to have fixed, cleaned up, redone, finished or implemented a long time ago. Currently I can't really say if any of this would change how we use the state object so for now, if there isn't a very good reason, which basically means a bug we can not fix otherwise, I would really prefer to leave it like it is and come back to it later once things clear up. kind regards gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
