Hi,

I wonder if anyone could help this one: What I'm trying to achieve is something akin to a relational database userform in Houdini - much like one would find in MS Access or even Excel; i.e., being able to scroll through each record and being able to view and amend each record's parms - using one single set of parameters (a template at the asset level).

I'm working with massive data sets (dealing with tens of thousands of nodes) and promoting parms up to the asset level from their source nodes would result in a very messy and unwieldy interface at the asset level.

I may be a little naive in thinking this but, given that Houdini appears to be at its most fundamental level a hierarchical relational dB, I'm hoping achieving the above is relatively straightforward - though initial research into CHOPs appears to preclude recursive manipulation of channel data. Any thoughts or suggestions would be really appreciated. Many thanks in advance.


Cheers

I'm not sure that I understood correctly what you are after, but for dealing with collections of parameters the Parameter Spreadsheet is a good start (and an overlooked gem of Houdini).

Dragos

Thanks Dragos,


I'll try to explain a little better: Imagine you have a set of parameters on an asset, we'll call them A, B, C, D, E. They, on the asset, control a collection of parameters on bunch of SOPs (a,b,c,d,e) in a single geo node (say, Geo1)…very straightforward. Now imagine duplicating this single geo node (for arguments sake) hundreds of times. I'd like to have that same interface on the asset that dealt with geo node 1 and control the same SOP parms but in geo 2, or geo 999. Essentially switching between each Geo nodes, and controlling their respective a, b, c, d, e parms.

(Asset level parms: A B C D E (pulls in SOP parm data from any of the Geo nodes)

Geo 1…………………….Geo999

a b c d e……………… a b c d e




So the user can interactively select the source geo those asset parms (ABCDE) pull in.

Hope this clarifies things a little….

Cheers

Like Dragos said:
Parameter Spreadsheet.

Or channel references or you would need to build a custom interface in QT.

But then: I don't get the rdb reference …

Hi,

Thanks for your suggestions. Neither the parameter spreadsheet or regular referencing works in the way I'd like. I've been playing about with multiparms have found a solution though, via one of the tabbed (switch) multiparm options. This is the closest thing to to an Access Userform Interface I can come up with. It works fine. It still means a lot of work setting up the references, but I can live with that .

The relational DB reference is probably the best way to describe what I am after. Access is a relational DB; Excel, as you'll know, is most definitely not. Excel predominately deals with spreadsheets - which is not the same thing; though it is possible to mimic Access's relational DB behaviour with Excel via user-forms. But the two apps are not really comparable when it comes fully-fledged DBs

I was hoping to achieve something like an Access interface where I could scroll through each record (where each record contains a set number of parm entries).

Anyway, thanks for your suggestions, but I think I'll go with the multi-parm option - it's more straightforward, if time-consuming.

Cheers

If I understand you correctly, you may get an approximation of what you are after with a set of top level parameters (A, B, C, D, E) AND a python (or hscript) action button.

The python (or hscript) script can get the values from the A, B, C, D, E, plus the SOP's path parameter and stuff the values to that SOP. Another button could load parameters from that SOP. You may also add a few buttons (back, forward, etc) that cycle through the SOPs and load the “next's” SOP parms.

The issue may be that the SOPs inside the HDA are locked and not editable. But you may be able to specify them as editable in the Op Properties Dialog (or even uncheck the Save HDA as Locket on the Basic tab).

Hi Rafal,

Many, many thanks for that . Yup, that's precisely what I'm after. That would be better than my current set up. The multiparm (tabbed) works for each ‘record’/'entry' but never retains the number of instances on the HDA after saving - each time you install the asset you have to specify the number of multiparm instances - which is not a huge hardship -after all the parm references still work once the multiparm entries are instantiated. The scripting solution sounds much more elegant. Many thanks for that.

Best wishes,

Helene