On Mon, 2006-10-16 at 13:16 +0200, Heinrich Fink wrote: > As far as I know (please correct me if I'm wrong), you can not inherit > materials in collada's scenegraph-model.
That is correct. COLLADA is not a scene graph. It has a <visual_scene> that contains <node> elements that (recursively) define local coordinate systems where objects are instantiated. COLLADA does not assume the run-time has any state inheritance mechanisms (or other optimizations) other then a coordinate transformation stack. > you bind an instance of a material > to an instance of geometry, like this: > > <node id="Box" name="Box"> > ... > <instance_geometry url="#box-lib"> > <bind_material> > <technique_common> > <instance_material symbol="BlueSG" target="#Blue"/> > </technique_common> > </bind_material> > </instance_geometry> > </node> > Yes, when you instantiate a <geometry>, you can bind a material to it. The bound material is an instance of a <material>. A <material> is an instance of an <effect>. Instantiation includes the ability to bind different values to the parameters of the object (ie per-instance data). > Looking at the Collada-scheme, the element <bind_material> in > <instance_geometry> is not mandatory. You could say, if you do not > define a <bind_material> element, to an instance of geometry, you take > the binding inherited from somewhere else. COLLADA does not define that behavior. If a material is not bound to a geometry that requests one (material attribute) then the appearance is undefined (implementation defined). > But I don't think that's common sense (in Collada). Nope it isn't. COLLADA describes the appearance (material) of the objects (geometry) individually, not the context in which to perform global optimizations. > I guess from the Collada Point-Of-View you should define a bind_material > for each geometry. But that's not at all inefficient. Materials in collada > actually reflect a way of state-inheritance, but from an effect-centric > view. Yes. The effect is the rendering pipeline state that renders the geometry's appearance. Specification of the <effect> doesn't assume very much about temporal coherency and statefulness with other effects that may be executed at run-time. > A definition of a material is just an instance of an effect with > the necessary changes of some parameters to override the default-values, > it could be even as short as this one: > > <material id="Blue" name="Blue"> > <instance_effect url="#Blue-fx"/> > </material> Yes, although the notion of default values is defined by the COLLADA profile (eg <profile_GLSL)), your <effect>, and not necessarily the API it maps to (eg OpenGL). > I think, in general, this kind of effect - inheritages makes more sense > than a geode-centric inheritage. It's much easier to reuse this new > material defintion somewhere else in the scenegraph. ... and thank you for taking the time to study how COLLADA FX works :) Regards, Marcus -- Mark Barnes COLLADA Project Lead, tel:+1.650.655.7342 Sony Computer Entertainment America http://research.scea.com _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
