Sébastien Grignard wrote: > >> 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 >> >> >> >> > Roger, > > If I'm understanding you correctly, your method supposes we can apply > several collada materials on one geometry. > I'm not sure this is possible in collada (but then again I'm not very > knowledgable with it), maybe Heinrich can answer us ? > Yes, it's possible. You can find it in the example "multimtl.dae" in this archive of COLLADA 1.4.1 examples:
http://sourceforge.net/project/showfiles.php?group_id=157838&package_id=204570 When binding the material to the geometry in a COLLADA-node you define a "symbol" for that material, which is used in this particular geometry within. ... <instance_geometry url="#box-lib"> <bind_material> <technique_common> <instance_material symbol="BlueSG" target="#Blue"/> <instance_material symbol="RedSG" target="#Red"/> </technique_common> </bind_material> </instance_geometry> ... And in the <mesh>-node in <library_geometry> you could use it, for example, like this: ... <polylist count="5" material="BlueSG"> <input offset="0" semantic="VERTEX" source="#box-lib-vertices"/> <input offset="1" semantic="NORMAL" source="#box-lib-normals"/> <vcount>4 4 4 4 4 </vcount> <p>0 0 1 1 5 2 4 3 6 4 7 5 3 6 2 7 0 8 4 9 6 10 2 11 3 12 7 13 5 14 1 15 5 16 7 17 6 18 4 19 </p> </polylist> <polylist count="1" material="RedSG"> <input offset="0" semantic="VERTEX" source="#box-lib-vertices"/> <input offset="1" semantic="NORMAL" source="#box-lib-normals"/> <vcount>4</vcount> <p>0 20 2 21 3 22 1 23 </p> </polylist> ... In this example you have a box with 5 sides in blue, bound with material "Blue" which is internally used within the geometry as "BlueSG". And you have one side in red, with the symbol "RedSG". But I honestly don't know a lot about the osg::Geode / osg::Geometry nodes (yet), and how deep in the geometry you could define an own stateset. Anyway, I hope that helps a bit... if you are a windows-user and you want to quickly preview those collada-files, there is a free Collada-Viewer, FeelingViewer @ www.feelingsoftware.com, which (mostly) works. - h _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
