Anyone got a tip to convert a customproperty to a regular customparamset?

[Alan Fregtman]

Hey guys,

I have a customproperty defined in a plugin and it is used in a few assets, but I no longer care for the plugin and just want it to be a regular customparamset, however, Softimage complains that the plugin doesn't exist.

Is there a trick to converting a customproperty to a paramset without having to recreate parameters one by one?

Any help appreciated.

Cheers,

   -- Alan

[Matt Lind]

Once you’ve deployed the custom property, it needs to be supported until you’ve removed it from all content which uses it.

 

The primary difference between a custom property and a customparamset is structure.  Customparamsets are a generic custom property for end users to do quick and dirty stuff.  They have very little support for PPGLayouts and cannot be identified from script code as all CustomParamSets have the same ‘type’ (customparamset).  The only way you can identify them is by name or by comparing parameters.  That is why the self installing CustomProperty was invented.

 

I’ve never heard of wanting to migrate from CustomProperty to CustomParamSet, so this is a bit odd.

 

 

Matt

[Alan Fregtman]

Well, somebody thought it was a brilliant idea to be making whole new plugins for character-specific rig properties, just because they wanted a ppglayout. (None of these properties had any logic whatsoever.)

I'm looking to migrate those to a GenericProperty property like:

http://www.softimageblog.com/archives/172

so it only relies on 1 plugin instead of 6 or 7.

[Matt Lind]

In that case you definitely don’t want to migrate to a customparamset.  You want to convert to a more intelligently designed custom property.

 

I don’t see the need for storing the PPGLayout code as a string as _DefineLayout() or _OnInit() could house that code.  You can also load PPGLogic from an external file, so really no need to go the generic property route in terms of implementation.

[Alan Fregtman]

In retrospect, I worded my thread wrong. I meant converting one customproperty to another. I guess it's too much to ask of the software.

I don't need Logic. I just want a way to make logic-free ppgs with infinitely different persistent layouts. The SI Blog post is what I'm after (unless there's some trick I've overlooked.)

[Matt Lind]

If you store the PPGLogic externally in a file, you can dynamically call different logic files depending on what you want to display.  The callbacks can then be married to what is displayed.  This is useful for one-to-many relationships like this or in cases where the data gets embedded into assets and you don’t want to have to run a batch process to update them each time the custom property is revised.  Modify the external logic file and the next time the asset is loaded and viewing content, it’ll use the latest version of the logic file to display the information.

 

The code to choose what to display can be provided as a function/callback embedded in the external logic file and called from _OnInit().  Just make sure to call PPG.Refresh() at the end.

[Michael Heberlein]

Last week I also stumbled upon Daniele's "persistent layouts" blog post. To do exactly the "quick and dirty end-user stuff" and store PPG layouts per scene or per model, to me it looks like a good solution to use just one self-installed "GenericProperty" instead of many.

Michael

[Cristobal Infante]

using pyqt would be another solution, you could create a custom .ui and just import it for every asset.

I am having to do something similar at work and debating which way to go, I would prefer softimage native of course..

[Christopher]

Is there anything like pyQT for JavaScript peoples :-)

::Christopher::

[Raffaele Fragapane]

None that will run inside Softimage. The only available browser front-ended ports around largely out-date the netview and JS.

Softimage also DOES NOT use Javascript. It uses JScript, which is Microsoft's stillborn half arsed effort at it.

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[Raffaele Fragapane]

Steve Caron was key to the pyQt Soft efforts though, you could write him an e-mail asking if he wouldn't mind writing JScript bindings maybe.

On Tue, Jun 18, 2013 at 12:57 PM, Christopher <chris...@thecreativesheep.ca> wrote:

[Steven Caron]

i guess i gotta add raff to my filter too? ;P

[Raffaele Fragapane]

You don't like Javascript peoples?! Does it mean you'll add Matt Lind as well?

[Steven Caron]

*filtering all the peeples*... i will be on the list, alone.

[Cristobal Infante]

Just learn Python you won't look back, I believe Raffaele has done some great tutorials to get you started:

http://tod.cgsociety.org/index.php/home/view/technical_direction_in_xsi_with_python

[Christopher]

Oh that is what Raf looks like, I was expecting him to look completely different.

::Christopher::

[Raffaele Fragapane]

It's more what I looked like eight years ago. Animators interceding for nearly a decade resulted in less hair and a more pronounced frown these days.

[Alan Fregtman]

I was a student in the very first round, fyi. :p I know my Python reasonably well, thanks.

What I was after was if there was some secret way of changing a customproperty type since fundamentally they're just parameters, but no, I have to mass-copy parameters (via scripting, yes) to a new property.

[Stephen Blair]

On 18/06/2013 9:29 AM, Alan Fregtman wrote:
>
> What I was after was if there was some secret way of changing a
> customproperty type since fundamentally they're just parameters, but
> no, I have to mass-copy parameters (via scripting, yes) to a new property.
>
>

Nope, no secret way to change the type [that I could find].

Scavenge the addparameter code from the original plugin and use that to
create the non-self-installed version of the property, and then use
BinaryData to copy over the parameter values?

[Andy Jones]

Perhaps you could add some code in the init callback of the property
to auto-generate the new property? I've done something sort of
similar for making custom properties that can "upgrade" themselves to
the latest definitions by checking a "version" parameter's value and
seeing if it's out of date. Of course, in that case I'm just storing
all the parameter values in a dictionary, deleting them, recreating
the params, and setting all the values. A little different than
creating a whole new property.

It's not that different from just doing it with a standalone script I
suppose, but maybe it's somehow helpful for you?