Pruning Unnecessary Params From Rop_ifd

[dee900]

We've got a developer writing a geometry exporter to a custom format. He is subclassing from ROP_IFD. By default, the custom ROP has lots of parameters which make no sense in our specific use case. For example, camera. (In fact, even if we leave the camera blank, we get an error upon pressing "render".). The developer writes:

"Similarly the parameters dialog is chock full of things that don't apply to geometry export, again added by the default interface. Even though I haven't called addCapability("image") etc (the only capability I've added is "hasrop"), the params window still includes lots of irrelevant things, they're just greyed out. Do I have to just live with that?"

Any suggestions would be most welcome ...

Cheers,

Darran.

[sibarrick]

Not sure if this will help, and I don't remember the full details, but I managed to hide parameters for an object using the following, maybe you can extract something useful from it

OP_TemplatePair *
OBJ_Driven::buildTemplatePair(OP_TemplatePair *prevstuff)
{
   OP_TemplatePair	 *driven, *geo;
   int   i,j;
   int   size,mysize;
   UT_String parm_name;


   // The parm templates here are not created as a static list because
   // if that static list was built before the OBJbaseTemplate static list
   // (which it references) then that list would be corrupt. Thus we have
   // to force our static list to be created after OBJbaseTemplate.
   static PRM_Template *theTemplate = 0;
   static PRM_Template *myTemplate = 0;
   if	 (!theTemplate)
   {
	  PRM_Template *  obj_template = OBJ_Null::getTemplateList();

	  size = PRM_Template::countTemplates( obj_template );

	  theTemplate = new PRM_Template[size + 1];   // add +1 for sentinel

	  for( i = 0; i < size; i++)
	  {
		obj_template[i].getToken( parm_name );
		if (parm_name == "stdswitcher" )
		{
		  theTemplate[i] = templatelist[0];
		}
		else if (parm_name != "stdswitcher" )
		{
		  if (parm_name == "stdswitcher" ||
			  parm_name == "keeppos" ||
			  parm_name == "pre_xform" ||
			  parm_name == "xOrd" ||
			  parm_name == "rOrd" ||
			  parm_name == "t" ||
			  parm_name == "r" ||
			  parm_name == "s" ||
			  parm_name == "p" ||
			  parm_name == "scale" ||
			  parm_name == "lookatpath" ||
			  parm_name == "lookup" ||
			  parm_name == "pathobjpath" ||
			  parm_name == "roll" ||
			  parm_name == "pos" ||
			  parm_name == "uparmtype" ||
			  parm_name == "pathorient" ||
			  parm_name == "up" ||
			  parm_name == "bank" ||
			  parm_name == "tdisplay" )
		  {
			copyParmWithInvisible( obj_template[i], theTemplate[i] );
		  }
		  else
		  {
			theTemplate[i] = obj_template[i];
		  }
		}
	  }
	}

	mysize = PRM_Template::countTemplates( templatelist );
	myTemplate = new PRM_Template[mysize + 1];

	myTemplate[0]=PRM_Template(PRM_SEPARATOR,1,&names[28]);

	for( i = 1,j=1; i < mysize; i++,j++)
	{
	  myTemplate[i] = templatelist[i];
	  //templatelist[j].getToken( parm_name );
	  //cout<<parm_name<<endl;
	}


	driven = new OP_TemplatePair(myTemplate, prevstuff);
	geo = new OP_TemplatePair(theTemplate, driven);

   return geo;
}

The key here was using copyParmWithInvisible

I think the original idea came from an object example, so maybe that will help too....

Edited February 8, 2007 by sibarrick

[Jason]

You might not want to hear this - but what is your time frame? Without knowing what your ultimate intention is, I'm quite sure that Houdini 9 will be able to provide you with a totally different and far more flexible way in which to do this kind of thing. In other words, you might not want to spend too much time trying to get a flawless system going in 8.1 only to find some clear advantages in 9.0 that might tempt you to redesign it.

PS. I'm pretty certain that your 8.1 ROP will still be able to work in 9.0.

[dee900]

You might not want to hear this - but what is your time frame? Without knowing what your ultimate intention is, I'm quite sure that Houdini 9 will be able to provide you with a totally different and far more flexible way in which to do this kind of thing. In other words, you might not want to spend too much time trying to get a flawless system going in 8.1 only to find some clear advantages in 9.0 that might tempt you to redesign it.

I have a project to deliver by mid April. Are you referring to Collada export ability?

[Jason]

I have a project to deliver by mid April. Are you referring to Collada export ability?

I would go with what you know for your April deadline, thats for sure. I think maybe Houdini 9 can help you with your next one:)