Results 1 to 7 of 7

Thread: Best way to compare effects using COLLADA_DOM

  1. #1
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42

    Best way to compare effects using COLLADA_DOM

    Hi,

    So in Blender you can only have 16 materials assigned to a single mesh, I have a COLLADA file that assigns more than that to a single mesh, however more than half of those are redundant (the exact same effect repeated more than twice with a different name), so I want to shave off the redundant ones using COLLADA Refinery, first is there already a conditioner that does this?

    Second, if I had to write my own conditioner, what would be the best way to compare 2 effects? right now I am thinking I would have to do some recursion and check child by child, but is there something along these lines already in place, you know operator~=(domElement&,domElement&)?

    ~= : Equivalent

    Thanks!

  2. #2
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    I've implemented a generic element comparison function using the DOM, but it's in domTest.cpp (search for 'compareElements'), I think I put it in the test suite rather than the DOM itself because I knew it didn't work perfectly (the comments explain how it can fail), but I should probably fix it up and move it to the DOM.

    Steve

  3. #3
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    Thanks Steve! I was thinking about something along those lines, you know compare non ID attributes, and then the char data.

    All I saw in the comments is the attribute order issue, that should be easy to fix, is there something else besides char data not matching because of differences in space padding (that wouldn't be an issue in my particular case) that you can think of?

    Thanks again.

  4. #4
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Thanks Steve! I was thinking about something along those lines, you know compare non ID attributes, and then the char data.
    Good point. If I were to add this to the DOM I would need to add an array parameter that contains a list of attributes you don't want compared. For my purposes in the automated tests I wanted everything (including the ID) compared, so I didn't think of this.
    All I saw in the comments is the attribute order issue, that should be easy to fix, is there something else besides char data not matching because of differences in space padding (that wouldn't be an issue in my particular case) that you can think of?
    No, that's the only problem I recall.

    Steve

  5. #5
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    Ok, I ended up writing my own version, since I am using the last stable release, I don't have access to domElement::getAttributeCount() or a way to access the attribute list without knowing its name beforehand. I just needed a true/false check, so this is what I came up with:

    Code :
    bool CompareElements(domElement* a,domElement* b)
    {
    	assert(a);
    	assert(b);	
    	if(a==b) return true;
    	daeTArray<daeSmartRef<daeElement> > ac,bc;
    	a->getChildren(ac);
    	b->getChildren(bc);
    	if(a->getElementType()!=b->getElementType())
    	{
    		return false;
    	}
    	else if(ac.getCount()!=bc.getCount())
    	{
    		return false;
    	}
    	else if((a->hasValue())&&(b->hasValue()))
    	{
    		if((*((char**)a->getValuePointer())==NULL)||(*((char**)b->getValuePointer())==NULL))
    		{
    			if(*((char**)a->getValuePointer())!=*((char**)b->getValuePointer()))
    			{
    				return false;
    			}
    		}
    		else if(strcmp(*((char**)a->getValuePointer()),*((char**)b->getValuePointer()))!=0)
    		{
    			return false;
    		}
    	}	
    	for(unsigned int i=0;i<ac.getCount();++i)
    	{
    		if(!CompareElements((domElement*)ac[i],(domElement*)bc[i]))
    			return false;
    	}
    	return true;
    }

    Perhaps it may be of use to someone else.

    I decided against writing a Refinery conditioner as well, I couldn't get a hollow conditioner to run (it did compile, but the refinery wouldn't take off after I compiled libloader ), and I figured it takes the same amount of time to just write a command line C++ application that does the same thing.[/code]

  6. #6
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    I moved the comparison code to the DOM in revision 444. Now you can write
    Code :
    if (daeElement::compare(elt1, elt2) == 0) {
        // Elements are the same
    }
    Steve

  7. #7
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    Great, Thanks.

Posting Permissions

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