Hi Allen, > As part of the work I am doing on OpenSG2 and pyOpenSG I am working on a > scene editor. It is not going to be anything as full featured as VRED, > but it should allow editing of basic scenes and debugging/development of > shaders and multi-pass rendering with OpenSG2.
sounds great. > Are part of this effort I have run into an interesting problem. > > - 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. > > For example the user may want multiple materials in the scene so they > can edit things and try out new materials. But as it stands right now > it would be difficult to just create a new material out of the blue > because this material would not be part of the scene graph and would not > be saved out. For materials, I think VRED solves this by introducing > the MaterialPool NodeCore. I could try to port this to OpenSG 2, but it > has a couple of issues. First, a node core seems a bit heavy weight to > me so I think it should be an attachment that could just be added to the > scene root. Second, the MaterialPool in 1.8 only supports pooling > materials. I think it would be better to support holding many types of > objects, not just materials. yes right I added the MaterialPool to handle unreferenced materials. This makes it also possible to write material libraries as a osb file out. > 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". > - In regards to groupId, there was a previous discussion about this and > I don't know what came of that > - 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 You could create a field container pointer pool attachment to store everything and just add some convenient methods or iterators to get the materials, fbo's ... Andreas > 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? > > Thanks, > Allen > > > > > > > ------------------------------------------------------------------------- > 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
