Dirk Reiners wrote: > Hi Allen, > >Allen Bierbaum wrote: > > >>- First, it is possible to have objects (field containers) that are part >>of the concept of a scene, but are not actually in the scene graph. >> >> > >Personally I disagree, but that's a different story. > >... > > >> I think it would be better to support holding many types of >>objects, not just materials. >> >>One idea I have been toying with is to just use AttachmentContainers. >>For example if I wanted to store materials and FBO objects. >> >>rootNode >> - AttachmentContainer:"MyEditorStuff" >> - AttachmentContainer: "Materials" >> - Material: "Material One" >> - Material: "Material Two" >> - AttachmentContainer: "FBOs" >> - FBO: "FBO_one" >> >>This may work but it has a couple of issues. >> >>- Adding attachments and looking them up is by binding id (uint16) and >>groupId in some way. So I would need some way to create a unique id >>that I could rely upon my editor always being able to use for looking up >>"MyEditorStuff". >> >> > >To clarify: do you want to have a generic FC to keep arbitrary FCPtr >data, or do you want to create different classes for these things? I'm >assuming the former, as in the latter case there is no conflict. > > I just want a container of some sort where I can dump fcptrs to objects that I need to keep around. The grouping may end up be arbitrary because I may dumpt materials in one container and FBO's in another and so on or I may just want to add a bunch of things of differing types to the same container.
>Then only if you want to use an arbitrary number of instances of your >type at the same time. And even then you can just go through the list >and find the ones you care about. > > How would I go through the list and find the ones I want? For example how would I know which attachment container is "MyEditorStuff" if there are possibly other attachment containers off the root of the scene? >>- In regards to groupId, there was a previous discussion about this and >>I don't know what came of that >> >> > >There was an open question whether anyone had ever used it, and I think >the answer was no. So I wouldn't mind removing it, honestly, and >replacing it with the FCType id. Which for this case doesn't really make >a big difference. > > The way you described GroupIds before, wouldn't this restrict the attachment containers to only allow one attachment of a given FCType? >>- There is no documentation for the interface to AttachmentContainer so >>I am not really sure if I am thinking of using it correctly. ( I know >>this is a nitpick, but it does cause some pain) >>- It would be *much* easier to do this if the attributes map was indexed >>by name instead of id >> >> > >I don't like that idea very much, as it would make the lookup >significantly more expensive. Given that attachments are the core way of > adding node-specific data to the graph and that this is/will be used >for traversal/rendering-specific data I don't like having to compare >actual strings to look up attachments. > > Agreed. >If that's what you want, you could just create your own container that >keeps this data indexed by name, and add that as the only attachment to >the root node. > > Yes, you are probably right. If I wanted named attachments I would need to add a new attachment container type that is indexed by string. After looking at the code for the current attachment container though I have to admit I don't think I am skilled enough to add this. Maybe I will just try to hack something for now with the current attachment containers. :) >>Anyway, does anyone have a good idea for how to deal with this in my >>application? Is there any other class that I should be looking at that >>is new in OpenSG2? >> >> > >Not that I'm aware of. > > Ok. Thanks for the help. -Allen > Dirk > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Opensg-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/opensg-users > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
