Results 1 to 4 of 4

Thread: common profile in <effect>

  1. #1
    Junior Member
    Join Date
    Dec 2007
    Posts
    5

    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

  2. #2
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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

  3. #3
    Junior Member
    Join Date
    Dec 2007
    Posts
    5
    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

  4. #4
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •