Hi, On Mon, 2010-08-16 at 13:54 -0500, Carsten Neumann wrote: > Hello Gerrit, > > Gerrit Voß wrote: > > On Mon, 2010-08-16 at 12:31 -0500, Carsten Neumann wrote: > >> this last one is a bit iffy as the parents field is actually the one in > >> the Attachment base class. Is the reuse of the parents field there > >> intentional [1]? > > > > yes, there is some magic with the parents happening, I'm looking into > > this, as this is where the assert violation comes from. > > yes, that was the motivation for making the changes, it seemed since the > actual parent objects are not transmitted it did not make sense to > transmit the fields pointing to them. And the assertion triggered > because indices were still transmitted, but they also refer to the > uniform position on the server side, so should not be transmitted - > well, at least that was my thinking ;) > > > I just wanted > > to collect all side effects before committing, at least I expect these > > changes to break the compat SHL version of the shaders. But I'm still > > verifying this though. > > ouch, sorry, I had not considered those. Do you want me to back out r2478?
not for now I have to fix it sooner than later so it hopefully should be fine. > >> [1] a related question is why StateChunk derives from Attachment in the > >> first place? Does anyone remember? > > > > not sure anymore, I don't know if we ever used them as attachments. > > hm, attachment adds two fields (parents, internal) that are mostly not > used for StateChunks, so it seems to make sense to change them to derive > from FieldContainer, or perhaps AttachmentContainer? They are already a weird combination of being both attachments and attachment containers (naming them needs the container part, and the VRML/X3D worshippers want that ;)). So maybe we should really get rid of them being attachments. I put it onto my think about list ;) kind regards gerrit ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
