To add to that, most of the nodes do their work out of process not in the current Houdini session. For example, the ROP Fetch spawns a Hython process that evaluates the target ROP node. Those external processes have their thread count set when they're spawned by the scheduler, and it will not change dynamically as the process runs.
The CPUs per Job and Maximum Processes settings on the Local Scheduler are used to determine how many jobs to run at the same time. A lengthier explanation was written here: https://www.sidefx.com/forum/topic/61771/ [www.sidefx.com]
Found 439 posts.
Search results Show results as topic list.
PDG/TOPs » how to get an overview of threads per task?
- tpetrick
- 586 posts
- Offline
PDG/TOPs » PDG for whitewater sims
- tpetrick
- 586 posts
- Offline
The second ROP Geometry node probably needs to be set to “Single Frame” instead of “Frame Range”. If it's set to single frame, it'll generate 1 work item per input work item. If it's set up frame range, it'll generate a range of work items for each item. This pattern is followed by most nodes - the TOP node will apply the operation defind by the parameters for each input work item.
If you're doing a simulation, you'll need to go to the ROP Fetch tab and turn on “All frames in one batch”, so they get submitted as a single job.
If you're doing a simulation, you'll need to go to the ROP Fetch tab and turn on “All frames in one batch”, so they get submitted as a single job.
PDG/TOPs » Sop Simple Baker -
- tpetrick
- 586 posts
- Offline
I think the problem with the simple baker is that it has a node that writes a temporary file to disk, e.g. to /tmp on Linux. If you're running multiple PDG jobs at the same time that temporary file gets overwritten by different copies of the baker, causing most of the jobs to fail or produce incorrect results.
The work around on the PDG side is to mark the jobs in that node as “single”, which means that only one job for the node will run at the same time. This can be done by going to the “Schedulers” tab, enabling the “Local Scheduler” overrides, and toggling on the “Single” parameter.
The real fix is for the SOP Simple Baker tool to make the temp file path configurable on the asset, so that it can be changed on a per job basis.
The work around on the PDG side is to mark the jobs in that node as “single”, which means that only one job for the node will run at the same time. This can be done by going to the “Schedulers” tab, enabling the “Local Scheduler” overrides, and toggling on the “Single” parameter.
The real fix is for the SOP Simple Baker tool to make the temp file path configurable on the asset, so that it can be changed on a per job basis.
Edited by tpetrick - 2019年3月20日 12:02:37
PDG/TOPs » Delete all sources after creating a MP4
- tpetrick
- 586 posts
- Offline
One option that would work out-of-the-box is to write all of the files you want to discard to a different directory, and have the Remove File node remove that directory. PDG already creates as session-specific temporary directory which can be accessed with the $PDG_TEMP variable - this is where log files and scripts created by PDG are written, among other things. Scheduler nodes have a right mouse button entry for deleting that directory manually, but $PDG_TEMP can also be used as the path in a Remove File node. You could of course use your own though, e.g. something like $HIP/tempfiles/…
Alternatively, something like the following would also work:
I have two wait for all nodes - the first one waits for the work items that I want to keep, and the second one has the nodes that produced intermediate files that should be deleted. The attribute delete after the first wait for all is there to delete the Output attribute. Then, there's a third wait for all which depends on both branches, and a Remove File configured to delete all of the files on the work item in the third wait for all. This setup ensures that the delete step isn't run until after everything else is cooked, and the delete step will also not touch any of the files from the left branch.
There are pros and cons to both approaches. If your work items produce files that aren't reported to PDG, the Remove File node will never find out about them so they won't be cleaned up. In that case using a pre-determined temporary directory is more reliable since the clean up step will always remove the entire directory. The second approach gives you more explicit control and makes it easier to move nodes between the “keep” and “discard” lists, but will end up with a lot of node wires in larger graphs. The second approach can also be bundled into an asset more easily, and maybe should be a “Cleanup” TOP node that we ship with Houdini.
Alternatively, something like the following would also work:
I have two wait for all nodes - the first one waits for the work items that I want to keep, and the second one has the nodes that produced intermediate files that should be deleted. The attribute delete after the first wait for all is there to delete the Output attribute. Then, there's a third wait for all which depends on both branches, and a Remove File configured to delete all of the files on the work item in the third wait for all. This setup ensures that the delete step isn't run until after everything else is cooked, and the delete step will also not touch any of the files from the left branch.
There are pros and cons to both approaches. If your work items produce files that aren't reported to PDG, the Remove File node will never find out about them so they won't be cleaned up. In that case using a pre-determined temporary directory is more reliable since the clean up step will always remove the entire directory. The second approach gives you more explicit control and makes it easier to move nodes between the “keep” and “discard” lists, but will end up with a lot of node wires in larger graphs. The second approach can also be bundled into an asset more easily, and maybe should be a “Cleanup” TOP node that we ship with Houdini.
Edited by tpetrick - 2019年3月18日 16:51:03
PDG/TOPs » API Docs
- tpetrick
- 586 posts
- Offline
The API docs can be found here: https://www.sidefx.com/docs/houdini/tops/pdg/index.html [www.sidefx.com]
PDG/TOPs » Merged Wedged Output to a single Mantra Task [SOLVED]
- tpetrick
- 586 posts
- Offline
Your Mantra node should have it's Evaluating Using parameter set to “Single Frame” instead of “Frame Range”. Single frame means it'll create a single mantra render work item for each of the input partitions.
Edited by tpetrick - 2019年3月15日 16:10:32
PDG/TOPs » No Pre-Render/Post-Render script for Geometry Top node?
- tpetrick
- 586 posts
- Offline
TOPs currently makes use of the pre/post callbacks itself, which is why they're not exposed on the TOP nodes. This is something we intend to fix, though.
There is also a Python Script TOP node which generates work items that run user-defined Python code. If you wire a ROP Geometry TOP into a Python Script TOP, the script node will create one work item for each item in the ROP Geometry TOP. You can use this to run post frame logic, for example.
There is also a Python Script TOP node which generates work items that run user-defined Python code. If you wire a ROP Geometry TOP into a Python Script TOP, the script node will create one work item for each item in the ROP Geometry TOP. You can use this to run post frame logic, for example.
PDG/TOPs » Data is not passing in 'Static' workitem generation
- tpetrick
- 586 posts
- Offline
When work items statically, your node has access to the full list of upstream work items. You need to tell PDG which upstream item is the parent of the item you're creating. For example:
When generating dynamically there's always exactly 1 upstream item, so PDG is able to determine the parent item on its own.
for item in upstream_items: new_item = item_holder.addWorkItem(parent=item)
When generating dynamically there's always exactly 1 upstream item, so PDG is able to determine the parent item on its own.
Edited by tpetrick - 2019年3月15日 11:03:31
Technical Discussion » Anyway to increase mouse cursor size in windows high dpi display?
- tpetrick
- 586 posts
- Offline
Technical Discussion » Event Trigger for python callback on drag and drop
- tpetrick
- 586 posts
- Offline
Houdini has a script hook for external drag/drop, but currently only file path data is supported.
To use the script hook add a Python script named externaldragdrop.py to the Houdini script path, for example ~/houdini16.5/scripts/externaldragdrop.py. The script should define a function called dropAccept which takes a single parameter. Every time a drop event occurs on the main Houdini application it will call the dropAccept function with a list of file path(s) that were dropped onto Houdini. The function can return True to block the drop event from continuing on to Houdini, or False to indicate that Houdini should handle the drop event itself.
An example drop handler script that ignores .hip file drops and creates Font SOPs with the contents of the incoming files:
If the data in the drag/drop event contains arbitary text or binary data instead of file paths the script hook won't be invoked. This is something that would need to be fixed on our end - I can look into fixing that if necessary.
To use the script hook add a Python script named externaldragdrop.py to the Houdini script path, for example ~/houdini16.5/scripts/externaldragdrop.py. The script should define a function called dropAccept which takes a single parameter. Every time a drop event occurs on the main Houdini application it will call the dropAccept function with a list of file path(s) that were dropped onto Houdini. The function can return True to block the drop event from continuing on to Houdini, or False to indicate that Houdini should handle the drop event itself.
An example drop handler script that ignores .hip file drops and creates Font SOPs with the contents of the incoming files:
import hou import os def dropAccept(file_list): if len(file_list) == 1 and os.path.splitext(file_list[0])[1] == ".hip": return False for filename in file_list: with open(filename) as f: contents = f.read() obj = hou.node("/obj") geo = obj.createNode("geo", "geo1", False, False) font = geo.createNode("font") font.parm("text").set(contents[:20]) return True
If the data in the drag/drop event contains arbitary text or binary data instead of file paths the script hook won't be invoked. This is something that would need to be fixed on our end - I can look into fixing that if necessary.
Technical Discussion » Houdini has full python PIL module or it is minimal?
- tpetrick
- 586 posts
- Offline
This should now be fixed in the PIL module shipped with Houdini, in the latest build of 16.0 and 16.5.
Technical Discussion » Houdini has full python PIL module or it is minimal?
- tpetrick
- 586 posts
- Offline
It looks like the PIL library isn't being packaged properly in the Windows build of Houdini. The version of PIL that's shipped with Houdini is missing some of the PIL/FreeType libraries, which are needed to load in font files. I'll look into fixing that issue on our end.
In the mean time, it might be possible to use your non-Houdini version of PIL with Houdini by adding it to the Python module search path. For example, you can try doing the following at the top of your script:
Note that this will only work if your system's version of PIL and its dependencies are compatible with the version of Python used by Houdini. I'm not sure if this will be the case.
In the mean time, it might be possible to use your non-Houdini version of PIL with Houdini by adding it to the Python module search path. For example, you can try doing the following at the top of your script:
# Insert the path to PIL on your system before other entries in the search path, to make sure it's picked up first import sys sys.path.insert(0, "path to your Windows PIL installation") # Import PIL modules from PIL import Image, ImageDraw, ImageFont ...
Note that this will only work if your system's version of PIL and its dependencies are compatible with the version of Python used by Houdini. I'm not sure if this will be the case.
Technical Discussion » Is there an alternative to hou.IPRViewer.pixel("C", x, y)
- tpetrick
- 586 posts
- Offline
Cool video!
The new Python method “hou.IPRViewer.pixels('image_plane')” is available in last night's 16.0 build - if needed, I can backport to 15.5 as well. The method works more or less the same as the existing “hou.IPRViewer.pixel(..)” call, however it isn't restricted to a particular (x,y) coordinate. It takes an image plane name as a parameter, and returns all of the image data as a tuple of float tuples, in row major order. Result is the pixel value at (0,0), result is the image data for (1,0), etc. Data starts from the bottom left corner of the IPR render result, like the other IPR inspection tools.
For example:
The new Python method “hou.IPRViewer.pixels('image_plane')” is available in last night's 16.0 build - if needed, I can backport to 15.5 as well. The method works more or less the same as the existing “hou.IPRViewer.pixel(..)” call, however it isn't restricted to a particular (x,y) coordinate. It takes an image plane name as a parameter, and returns all of the image data as a tuple of float tuples, in row major order. Result is the pixel value at (0,0), result is the image data for (1,0), etc. Data starts from the bottom left corner of the IPR render result, like the other IPR inspection tools.
For example:
width = viewer.imageResolution()[0] color_pixels = viewer.pixels("C") pixel_200x300 = color_pixels[width*200 + 300]
Technical Discussion » Is there an alternative to hou.IPRViewer.pixel("C", x, y)
- tpetrick
- 586 posts
- Offline
Hi Daniel,
It looks like there currently isn't a way to access the entire RGBA image with a single hou method. I've created an RFE to add one (RFE #82333), and will see if I can implement it this week.
Taylor
It looks like there currently isn't a way to access the entire RGBA image with a single hou method. I've created an RFE to add one (RFE #82333), and will see if I can implement it this week.
Taylor
Technical Discussion » When the Global UI Size is set to "Large" the radial menu icons become broken
- tpetrick
- 586 posts
- Offline
I was able to reproduce similar visual issues on my high dpi Linux system, and put in a fix for it this afternoon. Can you try tomorrow's build (16.0.550) and see if it also fixes the problem for you?
Edited by tpetrick - 2017年3月16日 16:02:04
Technical Discussion » Some Qt questions
- tpetrick
- 586 posts
- Offline
Alexey,
Can you try adding the following method to your Python Panel script:
def dragEnterEvent(self, event):
event.acceptProposedAction()
That block of code was needed to make the example work on my machine. Also, which platform are you currently using? I'm working through some drag and drop bugs on OS X so if you're on the platform drag and drop may not work as expected.
Can you try adding the following method to your Python Panel script:
def dragEnterEvent(self, event):
event.acceptProposedAction()
That block of code was needed to make the example work on my machine. Also, which platform are you currently using? I'm working through some drag and drop bugs on OS X so if you're on the platform drag and drop may not work as expected.
Technical Discussion » Some Qt questions
- tpetrick
- 586 posts
- Offline
Getting the Houdini stylesheet from the QApplication instance should be safe in both PySide and C++ code. We don't currently have a method for directly querying Houdini's style sheet directly. The stylesheet is generated at runtime based on the current colour settings and a base stylesheet.
If you're working in C++, you can also use QT_Utils::applyWidgetStyleSheets(QWidget*) to apply the Houdini style sheet to a QWidget. Note that this will overwrite any style sheets currently set on the QWidget.
If you're working in C++, you can also use QT_Utils::applyWidgetStyleSheets(QWidget*) to apply the Houdini style sheet to a QWidget. Note that this will overwrite any style sheets currently set on the QWidget.
Technical Discussion » Houdini 14 and Wacom | klick problem
- tpetrick
- 586 posts
- Offline
Technical Discussion » Some Qt questions
- tpetrick
- 586 posts
- Offline
Calling setStyleSheet in Python Panels should work as expected in tomorrow's build. Since we're using stylesheets, QFont and QPalette values are ignored automatically by Qt.
I'll take look at the QGroupBox and QTextEdit styling issues you mentioned.
I'll take look at the QGroupBox and QTextEdit styling issues you mentioned.
-
- Quick Links