Hello Gerrit,
Gerrit Voß wrote:
> On Fri, 2010-04-23 at 11:01 -0500, Carsten Neumann wrote:
>> 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.
I don't know how to fix it properly without backporting all the 2.0
changes, so yes my plan was to leave it as is.
> We rewrote a lot of the basics for 2.x for
> exactly this reason, so they do not have much in common any more.
yes. I only mentioned the 1.x problems to explain why I was looking at
Material/State at all, i.e. I had no plan to do any work in that area,
but instead I had been poking around and got curious.
>> 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.
ok, thanks.
>> 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.
ah, that detail is what I had missed - been looking too long at the 1.x
code where we don't have aspect/cluster local FC ;)
> 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.
it would be great if you could write a short mail with the plan you come
up with :)
> 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.
yes, no problem, as already mentioned this was mostly a curiosity thing
for me, not to prepare for some changes (besides the State as non-FC
idea). Thanks for the detailed answer.
Cheers,
Carsten
------------------------------------------------------------------------------
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
