Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Community Reputation

1 Neutral

About BWoods

  • Rank

Personal Information

  • Name
    Brandon Woods
  • Location
    Vancouver, Canada
  1. I have an HDA with a parameter that allows users to return a selection from the viewport (same type of parameter used on blast nodes etc.). I have a callback script that I want to run whenever the artist makes a selection, however, the script only seems to execute when the string portion of the parameter is edited. For example if I manually type the name of an object into the parameter the callback script executes as expected, but if I use the arrow button to select the objects in the viewport and hit enter to confirm my selection the callback script is not executed. This obviously isn't very useful or intuitive for artists. Does anyone have any workarounds or suggestions on how to get this functioning the way one would expect it to?
  2. Hey Alex, sorry I didn't see your reply back in August. Thank-you for this! I was just revisiting this thread to see if there were any comments that would help me resolve some issues with the previous .asCode() method that I encountered when running our tool on things like the new SOP level pyro solver. The hscript method you posted circumvents the problem nicely! Definitely going to be switching to this going forward!
  3. Just to update this, I was not able to get ikoons solution working for some reason, but I did figure out why the sop solver wasn't saving correctly with our existing code. As it turns out, the .asCode function will not output script for the creation of nodes inside of locked assets, which the sop solver is. It seems like an obvious answer in retrospect but I still think it is something that should be explicitly stated in the method definition for the hou.Node class. Regardless, the answer is to use the allowEditingOfContents function on your solver before saving it with .asCode and then loop over it after it is recreated and lock it again.
  4. Ahh I see thanks ikoon! This is part of a larger tool that loops over all the contents of a scene for creating templates and/or sharing smaller node networks. Just need to find a way to account for this in the loop somehow. EDIT: I can't share the code for the larger tool but this is the simplified version I was using to test out saving the sop solver. I had a geo object selected at obj level and the geo object had a simple setup with a sop solver transferring @Cd based on distance each frame. import hou import os def save_script(): # Create our script selected = hou.selectedNodes() script = "" for node in selected: script += node.asCode(recurse=True) filepath = "$HIP/test_script.txt" filepath = hou.expandString(filepath) with open(filepath, "w") as output: output.write(script) save_script();
  5. Hey, bit of a specific use case here, but has anyone successfully used the .asCode() Python function with the SOP solver? I can't seem to get it to save and recreate the nodes inside of the sop level solver node. I spent some time researching it but haven't found anyone even mentioning this problem. Everything else seems to work fine with the function even the DOP level SOP solver. It's just the SOP level solver that has this issue. I'm kind of at my wit's end trying to figure this out. I might be missing something super simple or obvious here, but I'm hoping someone else has encountered this and figured out what is happening. I suppose it could also be a bug, I haven't taken the time to dig through all the change logs on the SideFX website. I'm currently encountering this in Houdini 18.0.348 (which has known issues with the .asCode() function) as well 18.0.597 (where those issues have supposedly been resolved). If anyone has any insight I'd really appreciate a nudge in the right direction. Cheers, Brandon
  6. Pyro trail clusters get confused by loops

    Ahh yeah super simple solution, I didn't notice you could specify that. Thanks!
  7. Hi everyone, I've run into an issue and I'm looking for some help coming up with a work around. We've got a lot of effects that involve smoke trails from characters flying around and we've been using pyro clustering to make the trails. However there is one particular issue I just can't think of a solution to. The default cluster setup transfers the cluster number to a trailed collection of your source points and then finds the lowest source frame in each cluster in order to determine which frame each cluster container should be created on. This works fine normally, however if your trail loops back on itself or comes too close to where it was in world space at another point in the shot then the cluster gets confused as to which container should be used resulting in gaps in your trail. I've been trying to come up with a way to fix this procedurally but keep hitting dead ends. has anyone run into this issue before? Short of trying to convince animators to never have the characters loop back like this does anyone have any ideas on how to circumvent this problem? Thanks in advance, -Brandon