PDG 101 – Pt.2: Wedging by Christopher Kopic 05.11.2020 comments 7 Part of: PDG 101 PDG 101 automatisation, automatization, batch, PDG, processing, wedging To view this content, you must be a member of Entagma's Patreon at $29 or more Unlock with Patreon
very useful stuff, Thank you very much
Hey Christian, I have general pdg question,
When I set the Local Scheduler to use CPU Count Less One it will use one core to render each frame of something, all at the same time. What if this frame should be multi-threaded?
You know what I mean, does it make sense?
Hey Alvaro, inside your local scheduler, on the second tab you can activate “slots per workitem” and specify here how many threads each item gets. The total number of threads used (and therefore the number of workitems processed in parallel) is still set under “Total slots”. You can also have multiple schedulers for different nodes in your top graph, if you need these special settings only for one or two nodes.
Pretty sure the download link is broken for both wedging tutorials.
Nevermind, it seems to download in other browsers, but for whatever reason it’s just the wedging tutorials where this happens. Everything else downloads fine…
Fantastic series, thanks Chris.
Is anyone else having an issue where the ropfetch renders redshift frames much slower than directly from the redshift ROP? And any solutions.
Running in houdini 19.5 and RS3.5.08.
It’s been a while since I used Redshift with Tops, so I haven’t tested your exact versions. However there definitely is a time penalty with using Redshift with a Rop Fetch Top. My best guess is that Tops forces RS to load the scene into RAM new for every single frame, without RS deciding what it can keep and what needs to be refreshed.
You can get rid of most of that delay by using partitioners and making Tops start render sequences instead of single frames. This would only apply for the second wedging example in this series (animated geo) and not this one (static geo) though.