Found 132 posts.
Search results Show results as topic list.
PDG/TOPs » PDG Assuming for hip, should support hipnc for schools?
- kenxu
- 544 posts
- Offline
Sorry about that…but glad to see you've found a work-around. I've logged Bug 98923 to address this.
PDG/TOPs » Command Chain problems due to Python Script Node
- kenxu
- 544 posts
- Offline
It's probably because the Python script node's workitem generation is actually dynamic by default, when it's on automatic (we have a bug to fix this). Once a node is dynamic, the rest of the graph becomes dynamic, which may be what's messing things up here. Try explicitly setting the workitem generation to “static”.
PDG/TOPs » Text overlay Attributes/output size(file size) and cook times(render times)
- kenxu
- 544 posts
- Offline
Hi there,
So I've fixed the python script node part of the graph, it was using the wrong syntax:
# Print Work Item Name, Index and Attribute
print “name: ” + work_item.name
print “index: ” + str(work_item.index)
attrib = floatData(work_item, “scale”)
if attrib:
print “attrib: ” + str(attrib)
However, I couldn't get any further with the rest of the cook because it needs Arnold render and we don't have that installed here. So far as we can tell, you are doing it right in the ROP Composite node:
Frame Number $F
scale = `@scale`
parameter = `@scalechannel`
Can you maybe give us a test file that doesn't use Arnold (eg. Mantra)? We can then get further with helping you.
So I've fixed the python script node part of the graph, it was using the wrong syntax:
# Print Work Item Name, Index and Attribute
print “name: ” + work_item.name
print “index: ” + str(work_item.index)
attrib = floatData(work_item, “scale”)
if attrib:
print “attrib: ” + str(attrib)
However, I couldn't get any further with the rest of the cook because it needs Arnold render and we don't have that installed here. So far as we can tell, you are doing it right in the ROP Composite node:
Frame Number $F
scale = `@scale`
parameter = `@scalechannel`
Can you maybe give us a test file that doesn't use Arnold (eg. Mantra)? We can then get further with helping you.
PDG/TOPs » PDG output multiple objects to a FBX file , help !
- kenxu
- 544 posts
- Offline
Hey guys, in H18, we have a “batchable” version of the HDA Processor, that spins up once, then is able to process multiple workitems without tearing the session down. In our recent tests it's about 10x faster for a lot of loads. Perhaps this would offer a way to do this more efficiently.
PDG/TOPs » Wedge node changing viewport lighting
- kenxu
- 544 posts
- Offline
Hi there,
The OpenGL ROP does not use any of the settings of the active viewports. That said, there are some settings you can wedge, in particular in the display options section of the OpenGL ROP.
The OpenGL ROP does not use any of the settings of the active viewports. That said, there are some settings you can wedge, in particular in the display options section of the OpenGL ROP.
PDG/TOPs » Accessing PDG Wedges when instancing / copy_to_points
- kenxu
- 544 posts
- Offline
Hi Tim,
Sorry for the late reply. It's a little hard to follow based on just your description above. Could you kindly submit a file to us? We'll analyze it and get back to you.
Sorry for the late reply. It's a little hard to follow based on just your description above. Could you kindly submit a file to us? We'll analyze it and get back to you.
PDG/TOPs » ERROR: Cannot find node /obj/topnet2/ropmantra1/ropnet1/mantra1
- kenxu
- 544 posts
- Offline
PDG/TOPs » Batch renders with Arnold using PDG
- kenxu
- 544 posts
- Offline
This sounds more like a shader issue than a PDG issue. I’ve pointed your question at our rendering folks, but with SIGGRAPH on our door steps please expect some delays in our reply.
Edited by kenxu - July 27, 2019 10:01:42
PDG/TOPs » Please file RFEs / BUGs for us :)
- kenxu
- 544 posts
- Offline
Hi everyone,
We'd like to ask a bit of help from you to help us deal with the volume of requests a little better. Right now, as issues are raised on the fourm, whether it is a BUG or an RFE, we are spending a significant chunk of time just translating those issues into BUGs and RFEs so that we are logging them and keeping track of them. However, that time is probably better spent actually fixing those BUGs and RFEs instead of just logging it. As issues are raised, if you guys could please log the issues using the BUG DB for us, it would save us a lot “paper work” and thus help give us more cycles to addressing the issues. Please make sure the product is set to “PDG” for PDG issues.
Thanks in advance for your help!
We'd like to ask a bit of help from you to help us deal with the volume of requests a little better. Right now, as issues are raised on the fourm, whether it is a BUG or an RFE, we are spending a significant chunk of time just translating those issues into BUGs and RFEs so that we are logging them and keeping track of them. However, that time is probably better spent actually fixing those BUGs and RFEs instead of just logging it. As issues are raised, if you guys could please log the issues using the BUG DB for us, it would save us a lot “paper work” and thus help give us more cycles to addressing the issues. Please make sure the product is set to “PDG” for PDG issues.
Thanks in advance for your help!
PDG/TOPs » PDG Master class posted
- kenxu
- 544 posts
- Offline
Thank you everyone for your thoughtful comments and contributions so far. Addressing some of the points above in no particular order:
- Mappers - yes, there will be a more detailed and practical talk around this. We plan to deliver the talk at Siggraph at our Houdini Hive, and record it for distribution shortly after. Will post about it here once it's live. I only had enough time in this first master class to introduce the concept. The short takeway: use mappers to model manual operations. The manual edits made using mappers can persist even as the upstream procedural stuff changes.
- Loss of attributes of workitems being mapped to: because mappers are more of an advanced topic, they are a bit less developed overall and has less of the built-in niceties as compared to partitioners. This will get stronger as we continue to develop. There is an RFE to do add that support.
- HDA processor pooling - As we're still shoring up various aspects of PDG, sometimes we slip up and introduce a regression. We are aware of a problem here. It is fixed on Windows but we're still trying to get to it for Linux.
- More tutorials to cover more use cases - yes we hear you. As mentioned above another one is coming at Sig, and we've got more in the pipe, no pun intended . This thing has such a huge scope that it's a difficult task to just showcase and teach all the areas that it touches. This is made even tougher as we try to balance client support with needed patches in key areas with forward development. We're on it though, and will commit to delivering more material steadily.
- Big thanks for the additional tutorial topic suggestions above. Very good points and we'll take that into consideration as we plan the next tutorials.
- Mappers - yes, there will be a more detailed and practical talk around this. We plan to deliver the talk at Siggraph at our Houdini Hive, and record it for distribution shortly after. Will post about it here once it's live. I only had enough time in this first master class to introduce the concept. The short takeway: use mappers to model manual operations. The manual edits made using mappers can persist even as the upstream procedural stuff changes.
- Loss of attributes of workitems being mapped to: because mappers are more of an advanced topic, they are a bit less developed overall and has less of the built-in niceties as compared to partitioners. This will get stronger as we continue to develop. There is an RFE to do add that support.
- HDA processor pooling - As we're still shoring up various aspects of PDG, sometimes we slip up and introduce a regression. We are aware of a problem here. It is fixed on Windows but we're still trying to get to it for Linux.
- More tutorials to cover more use cases - yes we hear you. As mentioned above another one is coming at Sig, and we've got more in the pipe, no pun intended . This thing has such a huge scope that it's a difficult task to just showcase and teach all the areas that it touches. This is made even tougher as we try to balance client support with needed patches in key areas with forward development. We're on it though, and will commit to delivering more material steadily.
- Big thanks for the additional tutorial topic suggestions above. Very good points and we'll take that into consideration as we plan the next tutorials.
Edited by kenxu - July 21, 2019 16:08:47
PDG/TOPs » [ISSUE] ImageMagick - can't montage single images ("{image}" is only accessible by convert operation)
- kenxu
- 544 posts
- Offline
Hi there, sorry for the late response. Our team member in charge of this feature is out on vacation this week. We’ll take look as he returns.
PDG/TOPs » RFE discussion: ffmpeg utility
- kenxu
- 544 posts
- Offline
Agreed here as well. Some of these stock nodes needs another pass. We’ll take a look at this request before H18.
PDG/TOPs » PDG Master class posted
- kenxu
- 544 posts
- Offline
https://www.sidefx.com/tutorials/pdg-core-concepts/#comment-4380 [www.sidefx.com]
The first of several to come. Next planned ones are:
Schedulers:
A) How to deploy with Tractor
B) How to deploy with Deadline
C) How to deploy with HQueue
D) How to write your own binding
API
- A deep dive on the PDG API.
Please let us what further questions / topics we could address beyond those above.
The first of several to come. Next planned ones are:
Schedulers:
A) How to deploy with Tractor
B) How to deploy with Deadline
C) How to deploy with HQueue
D) How to write your own binding
API
- A deep dive on the PDG API.
Please let us what further questions / topics we could address beyond those above.
PDG/TOPs » few more questions [updated]
- kenxu
- 544 posts
- Offline
Hi Eric,
You can use the invoke node to run any SOP compile block in process. That's probably the best bet in terms of running something in process in order to manipulate geometry.
The other way to run something in process, as you know, is the Python script node. At some point in the future we'll get a C++ API to PDG, and that'll allow you to write more in process code - however, even then, it's unlikely you can just call into any geometry code - not all our geometry code is thread safe. Those that have been made thread safe are already available as SOP verbs and you can put those in compile blocks and already call into them via the invoke node as mentioned above.
You can use the invoke node to run any SOP compile block in process. That's probably the best bet in terms of running something in process in order to manipulate geometry.
The other way to run something in process, as you know, is the Python script node. At some point in the future we'll get a C++ API to PDG, and that'll allow you to write more in process code - however, even then, it's unlikely you can just call into any geometry code - not all our geometry code is thread safe. Those that have been made thread safe are already available as SOP verbs and you can put those in compile blocks and already call into them via the invoke node as mentioned above.
PDG/TOPs » few more questions [updated]
- kenxu
- 544 posts
- Offline
Hi Andr,
Sorry for the late reply on this topic. There is quite a number of issues to address and it took us a little bit to sync up on all the issues. Anyway, answers / further discussion below:
1. This likely due to the overhead of spinning up a hython session. The ROP geometry is running out of process, whereas the geometry import node can depending on its setting, be running in process.
2. This is either a bug or due to the fact that PDG node does not exist until TOPs graph gets cooked in some way to generate it. If you do Tasks -> Generate Static Workitems, and try again - does it still happen? If so, it's a bug and please upload a scene. If not, then it's due the the previously mentioned artifact - PDG is kept separate from TOPs so it can be detached in the future from Houdini and deployed completely independently.
3. Yes, those functions require the unique ID of the workitem. Index is not enough because it is not unique.
4. Consider using a merge node, along with a file SOP pointing to `@pdg_output` to visualize the output of a workitem or else use `@pdg_input` to visualize the input to a workitem, when you select the workitem.
5. I've logged Bug 98079
6. Only the invoke and geometry import can access the raw geometry at the moment.
7. Not at the moment. I've logged RFE 98081 to track it.
8. You can find it documented here: https://www.sidefx.com/docs/houdini/tops/pdg/PartitionHolder.html?origin_team=T045BRUUR [www.sidefx.com]
9. Likely a bug, we'll look into it further. Let us know if this is urgent, we'll try to look at it sooner in that case.
Sorry for the late reply on this topic. There is quite a number of issues to address and it took us a little bit to sync up on all the issues. Anyway, answers / further discussion below:
1. This likely due to the overhead of spinning up a hython session. The ROP geometry is running out of process, whereas the geometry import node can depending on its setting, be running in process.
2. This is either a bug or due to the fact that PDG node does not exist until TOPs graph gets cooked in some way to generate it. If you do Tasks -> Generate Static Workitems, and try again - does it still happen? If so, it's a bug and please upload a scene. If not, then it's due the the previously mentioned artifact - PDG is kept separate from TOPs so it can be detached in the future from Houdini and deployed completely independently.
3. Yes, those functions require the unique ID of the workitem. Index is not enough because it is not unique.
4. Consider using a merge node, along with a file SOP pointing to `@pdg_output` to visualize the output of a workitem or else use `@pdg_input` to visualize the input to a workitem, when you select the workitem.
5. I've logged Bug 98079
6. Only the invoke and geometry import can access the raw geometry at the moment.
7. Not at the moment. I've logged RFE 98081 to track it.
8. You can find it documented here: https://www.sidefx.com/docs/houdini/tops/pdg/PartitionHolder.html?origin_team=T045BRUUR [www.sidefx.com]
9. Likely a bug, we'll look into it further. Let us know if this is urgent, we'll try to look at it sooner in that case.
PDG/TOPs » hou.perfMon + PDG?
- kenxu
- 544 posts
- Offline
The performance monitor is currently set up to measure the sum of all workitem times within a processor. It is not set to use wall clock time - which, arguably may be more useful. We have an RFE for that.
However, what you are wanting to do seems to be just accessing each of the workitem's cook time, of which there should be an attribute on the workitem that you can access.
However, what you are wanting to do seems to be just accessing each of the workitem's cook time, of which there should be an attribute on the workitem that you can access.
PDG/TOPs » Preview problem
- kenxu
- 544 posts
- Offline
Visualization options are a bit lacking in TOPs right now. There is a way to do it, but it has to be manual at the moment. Put down a file SOP, and in the file field put:
`@pdg_output` to visualize the output of the current selected workitem.
Set it to
`@pdg_input` to visualize the input to the current selected workitem.
The node view flag only controls which node PDG cooks down to, if you choose Tasks -> Cook Output Node.
`@pdg_output` to visualize the output of the current selected workitem.
Set it to
`@pdg_input` to visualize the input to the current selected workitem.
The node view flag only controls which node PDG cooks down to, if you choose Tasks -> Cook Output Node.
PDG/TOPs » Switching/Bypassing
- kenxu
- 544 posts
- Offline
Yes, we know we're still short on training material. Two are in the works, a master class that should drop within days, and another demo in time for Siggraph. We'll continue to work on them - it's a fairly deep technology with a lot of things to point out.
PDG/TOPs » Extracting and Referencing the String Text of Input/Output File Path from TOP Network
- kenxu
- 544 posts
- Offline
PDG/TOPs » How-to combine a variable amount of geometryimport?
- kenxu
- 544 posts
- Offline
Hi Andr,
In the short run, the work-around option 2) is the best. In the medium term, we'll get the “attribute promote” node added so that this becomes standard functionality and you don't need to roll your own.
WRT the prints, it's expected, as PDG is a fundamentally asynchronous technology. Everything from the way it farms out work to the graph evaluation itself is asynchronous. On the upside is the ability to scale, but the downside is messy prints
In the short run, the work-around option 2) is the best. In the medium term, we'll get the “attribute promote” node added so that this becomes standard functionality and you don't need to roll your own.
WRT the prints, it's expected, as PDG is a fundamentally asynchronous technology. Everything from the way it farms out work to the graph evaluation itself is asynchronous. On the upside is the ability to scale, but the downside is messy prints
-
- Quick Links