Hdk Sop "sim" Cook Problem

[Guest xionmark]

Greetings,

I have this annoying problem when building a SOP (with the HDK) that does a sort of "simulation" thingy, more specifically, it reads the incoming geometry at an "init" frame and then performs some sort of processing on the data for each subsequent frames.

The problem is that for some reason, the geometry doesn't update in the viewport unless I append another SOP to the output of my "sim" SOP.

The data in the spreadsheet is being updated correctly but for some reason not in the viewport; this must be something super simple that I'm missing.

Here's a boiled down cookMySop() function that reads the incoming geometry at some frame then simple adds 0.1 to the point's Y axis.

OP_ERROR SOP_DEBUG::cookMySop(OP_Context &context)
{
   float now;
   long frame;
   int initframe;
   GEO_Point *pt;
   UT_Interrupt *boss;

   now = context.myTime;
   frame = context.getFrame();

   if (lockInputs(context) >= UT_ERROR_ABORT)
	  return error();

   OP_Node::flags().timeDep = 1;

   initframe = INITFRAME();

   if (error() < UT_ERROR_ABORT)
   {
	  if(frame == initframe)
	  {
		 boss = UTgetInterrupt();
		 boss->opStart("Initializing");
		 gdp->clearAndDestroy();
		 duplicateSource(0, context);
		 boss->opEnd();
	  }

	  else
	  {
		 boss = UTgetInterrupt();
		 boss->opStart("Setting new grid positions");

		 FOR_ALL_GPOINTS(gdp, pt)
		 {
			if (boss->opInterrupt())
			   break;

			pt->getPos()[1] += 0.1;
		 }
		 boss->opEnd();
	  }
   }

   unlockInputs();
   myCurrPoint = -1;
   return error();
}

I can upload the code and a hip file if needed.

As always, thanks in advance!!!

--Mark

[eloop]

It sounds similar to my question here yesterday regarding display normal recalculation. Try adding gdp->normal() after you've updated the point positions.

-Drew

[Guest xionmark]

It sounds similar to my question here yesterday regarding display normal recalculation. Try adding gdp->normal() after you've updated the point positions.

Ah!

Just tried your suggestion, it adds N attribute (even if it wasn't there) and after I turned on the display normals for the viewport I did indeed notice there were normals now, and they were moving! Doh! After turning on the display points for the viewport the real problem was revealed, the primitives aren't updating, not the points.

I'm not sure what to about that yet.

Thanks Drew.

--Mark

[eloop]

Hmmm, I hadn't noticed it was actually adding a normal attribute. So Simon, this isn't really what I wanted. There must be some internal mechanism to tell a gdp when it needs to recalculate normals to get a proper shaded opengl preview, and it's probably reset everytime you gdp->clearAndDestroy(). Any other ideas guys ? I should probably try the devkit mailing list while I'm at it.

Mark, glad my suggestion helped you along the way

-Drew

Ah!

Just tried your suggestion, it adds N attribute (even if it wasn't there) and after I turned on the display normals for the viewport I did indeed notice there were normals now, and they were moving! Doh! After turning on the display points for the viewport the real problem was revealed, the primitives aren't updating, not the points.

I'm not sure what to about that yet.

Thanks Drew.

--Mark

[Guest xionmark]

Noticed something else, it appears it's only when NURBS or Bezier surfaces are input to the SOP, poly's and mesh seem to be OK, I've been using NURBS surfaces and just noticed this clue.

I tried doing a forceRecook(), no luck, still digging.

--Mark

[sibarrick]

Hmmm, I hadn't noticed it was actually adding a normal attribute. So Simon, this isn't really what I wanted. There must be some internal mechanism to tell a gdp when it needs to recalculate normals to get a proper shaded opengl preview, and it's probably reset everytime you gdp->clearAndDestroy(). Any other ideas guys ? I should probably try the devkit mailing list while I'm at it.

Mark, glad my suggestion helped you along the way

-Drew

Hmmm that's odd, I kinda assumed that you must have had normals already otherwise they wouldn't be causing a problem. When I use it I just do a test for N and if it exists I recalculate them and if they don't I leave well alone. This sounds like a more indepth problem. I've not had a problem when building geometry where it shaded wrong and there were no existing normals. I can't see why building geometry from points with no normals would cause a problem. Edward?

[Guest xionmark]

Hi there,

Ondrej answered my question on the SESI list. Just needed to add:

gdp->notifyCache(GU_CACHE_ALL)

to ensure that any caches (including display caches) are rebuilt.

Works fine now.

--Mark