Hi,

I completed the awesome “PDG for Indie Gamedev” tutorial series [www.sidefx.com] from Kenny Lammers and I'd like to share my comments and questions and maybe hear from other people having used PDG in Unity.

• It's very hard to debug PDG in Unity when everything works fine in Houdini, but a work item fails in Unity.
  I often had issues with paths being wrong for Unity: In HDA Processor, the HDA path is supposed to be $PDG_DIR/hda/myhda.hda, but defaulted to $JOB/hda/myhda.hda. I forgot to change it several times and since there are no error messages, except the “FAILED” in the PDG Asset Link, it took a while each time to pinpoint which node was failing.
  It's especially difficult when using the “HEngine Data” tag that hides nodes.
  It would be very useful to have the name of the failed items (in the Unity console or as a tooltip in the work item status table), and as much info as we have in Houdini when middle clicking on a failed work item.
  
• Also related, it would be useful to have more details of what's cooking in the PDG Asset Link. At least the names of the TOP nodes being processed in a tooltip or something. We're kind of blind compared to the amount of cool feedback we have in Houdini
  
• When building and testing the TOP network, Houdini and Unity share the same $PDG_DIR path to write and read data (mostly bgeo files) Can it create conflicts and issues? Is it better to always clean up this data when switching from Houdini to Unity and vice versa?
  
• Last question: In the tutorial, to make terrain textures show up correctly, their path have to start from a “Assets/Resources” folder and not have file extensions. Is it a Unity Engine constraint? I could not find any documentation on this.
  

Thanks a lot!
Alex

Hi Alex,

This is great feedback. Thank you for being so thorough and informative.

Yes, the debugging aspect of PDG in Houdini Engine requires improvements for usability. One thing that will help is being able to open or show the generated log file from within Unity. I have an RFE for this. Another might be showing more granular info for failed work items, as you suggest.

Note that $JOB var does not exist in a Houdini Engine session by default, so I suggest instead to use a custom environment variable that you can always set from Houdini (via houdini.env or Alias and Variables window), and Unity (via unity_houdini.env file). Also note that the TOP Local Scheduler node defaults to using $HIP for its Working Directory. $HIP points to your user directory by default in a Houdini Engine session (because there is no .hip file in a Houdini Engine session), which is probably not what you want. Instead, always set the scheduler node's Working Directory to something valid for both Houdini and a Houdini Engine session.

So right now, you have to select the TOP node in the drop down to see its status. I guess it would be helpful to show names (and perhaps buttons to select) TOP nodes currently being cooked. The current design leans towards the side of clean, simple UI instead of showing more info which might lead to clutter and confusion for the user (if say they aren't familiar with TOPs/PDG/Houdini). Perhaps there is a balance we haven't achieved yet though with the PDG Asset Link UI.

It is not necessary to use the same $PDG_DIR for both Houdini and Unity. Kenny did that for the demo because he found it easier to debug (e.g. he can cook in Unity and load result geo in Houdini). If you use the same directory though, yes it can cause conflicts if working in both Houdini and Unity at the same time. So would be good to clean out the directory if you are getting issues. But you can supply a separate $PDG_DIR value by exposing it as a parm and changing it from within Unity. In fact, this is exactly what I would recommend. Expose the TOP scheduler node's Working Directory in your TOP master HDA, and use different directories when in Houdini and in Unity.

Yes the texture loading file path was due to Unity's loading mechanism. The textures have to be placed in a folder that is placed under the project ‘Assets’ folder or a ‘Resources’ subfolder. Unity treats assets placed in either folder differently for packaging and loading. Unity preprocesses the assets in the ‘Resources’ subfolder, and loads assets in there much faster than assets placed in the ‘Assets’ folder. Also, assets placed in the ‘Resources’ folder don't need to be specified with their extension (nor the ‘Resources/’ folder prefix). On the other hand, assets placed in the ‘Assets’ folder do need to have their extension, and need to start with ‘Assets/’ as the start of their file path. The reason that the PDG demo uses textures from the ‘Resources’ folder was due to the faster speed of loading them. But you can also specify textures from the ‘Assets’ folder and it should work (with the correct file path e.g. 'Assets/Textures/texture1.png").

Hi seelan!

Thanks for your detailed answer, it clears many things up on how to setup PDG in Unity and how Unity works.
All of this is pretty new to me and I just want to make sure I set up everything properly for my team/project.

I'm already using the unity_houdini.env to setup a custom directory for PDG to work in, as instructed in the tutorial. It's just that because of a bug in the HDA Processors (already reported as bug #96263) I had to set the HDA path to $JOB to be able to update the HDA parameters and then forgot (several times ) to set the path back to $PDG_DIR!
As you suggested, I will definitely try to expose the Scheduler's node Working Directory in my TOP HDA. Does it mean that I can get rid of the custom environment variable altogether (both in Houdini and Unity)?

I agree with you on the clean and simple aspect of UI for the PDG Asset Link, however I don't think any artist would be playing a lot with the PDG Asset Link itself. As a tech artist, I would setup everything in the Asset Link, set it to Autocook and leave artists only tweak the TOP HDA parameters and the auxiliary HDA tools.
So a minimum of info on what's going on, and a maximum of info when something goes wrong seems fair to me.

Thanks,
Alex

Yes, if you expose the working directory parm then you probably won't need the unity_houdini.env file. But do note that if you are working in a cross-platform environment (i.e. artist A on mac vs. artist B on windows), and they have different paths (e.g. /Users/blah/project vs. C:\Users\blah\project) then unity_houdini.env should be used as it allows to set custom paths for each artist and save it locally on their machine. If you only use the parm though, the path will be saved in the HDA in the Unity scene, and checked into source control with that path, which means each artist might have to change the path. You can do a combination of both exposing the parm and using the unity_houdini.env file as well, which might give best of both worlds.

Sounds good. Do submit RFEs if you have suggestions to improve the usability and UI. Thanks again.

Learning PDG for Unity here too… looks like you may be a little more advanced than me at this point.

I'm not changing any path variables in either Unity or Houdini, but have managed to get everything working saving all the HDA's and Top directly to my Unity test projects.

I'm on Mac and we have people in our group on PC so that may have to change in the future once I get out of the learning mode and have to share files. As of right now I plan on deleting the Houdini source and only keeping the output before sharing on Unity Collab. Not sure if that theory will work on not yet though.