Found 132 posts.
Search results Show results as topic list.
PDG/TOPs » Scrolling frame range with TOP in SOP context is laggy.
- kenxu
- 544 posts
- Offline
It’s because the topnet is sops is always marked as time dependent - so it’ll serialize task graphs to disk no matter what. We’re looking to put some options on that node to allow better control of it.
PDG/TOPs » Is there a way to pick up a cooked result of PDG?
- kenxu
- 544 posts
- Offline
Yes, I think we're introducing some sort of visual feedback, so that if a workitems were marked cooked because it found its expected file already on disk, then that would be apparent.
PDG/TOPs » Caching a DOPnet fails ?
- kenxu
- 544 posts
- Offline
You need to turn on “all frames in one batch” in the rop fetch tab, as this is a simulation. If you don't have that on, it will launch the jobs randomly for each frame, and then do a run up for every frame - it will work, but super inefficient and not at all what you want.
PDG/TOPs » Context View suggestion for PDG
- kenxu
- 544 posts
- Offline
Thanks for the feedback! Yes, we need a better way of doing previews other than dropping down a file sop and then pointing it to @pdg_output (which is causing some confusion unfortunately for people to understand when to use @pdg_input and when to use @pdg_output - basically @pdg_output should only be used for previews). We are thinking about how to approach a more holistic preview framework, so this feedback definitely helps.
PDG/TOPs » Is there a way to pick up a cooked result of PDG?
- kenxu
- 544 posts
- Offline
Many of the nodes such as ROPFetch has a feature to look at the file it expects to find on disk - and if it does, it will automatically mark the workitem as cooked. We are doing a sweep to make sure this feature is available on as many nodes as possible. So hopefully, PDG will just pick up from where you left off, without you ever needing to do anything, even saving the task graph. This feature would only work if you stick to the @syntax in your output files, because PDG needs to figure out the expected output file, and it can only do that with the @syntax - so please do stick with that as much as possible.
PDG/TOPs » Rop Mantra Top / Overlaytext Top cook issues (17.5.214)
- kenxu
- 544 posts
- Offline
PDG/TOPs » Scrolling frame range with TOP in SOP context is laggy.
- kenxu
- 544 posts
- Offline
Possibly if the TOP is somehow triggering a simulation, and “all frames in 1 batch” is not turned on? Just guessing here, but a scene file would go a long way to helping sort this out.
PDG/TOPs » how to get an overview of threads per task?
- kenxu
- 544 posts
- Offline
I think there are a few possibilities around GPU. What you mentioned there is one, which we will certainly discuss more and follow up with you. The other possibility is to make PDG GPU aware, being able to send a kernel to the GPU, and create workitems at the level of workgroups in OpenCL - so effectively making the GPU a local “farm”. Would be good to get your feedback around that possibility as well.
PDG/TOPs » PDG and exporting to FBX
- kenxu
- 544 posts
- Offline
You can use a ROP Fetch node in TOPS to point to your ROP FBX node. In the output of the ROP FBX node, have something along the lines of path_to_output_dir/my_output_file_`@pdg_name`.fbx
Edited by kenxu - 2019年3月27日 21:14:44
PDG/TOPs » No input/output on TOPs nodes
- kenxu
- 544 posts
- Offline
PDG/TOPs » how to get an overview of threads per task?
- kenxu
- 544 posts
- Offline
The local scheduler is not currently thread aware. It just knows how many processes are running on the local machine, but has no insights into the inner workings of each process.
PDG/TOPs » How would you wedge multiparms?
- kenxu
- 544 posts
- Offline
Varying the number of multiparms might not be too bad, but filling in their contents would be more challenging - the multiparm instances would not even exist until runtime, and so we have no way yet to specify what should go in them before runtime. As a work around, would it work if you specified the maximum number of multiparms in the HDA, then proceed to fill in the contents with the regular @syntax for each instance?
PDG/TOPs » flipbook launch
- kenxu
- 544 posts
- Offline
I don't think we should automatically do that - it may not be an operation that's desired by everyone. If you truly desire it, consider doing a wait for all then run a command after that to launch the flipbook…
PDG/TOPs » Mantra startup time + PDG - [was Mantra geometry preparation]
- kenxu
- 544 posts
- Offline
The 1/4 was used as a heuristic to avoid overloading the machine by default. We had cases where the user tried to run way too much on a single machine: 80 sims each with 250 frames with each frame baking out 1 gig of data. To top it off the sims used opencl, which drained the graphics memory - drivers do not behave well under those conditions. To prevent situations like that, we opted for some very conservative settings. Feel free to up the number of CPUs used - just please keep in mind what you're asking the machine to do
PDG/TOPs » No input/output on TOPs nodes
- kenxu
- 544 posts
- Offline
Ooo, looks like there is some serious conflict going on in your system between your Houdini Python and your Maya Python. It's somehow picking up Maya's stuff. Check your paths, and environment variables like PYTHONHOME, PYTHONPATH, and maybe consider deleting your prefs?
PDG/TOPs » Status check if failed, automaticly recook
- kenxu
- 544 posts
- Offline
Yeah, I've this a few times myself, when we were trying to generate a lot of terrain data for ML. It's not TOPs, it's whatever process that TOPs is trying to run - in my case the failure rate was around 1/10000, and there is some bug we haven't caught in other parts of Houdini. If you want to be able to zero in on the problem, filter by expression is the recommended method. We'll look into an “auto-retry” type setting to handle occasionally glitchy child processes like your case.
PDG/TOPs » PDG Running On GPU cores
- kenxu
- 544 posts
- Offline
Simulations by themselves are inherently serial - you must simulate the previous frame before proceeding with the current frame. As such, the way we benefit from PDG in the case of sims is to unblock downstream sims or renders as soon as a frame is done. The original sim will not be made any faster by PDG. Any GPU ultization today is based on the tasks themselves - if it utilizes GPU, the task itself may complete faster.
That said, the topic of throwing a bunch of tasks at the GPU is a valid one. We do not yet support it, but is on our roadmap to look at.
That said, the topic of throwing a bunch of tasks at the GPU is a valid one. We do not yet support it, but is on our roadmap to look at.
PDG/TOPs » Unreal Engine not supported?
- kenxu
- 544 posts
- Offline
We have to meet internally about dev priorities soon. We’re hearing lots of demand for this though - thumbs up here to vote for this - it will further inform our decisions.
PDG/TOPs » Delete all sources after creating a MP4
- kenxu
- 544 posts
- Offline
Ok, in that case maybe have a final step to copy your final file somewhere else, the RMB at the root of the PDG graph, and choose “Delete Selected Node Results From Disk”. This should get rid all files that have been produced.
PDG/TOPs » TOP HDA Processor not working in Apprentice version?
- kenxu
- 544 posts
- Offline
Yes, that's the only one that doesn't work - because it currently requires Houdini Engine and that's not available for Apprentice.
-
- Quick Links