Cooking

[sibarrick]

Hi all,

I have a sop I'm mucking about with that cooks in a rather odd way.

Here's the situation, put the sop down bingo it works. Change the input sop and nothing happens. Press the bypass flag twice and bingo it cooks again.

I'm using duplicateSource, not duplicateChangedSource. Is there something else I need to do to get it to recook when the input changes. The only thing that changes in the input is size not point number.

The other weird thing is that i'm using findPolysUsingEdge at the heart of this sop and if I display what it returns it only outputs sensible numbers when the sop itself appears not to have cooked. After I do the bypass thing twice the geometry updates but the print out from findPolysUsingEdge says the opposite.

[davedjohnson]

What is your SOP going to do when you're done?

[Slapdaddy]

How do you know it cooks? Are you using something like a printf before or after

if(error() < UT_ERROR_ABORT) ?

Does your sop require at least 1 input? Are you locking the inputs during the cook?

Sorry for all the vague questions, but there is not enough information in your post for me to answer your question... though I am new to HDK so it could be just me.

[Jason]

Perhaps you could check with the Performance Monitor to see if it's being asked to cook or not?

[sibarrick]

The sop is hopefully going to do some "basic" cleanup of triangles into quads. Depending on how successful it is I might try and impliment a more sophisticated routine, but it's more a learning excercise.

So to answer some of your questions:

I'm pretty sure it's cooking because the output changes, how could it change if it doesn't cook?

I'm using cout to check the results of various calculations and they seem to be consistent except for the output from findpolysusingedge. Where if I output primlist.entries() sometimes I get 0 other times I get the expected 2. Weird thing is when I get 2 the results seem wrong when I get 0, and the sop should break, it seems to work. It's all so random and inconsistent I think that is just a red herring, there must be some fundamental mistake, either something about writing sops or an unitialised variable or such like, but I can't see it.

It has one input and I'm lockingand unlocking inputs.

Since I've run out of ideas of how to check it here is the code, it doesn't do much yet, but you can see how it should function. All it does at the moment is highlight edges, but if you uncomment the delete part it will delete the edges it finds. To get it to cook at all you might need to jiggle with the position of the input grid in the test.hip. That should give you an idea of the weirdness.

TriToQuad.zip

[George]

Hi Simon,

I think the problem is that you are using a gdp to build the pointref array before you call duplicateSource. When you call duplicateSource() it copies the input gdp into your current gdp. So any references to gdp before the call to duplicateSource will be invalid. Try moving the instantiation of the point ref array and GEO_Closure after the duplicateSource(). I believe that may be the cause of the weirdness you are seeing. Let us know if that fixes it.

Take care,

George.

[sibarrick]

Nope, already tried that. Just to be sure I did it again, and moved all declarations to the other side of the duplicateSource. No joy.

It seems that when I open the file it doesn't cook correctly, if I move the grid I get one cook and it is fine, then all subsequent cooks are a bit random. So it must be something like you suggest but not just that particular thing. Something must not be initialising til the second cook.

But then once it is, why would it fail at the subsequent cook?

Confused.

[George]

Hmm... okay here are my results with this SOP:

I moved all the declarations that use gdp to after the duplicateSource and compiled.

I loaded the test.hip, and I got no highlighting. I cranked the tolerance to 5000 and now all the diagonal edges highlight. Then I went back up to the grid and moved it around a bunch of times, and everytime I get the highlight on the diagonal edges. If I scale it down so that the fitness is larger than 5000, my highlights disappear -- which I think is intentional.

Does that match the behaviour you see?

George.

[sibarrick]

No not quite, it I turn the fitness up to 5000 I don't get the central major diagonal highlighting, if I move the grid, it lights up. If I move it alot I get different edges flicking on and off. Grid is a default 10x10 can't remember if I posted that or the smaller one I was testing with.

There seems to be something screwie with the fitness calculation, it's not returning the same amount for each poly which it should. I'll go back and look at that maybe that's the answer. I can't at the moment see why it should be different for each poly since I'm passing exactly the same values to it for each one.

DOH!

//get pointer to poly
       
        for (j = 0; j < 2; j++)
        {
          vtx = &poly->getVertex(j);
          vertexPos[j] = vtx->getPos();
        }

j<2 I don't think so, j<3 please! idiot.

[George]

j<2 I don't think so, j<3 please!    idiot.

19689[/snapback]

Aha! Excellent. Good show. And those are always a bugger to track down too