When I try and render using the Mono DPX Shotgun Write node, it seems to be filling out all of the information correctly, but when I go to render it returns:
Errno 2 No such file or directory: ''
any ideas?
I'm pretty sure I have everything set up correctly...
thanks in advance..
Hello Josh!
This can happen if the paths in your templates file are set up slightly different to the paths in the folder configuration! If you are ok to email your configuration to toolkitsupport@shotgunsoftware.com, we can take a quick look and see if we can figure out what is going on!
Thanks!
Manne
Thanks for the response- which config file should I send? And which template files?
It's weird, in the Nuke Write node, if I click on the Jump To File System, it goes to a '1920x1080' folder that seems right. But the render still fails with the same Errno 2.
If you could just zip up your entire project configuration and send it that would be great!
Thanks!
Manne
Here is our project from the 'software' folder...let me know if you need anything else?? (or if I did some stuff colossally wrong...)
thanks!
josh.
Thanks Josh, that's great!
I will try to set up your config locally and see if I can reproduce the issues you are seeing!
Any luck with this? I also have some questions in general about Nuke integration - specifically how Shotgun considers "plates"- it looks like they have to be Assets for Loader to see them...but then are they the Versions of the Assets? Or should I be using Elements? We also have RV - what's the best practice for getting a DPX sequence into a Shot that can then be loaded into Nuke as a plate or element...
thanks!
josh.
Hello Seth and Josh!
Josh, apologies for not following up regarding the nuke write node - since it involved a bunch of questions and debugging, we moved that into a support ticket and are tracking that separately - I'll check in with Alan (who is working on that) today to see how things are going!
As for the loader, Seth sums it up nicely! The idea is that the publish represents a file (or an image sequence) of data which can be used inside an application. It could be an exr sequence, an abc, a maya file etc. Versions are then used to review and take notes - they are the visual representation of a publish. There is a field on version which you can populate to connect a particular version to a number of publish records - this is how you can keep track of which review version is associated with a group of publishes. We recommend that you populate this relationship when you for example publish via the multi publish.
The ultimate idea is that when you publish, you may generate a collection of files - sometimes different file formats but effectively the same content (a maya file, an obj, an alembic etc) - and these are all different representations of the same thing - and they are associated with a single review version which can then be used to take notes and preview the publish data. A sort of fancy moving thumbnail if you like.
This idea becomes a little bit odd when the published data is an image sequence -- effectively the image sequence is both the thing you want to review and the thing that will be sent down the pipe - in this case you may have to "double up" and use both a publish and a version.
Both the case with publishes and versions described above and the case where a review version may have more than one representation (e.g. high rez frames, quicktime, multiple color spaces, sequence of jpegs) are things that we have been talking about for quite a while now - with our new larger engineering teams we are hopeful that these are now projects which we'll be able to tackle and add much more official support for sooner rather than later!
Thanks Seth for your great reply!
Manne
Josh,
I find this a bit confusing as well, and recently asked for some clarification on the matter when representatives from shotgun visited our studio. From what I understand, if you want a render (or plate) to be both view-able in screening room, and importable through the loader in nuke, you need to create both a version, and a publish of the same media. The version will be used inside screening room, and the publish will be accessible to the loader. I think the idea was that a publish of the media would be the 'main' or source / original format of the media / render, and then you could create multiple versions that are derived from the source / original media, such as proxy jpegs or QuickTime movies. That being said, in our current setup, our versions for the source / original media have fields named sg_review_frames and sg_path_to_movie that point to our proxy and QuickTime movies, and screening room in RV uses those fields to switch between the original media and the proxy / movies during our review sessions. (As I understand it, this behavior was slated to be replaced in screening room to allow for reading from multiple versions, but I am not sure if it has) The published file record name is also important as it dictates the file name that the loader is looking for, where the name of the render version is more arbitrary. So, though it may sound like I understand how it is supposed to work, I really still to this day am confused as to why it works that way.
Hope that helps, and Manne - if I have this wrong, I apologize! If there is a document that describes the relationship better, please let me know :) I usually rely on this one: https://toolkit.shotgunsoftware.com/attachments/token/42frv90zdy399a0/?name=sg_version_representations_v6.pdf but I am not sure if it is now out of date..
Seth