Jump to content

Hdk Sop "sim" Cook Problem


Guest xionmark

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :P

-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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :P

-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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...