# Evaluate a parameter with no work item self['example'].evaluateInt() # Evaluate at a specific index self['example'].evaluateInt(2) # Evaluate the parameter against a specific work item. This is needed if you want @attribute expressions to be evalauted. new_item = itemholder.addWorkItem() self['other_example'].evaluateString(new_item) # Specified work item and index self['other_example'].evaluateString(new_item, 1)
Found 438 posts.
Search results Show results as topic list.
PDG/TOPs » Set spare parameters from Python Processor Node
- tpetrick
- 585 posts
- Offline
Yep, it's possible to add spare parms to any TOP node. For example, in Python Processor code you can evaluate any params on the node, including spare parms, like so:
PDG/TOPs » Q: Wedging preserving original value implemented?
- tpetrick
- 585 posts
- Offline
That particular case will be fixed in tomorrow's build. The Wedge TOP now tracks the target parameter/captured value type separately from the attribute type - before it was assuming that they matched, which caused some issues.
PDG/TOPs » Get multi digit/index @wedgenum with "Preserve Wedge Numbers"
- tpetrick
- 585 posts
- Offline
Can you attach a .hip file that demonstrates the issues you have with the random samples?
PDG/TOPs » Q: Wedging preserving original value implemented?
- tpetrick
- 585 posts
- Offline
You're using it correctly. It looks like I mixed up a backport to 17.5, which I've fixed now.
PDG/TOPs » Q: Wedging preserving original value implemented?
- tpetrick
- 585 posts
- Offline
PDG/TOPs » $JOB/$HIP variable not correctly evaluating with rop?
- tpetrick
- 585 posts
- Offline
$HIP should work fine - that's what all of the example files use, and what the default value contains. There was bug with $JOB being overwritten incorrectly by the job script that evaluates the ROP, though. That issue will be fixed in tomorrow's daily build.
Edited by tpetrick - 2019年5月8日 15:43:11
PDG/TOPs » ResultData (@pdg_input) - can't evaluate expressions.
- tpetrick
- 585 posts
- Offline
PDG/TOPs » Q: Wedging preserving original value implemented?
- tpetrick
- 585 posts
- Offline
A solution that uses the stash/restoring on the Wedge TOP has already been implemented. We're just testing it internally, and I aim to have it available in 17.5 in the next few days. It works as follows:
When selecting a target parameter for a wedge entry, the value of that parameter is automatically stashed on the Wedge TOP. This is done so that the value isn't lost if the work items are dirtied, for example. The Wedge TOP has buttons to manually restash the value, restore the value for a particular parameter, or restore all values accross all wedge entries.
When selecting a work item, the target parameter value(s) are overwritten by the wedged values on that work item. When the work item is deselected they're automatically restored from the value(s) stashed on the wedge node itself.
When selecting a target parameter for a wedge entry, the value of that parameter is automatically stashed on the Wedge TOP. This is done so that the value isn't lost if the work items are dirtied, for example. The Wedge TOP has buttons to manually restash the value, restore the value for a particular parameter, or restore all values accross all wedge entries.
When selecting a work item, the target parameter value(s) are overwritten by the wedged values on that work item. When the work item is deselected they're automatically restored from the value(s) stashed on the wedge node itself.
Edited by tpetrick - 2019年5月6日 17:04:46
PDG/TOPs » Q: Wedging preserving original value implemented?
- tpetrick
- 585 posts
- Offline
Wedging with TOPs was designed around the idea that the the value(s) that matter are described by the Wedge node itself, not specified in the nodes being wedged. For example the “real” value might be set as the center value in the Center/Offset wedging mode, or specified among the list of values using the Value List multiparm.
We've discussed the value restoring issue quite a bit internally, and I don't think it's feasible for us to integrate the overriding mechanism used by CHOPs with TOPs. One thing that could be done is to stash the “original” value somewhere. Work item selection could, for example, save the current value of the target parm to an attribute and then restore it back on de-selection. Alternatively, the target parm value could be saved to the wedge TOP itself when the target parameter field is set, with a button to re-capture the target parm value on demand and a button to restore defaults.
We've discussed the value restoring issue quite a bit internally, and I don't think it's feasible for us to integrate the overriding mechanism used by CHOPs with TOPs. One thing that could be done is to stash the “original” value somewhere. Work item selection could, for example, save the current value of the target parm to an attribute and then restore it back on de-selection. Alternatively, the target parm value could be saved to the wedge TOP itself when the target parameter field is set, with a button to re-capture the target parm value on demand and a button to restore defaults.
PDG/TOPs » Scrolling frame range with TOP in SOP context is laggy.
- tpetrick
- 585 posts
- Offline
PDG/TOPs » Sequential DOPs workflow
- tpetrick
- 585 posts
- Offline
You don't need a mapper. I've attached a simple example with two “sims” that are just writing out/coloring geometry, but the TOP graph structure should be the same.
PDG/TOPs » Run bash command in terminal using PDG
- tpetrick
- 585 posts
- Offline
The Generic Generator node lets you run any executable that's on your PATH as a work item. If you want to actually use the shell itself, e.g. for piping between several executables, you'll need to run it with /bin/sh (or your shell of choice). For example, setting a Generic Generator's command field to /bin/sh -c “ls -la | grep *.txt”.
In you case though, you probably just want something like deadlineslave -nogui -name “somename”, which would work fine as long as the deadlineslave executable can be found on the PATH.
In you case though, you probably just want something like deadlineslave -nogui -name “somename”, which would work fine as long as the deadlineslave executable can be found on the PATH.
PDG/TOPs » Sequential DOPs workflow
- tpetrick
- 585 posts
- Offline
The second ROP should be set to “Single Frame” instead of “Frame Range”. In general, the parms on the TOP node describe what to do for each incoming work item. If you have a ROP node with 100 frames, and you want the next node to create 1 frame per incoming frame, the “Single Frame” will do what you're looking for. For example, rendering a sim's output with a ROP Mantra.
If you want to use some subset of the upstream frame range in the second ROP Geometry, you could put a Filter by Expression node between the first and second ROP node - in your case, I think the expression would be @pdg_frame > 1050, to filter out work items with a frame value larger than that.
If you want to use some subset of the upstream frame range in the second ROP Geometry, you could put a Filter by Expression node between the first and second ROP node - in your case, I think the expression would be @pdg_frame > 1050, to filter out work items with a frame value larger than that.
Edited by tpetrick - 2019年4月10日 16:31:58
PDG/TOPs » Running Houdiniservers in sequence
- tpetrick
- 585 posts
- Offline
Can you attach a .hip file that demonstrates that issue? The Feedback Begin and various command chain begin nodes should be maintaining the attributes from input work items. I've attached an example file that cooks work items sequentially using both the feedback block and a Houdini command chain. Attributes from the input work items are preserved on the items in the loop block.
Edited by tpetrick - 2019年4月10日 11:02:24
PDG/TOPs » Export multiple FBX from SOP result
- tpetrick
- 585 posts
- Offline
PDG/TOPs » Export multiple FBX from SOP result
- tpetrick
- 585 posts
- Offline
The geometry import currently can't create work items from piece attributes, but it can create them from groups. If you're able to put in each of the pieces of geometry into its own group, you can set the geometry import's class to Primitives, and “Create Work Item For” to “All Groups”. That will create a work item for each group in the geometry, which can then be used to drive a ROP Alembic TOP node to write out the geometry.
PDG/TOPs » Work Item using Named Primitive in Geometry Import
- tpetrick
- 585 posts
- Offline
Not at the moment - there's an RFE for that already, though.
Edited by tpetrick - 2019年3月28日 18:01:51
PDG/TOPs » Can't figure out how to use TOPS with caching preroll and rendering a smaller shot range.
- tpetrick
- 585 posts
- Offline
You can use an Attribute Create to set the frame range attribute on the work items, before the node that creates the batches. When operating in batch mode, the ROP Fetch nodes use the incoming work item's frame and frame range to figure out how big the batch should be.
This is maybe something that should be configurable on the node - we'll look into that on our end.
This is maybe something that should be configurable on the node - we'll look into that on our end.
PDG/TOPs » tractor emtpy string argument issues
- tpetrick
- 585 posts
- Offline
I've fixed the ROP Fetch node so that it doesn't pass that argument when the value is empty string, which should fix this specific case. We'll be applying a fix for the Tractor Scheduler itself as well, but tomorrows build will definitely have the ROP-specific fix.
Edited by tpetrick - 2019年3月26日 14:20:02
PDG/TOPs » how to get an overview of threads per task?
- tpetrick
- 585 posts
- Offline
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]
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]
-
- Quick Links