Hi Akira,

In order to make things easier on Mac, I've added support for a PDG_IMAGEMAGICK_DIR variable. Instead of setting the PDG_IMAGEMAGICK variable, please set the PDG_IMAGEMAGICK_DIR variable to the location of your ImageMagick binary folder (e.g. ~/imagemagick/7.0.10-14/bin). This will allow the node to find the executables of all the various subcommands (convert, montage, etc.).

This fix will be available in the next Houdini daily build of 18.0 (18.0.481 or later).

Hi Akira,

Glad you found a solution for now. The reason for this is that Imagemagick may be invoked in different ways depending on which installation of the program you are using.

For example, in some installations you call magickdirectly, and specify the subcommand as an argument:


In other installations, you call the subcommands directly:


I believe that some installations also support both. It looks like the first mode of operation is not being handled on MacOS (invoking the subcommand as an argument to magick. I will file a bug for this. I will also file a bug to update the node documentation with more clarification about the different ways that Imagemagick can be invoked.

Are you able to call the subcommands directly with your installation? If so, the easiest setup would be putting the Imagemagick binary folder on your system path.

Lastly, there will be some work done on the Imagemagick node to make this easier and more seamless for the user.

You should be able to set “Create File Inputs” to an expression. E.g. if you have an attribute called “requires_inputs” you, should be able to set the “Create File inputs” parameter to “@requires_inputs” and HDA Processor will handle the rest.

1) This is possibly because the Python Script is adding attributes during the Cook step (guessing from the screenshot). Try setting the “Evaluate Script During” parameter to “Generate” on the Python Script node if it is not already set to that.

2) The HDA Processor service should be working. Can you send the errors as well as a screenshot of your service configuration in the PDG Service menu dialog?

3) This is a known issue with the expressions. I agree that at the minimum, all parameters should be accessible. I will make this change.

Built-in nodes for making it easier to work with attribute arrays is currently on our list of planned features.

Hi there! Do you have the Input File Source set to “Upstream Output Files”? This option can be used to provide a variable number of inputs.

Currently, it would require the second method (using an attribute in the Hda Path parameter on the Hda Processor node). Do you have a case where it require the first method (recognizing the @hda attribute automatically)?

It looks like something changed recently that caused this workflow to no longer work (HDA Processor was clearing the hdaparms_* attributes). I've updated the node so it will no longer clear those attributes if you have disabled all of the HDA's parameters. This fix is available in tomorrow's build!

To clarify – you want to add some custom parameters to the node's interface when your custom preset is selected?

There are instructions here for installing a Houdini Engine only setup: https://www.sidefx.com/docs/hengine/_h_a_p_i__integration.html#HAPI_Integration_EngineInVersionControl [www.sidefx.com]

Just to note, the 3ds Max plugin will not pull a Houdini Core license when Houdini Engine licenses are available. In your case, since you have enough Engine licenses for the team, the plugin should only ever pull an Engine license.

Hello,

Currently, it is not possible to automate the Mapbox HDA because it requires a GUI (which is launched when the ‘Refresh’ button is pressed). I've filed an RFE for you to make it possible to process the HDA in TOPs.

I've attached a .hip file that demonstrates how to configure the FFmpeg node to create a gif from a series of images. You will need a more recent version of Houdini 18.0 as it uses the updated FFmpeg nodes. I will file an RFE to add a preset to the FFmpeg node for creating a gif.

Let me know if you have any other questions.

Hi again,

Starting in tomorrow's build of Houdini 18.0, there will be now be “String Array”, “Integer Array”, and “Float Array” options in the “PDG Attribute Type” menu that allow you to retrieve arrays as an attribute automatically.

Hi there,

Both of your queries are technically correct, but this is not currently supported. There needs to be options for “String Array”, “Integer Array”, and “Float Array” added to the “PDG Attribte Type” parameter. I will add an RFE for this and update this thread once it has been added to the node.

Thank you!

Hello!

HDA Processor is not actually cooking the instances of the HDAs that are within your HIP file. When an HDA Processor job cooks, it runs Hython in a new process. The HDA Processor job will instantiate the HDA within that Hython session, set the parameters, cook the HDA, and then report the outputs. Therefore, if you want to expose the HDA Parameters on the interface of your top-level OBJ HDA, I would directly promote the HDA Parameters from the HDA Processor onto the top level HDA interface.

I will file a bug for the hide/disable not working. This is happening because the HDA Parameters are prefixed to avoid name clashes and the hide/disable expressions are not updated to account for this.

Buttons on your HDA's interface should be working correctly. They will appear as Toggle parameters within the “HDA Parameters” folder. When the toggle is enabled, it means that HDA Processor will “press” the button when it cooks.

You are correct – the “Enable Expressions” toggle in the “Filter HDA Parameters” window is just a quick way to enable Python expressions on parameters.

You could drive everything on the HDA Processor using attributes like you are describing. I would recommend disabling all the parameters with the “Filter HDA Parameters” window if you do this. The HDA Processor knows which attributes on the work item are HDA Parameters via 4 string attributes: hdparms_buttons, hdaparms_floats, hdaparms_ints, and hdaparms_strings. These attributes contain lists of names of the HDA Parameters. For example, if you wanted to set a float attribute on your HDA Processor called “velocity”, you would have to add a “velocity” attribute with its values, and add “velocity” to the hdaparms_floats string attribute.

I hope this helps. Let me know if you have any more questions. I can also provide some example files if you need any further clarification!

Hi there,

Can you submit a bug for the problem with the session not successfully starting when not using an administrator account? A bug can be filed here: https://www.sidefx.com/bugs/submit/ [www.sidefx.com]

Thank you!

The plugin should be able to import alpha, illumination, as well as all of the uv maps (uv..uv99).

I tried to reproduce the crash with the attached asset but was unable to. I also tried changing uv11 to illumination, but the illumination was showing up correctly in 3ds Max.

I will try a few more tests (I was investigating with 3ds Max 2019 but I will also try with 2018), but if you could also attach the HDA that is crashing for you, that would be super helpful!

Thank you!

Is the HDA that you attached (zTester.hda) crashing for you?

Enable the “All Frames in One Batch” option instead of the “Cook Frames as Single Work Item” option. (You will only need the first ROP Fetch when using this method).

I left something out of the hip file: you will also want to turn on “Create File Inputs” on the HDA Processor node and change the File Tag parameter to just “file”.

HDA Processor will generate 1 work item per upstream work item. If you want to provide multiple file inputs from different upstream nodes to HDA Processor, you will first need to partition those work items together before the HDA Processor node. I've attached a .hip file that demonstrates this. From the Tasks menu select “Generate Static Work Items” to see how it works (cooking it won't work as I haven't hooked up an HDA to the HDA Processor – this is just for demonstration).

If you attach your .hip file I can also take a look at it for you.

With “Upstream Output Files”: the inputs are wired according to the ordering of the outputs in the upstream node. So the first output will become the first input to the HDA, the second output will be wired as the HDA's second input, etc. If you have inputs that you want to provide to the HDA Processor that are produced by multiple nodes, you will need to partition together those work items first before feeding it to the HDA Processor (and ensure that ‘Merge Input Attributes’ is enabled on the partitioner).

With the “Custom File Paths” option: the inputs are wired according to their numbering (Input File 1 -> 1st input pin of the HDA, Input File 2 -> 2nd input pin of the HDA, etc).