common profile in <effect>

Hello!
I was wondering if there is anything inside the dom which would help loading common profile effects, specifically <phong> and <blinn>. I started reading that part manually through getElements (<profile_COMMON> -> <Technique> -> <blinn>/<phong>), however i figured, for those two element types, there are missing type definitions (<emission>: there is no COLLADA_TYPE::EMISSION f.e.), which made me curious whether I am missing something about those profiles.

Regards,
Michael

There are domBlinn and domPhong classes. There’s no domEmission class, because emission shares the same type as the other material color elements, called domCommon_color_or_texture_type, which is a wrapper over an element that might contain a <color> or a <texture> (and maybe a <param> too, I forget). domPhong::getEmission, for example, returns a domCommon_color_or_texture_type.

Steve

Hello Steve,
first off I want to thank you for the time spent here. Your input helped me making the code much nicer, thank you.
I have another question out of curiosity now, for which I don’t want to create a new thread, as I believe I have polluted the forum’s index enough for now.

Until now I only read one primitive subnote per geometry because of internal data representation limitations of my so called engine, which I am trying to fix now. I learned from the spec, that each mesh must have exactly one vertices-subnote. Why must contained primitives (<triangles> etc.) reference that by name then?

Regards,
Michael

Why must contained primitives (<triangles> etc.) reference that by name then?
Good point! Once you see semantic=“VERTEX”, you know which <vertices> element to use, so I think it’s redundant to also specify the <vertices> URI in the source tag. It was probably easier to design the schema this way. Since some <input>s inside a geometric primitive require a source to be specified, it was probably easier to require that all <input>s specify a source, even if it’s redundant.

Steve