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.
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.
> - 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.
> - 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.
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.
> 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.
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
