Sebastein, > -----Original Message----- > Yes, at least for me :-) > I'm in fact in the same situation : understanding what could be done but > without the collada knowledge I'd need to write the changes myself. > As you said the main question is whether we can reproduce the OSG's > StateSet inheriting in collada, or are we forced to create one material > for each geometry that has a different list of statesets attached to it. > > > > > > >I don't know enough about Collada to code this up myself. But maybe we > can > >work out the design together and I might be able to give it a go. > > > >
At least I was not writing complete nonsense! After having slept on it, I think one possible approach would be as follows:- 1. A method that is executed as each node (including geodes is traversed. This method would need to detect whenever a new "material" was encountered. It would name and store each new material for inclusion in the "library". Additionally this method would maintain a list of "currently active materials". Maybe there is something in one of the other osg plugins we can model this on. Anyone know? 2. A method that is executed per geode after method 1 has been executed for that geode. This method would scan the stateSet associated which each geometry contained in the geode and add any new "materials" found to the "library". The method would then set the local material name bindings for the DOM geometry such that the materials are correctly applied to each DOM mesh. The main thing that I not sure on is whether any new materials encountered at the osg::Geode and osg::Geometry stateSet levels need to be put in a global "library" as they can never be referenced outside of the scope of the geode node in the osg tree(on reviewing this I am not sure I am correct here, what about geometries shared between geodes?). I do not know whether there is any local material mechanism or if the way the writer puts geometries into a library-geometries forces a library_materials to be used. I still cannot get my head round this. It may be better to implement as closely as possible to original model used in the writer and then look for optimisations later. Any comments? Roger _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
