How to read an effect in library_effects?

So, I’m trying to read an effect using the DOM so that I can get the texture and material information to use for my model, but I’m having a hard time figuring out how to get to that information. Here’s a part the .dae file that I’m working with:

<effect id="rock_001-fx" name="rock_001-fx"><library_effects>
		<effect id="rock_001-fx" name="rock_001-fx">
				<technique sid="">
							<color>0.0 0.0 0.0 1.0</color>
							<color>0.4 0.4 0.4 1.0</color>
							<texture texture="C__Documents_and_"/>
							<color>0.9 0.9 0.9 1.0</color>
							<color>0.0 0.0 0.0 1.0</color>
							<color>1 1 1 1</color>

I can get into library_effects and then to the effect, but that’s where I’m stuck. There isn’t a method to access profile_COMMON or technique from domEffect.

I noticed that if i go this route domEffect.getExtra_array().get(0)->getTechnique_array() I have access to a “technique” section, but is this the same techinque section in the example above? Since there isn’t an extra section this doesn’t seem right, but if it is how do I access the rest of the information from domExtra? domExtra doesn’t seem to know about the information it contains, so how would I go about reading the rest of the information? (only if this is the right way)

Hey method-billy,
first, what tool was that exported from? because it is wrong. I’ll get back to that in a bit.

To get the profile_COMMON in the COLLADA DOM, profile_COMMON and profile_CG, etc. derive from domFX_profile_abstract. To find the profile_COMMON you must get the profile_abstract array and then iterate through it. There are 3 ways to check which element you have. you can do a strcmp on getTypeName() to look for “profile_COMMON” (or the constant COLLADA_ELEMENT_PROFILE_COMMON defined in dom/domConstants.h), you can check the newly added enum getType() (new to DOM 1.2.0 just officially released last night) or you can do a check against the _Meta, ie element->getMeta() == domProfile_COMMON::_Meta. Using the daeSafeCast function does the last method for you. heres how to do that

domProfile_COMMON *pc = daeSafeCast<domProfile_COMMON>(element);
if (pc != NULL) //you have a profile common, else continue to the next fxprofile_abstract

The tool that you exported this from is broken. It is doing a common error we in the COLLADA community refer to as “direct texture linking”. You can get more information on this from here It may be a good idea to implement a loader that supports both the correct way and incorrect way for backwards compatibility but even doing that wouldn’t help this document. “C__Documents_and_” is far from a vaild texture. Maybe you just truncated the path for the example but if not there are some serious problems going on there.


Thanks, I’ll try using profile_abstract array and see where I get. While I was waiting for an answer I messed around and found that I could get the information by domEffect->getContents().get(0).getChildren()… altough it takes a lot more processing of the data on my part. I’m hoping that going the profile_abstract route will be simpler :slight_smile:

On my .dae file not being correct, I can’t remember where I got the file from, but at the time I needed a model with a texture and that was one of the first ones that I found. After looking at the sample data again, I think I’ll probably switch to working with duck.dae from the sample data instead.

Okay, so I was able to use profile_COMMON to get access the data that I wanted and I have another question about that.

<newparam sid="file2-surface">
                    <surface type="2D">
                <newparam sid="file2-sampler">
                <technique sid="common">
                            <color>0 0 0 1 </color>
                            <color>0 0 0 1 </color>
                            <texture texture="file2-sampler" texcoord="UVSET0"/>

So when I read the texture from diffuse, I’m left with a texture name of “file2-sampler”. Is that a reference an element that DOM can resolve or do I have to iterate through the newparams and match the strings?

A little from column A and a little from column B.
The DOM will not resolve the sid reference automatically for you upon load like URIs, but there is a daeSIDResolver class that can. The only problem is that these references aren’t standard COLLADA addressing syntax targets. They are just SIDRefs.

Actually, in this case its probably just easier to iterate over the newparams by hand. There are two different dom types for newparams depending on the scope. <effect><newparam> (which I don’t think any implementations are using) are shared parameters for any profile. They are type domFx_newparam_common. The <effect><profile_COMMON><newparam> is type domCommon_newparam_type.

if you want to venture into using the daeSIDResolver class, for the constructor’s parameters, the container should be the <effect> element, the target should be a string “./file2_sampler” (this essentially means search relative to the container) and the platform should be left NULL. When you call getElement() make sure you check it’s type to differentiate between the two newparam types. For more information on the COLLADA Addressing Syntax look in the COLLADA specification found at . There is a whole section about it. It will definately be usefull to know when you start importing animations.

Just giving you a heads up.