I'm doing a section of a music video: I've made a simple “blooming petals” HDA with a number of parameters, and now I need to set up lots of instances of it that fire off at certain beats and cues within the music.

If I wanted to orchestrate a fireworks display, I'd have exactly the same question - I could create a super flexible über-firework HDA, but I'd then need a way to store the parameters and timing for each instance.

There are a number of ways I could do this, but I'm interested to know what others feel is the best approach.

My HDA has a pretty simple interface:


And I need to set up / orchestrate around 50 instances. So I could just make lots of copies, tweak their parameters for timing and taste, and merge 'em all:


(yuck)

But it'd be much nicer to be able to use the spreadsheet to set all those parameters and delays, so an approach like this, using points and attributes may be better:


At least I can see and tweak all the parameters in the spreadsheet nicely. That locked “All_the_orchestration_information” Edit SOP lets me see all my lovely data:


But it has its issues. If I want to add another parameter to my setup, I have to unlock that Edit node and lose all my orchestration. Or if I didn't create enough points to start with… things could get messy.

What are your thoughts? Is there a better way to achieve a spreadsheety display of my timings and parameters? Is it necessarily evil to edit in the spreadsheet like this?

Hi there,
do you know about the concept of packed primitives and unpacking prims?
http://www.sidefx.com/docs/houdini/model/packed.html [www.sidefx.com]

Not sure if that would help but…

kind regards

Olaf

Yes - but that doesn't really help here, as most of the instances of my HDA will have different parameters set. Plus the meshes output are small and lightweight so performance isn't an issue in this project.

S'pose I'm asking: if you'd made a firework HDA, configurable to generate every kind of firework your show needed, where / how in Houdini would you actually design your show?

It's really a question of how best to store the data for all the instances. Point attributes seem the most sensible, and they're easiest set in the Spreadsheet, but … using the spreadsheet always seems a little fragile somehow.

In an ideal world, we'd have a specialised point generation SOP - a “Create Points plus Attributes” SOP that'd let you create and edit points (rows) and attributes (columns) in the spreadsheet without destroying what was already there.

Edit: I've logged it as an RFE.

Ok maybe like this
you pack your HDAs geometry and on the packed prim point you have the attributes(data). If you change the data you unpack the HDA update the geo and pack it again… Something like this. Should do what you want.

Not easy to explain in a few words

And i would never edit data in the spreadsheet…

And i would never edit data in the spreadsheet…

Hehe - yep, feels wrong, doesn't it But it really is the best way to store data like this:



The nice support folk have suggested that I store this info in an external text file, then use something like the Table Load SOP, which sucks in a CSV file, creating points and attributes all at the same time. Which is grand, but doesn't lend itself to quick iterating and tweaking, which really is what I need when developing both my HDA and my “running order”.

I've raised an RFE asking for a Table Load SOP that just uses Houdini's own spreadsheet, rather than relying on an external package. If they do add it as a new feature, it'll certainly help my workflow; it'll let me populate my scene with a few instances of an HDA with varying parameters so I can tweak the HDA and see how it looks in different situations.

Thanks for the tips, though Olaf - much appreciated

Hi Howie,
sure working with external data in xml, a text file an excel spreadsheet or whatever is actually great. I do that quite a bit. But with a dynamic changing layout or parameters etc. hmm
I have to look into this. This is sort of important when working with meta data.
I dont mind it being an external editor but you would need, one node that writes the meta data to a file and another one that reads it after (or better even while) being manipulated.

Olaf