Re: [Nuke-users] ShotGun / RV player and Nuke
Hi, Have you seen shotgundropper http://www.nukepedia.com/python-scripts/nodegraph/shotgundropper/ ? We use a custom version of this and it works great. Regards, Gerard. ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] ShotGun / RV player and Nuke
I wrote a read node which would find the latest elements for a shot. http://www.vfxtalk.com/threads/21217-Shotgun-Read-Node-(SG-Integration) But it was written in '09 and hasn't been updated since so you probably will need to tweak the SG API calls. - Gavin Greenwalt Straightface Studios On Wed, Dec 14, 2011 at 8:52 AM, Gerard Keating gera...@gmail.com wrote: Hi, Have you seen shotgundropper http://www.nukepedia.com/python-scripts/nodegraph/shotgundropper/ ? We use a custom version of this and it works great. Regards, Gerard. ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] ShotGun / RV player and Nuke
Oh I also forgot to mention that if I was starting over from scratch (which I am half heartedly considering) I would do it all completely differently: This is what I sent to Shotgun Software: http://i111.photobucket.com/albums/n134/im_thatoneguy/ShotgunNodes.gif So my basic philosophy going in was to address a couple fundamental challenges: - Exposing the shotgun data to scripting. - Maintaining consistency between various Shotgun-Nuke integration efforts and Deadline's integration. - Streamlining and standardizing the user experience. With those goals in mind I took the parts I like from the Deadline integration, mainly the unified Entity Browser but tried to think of ways to better use that data. There are a number of ways in which a Nuke Script can interact with Shotgun. You could read notes for instance on your shot. Maybe having a node to right inside of nuke review all of the feedback to make comp changes. You could use Shotgun to link to Deadline rendered file paths to read in render pass versions. You can use Nuke to review render element versions and make notes to the 3D department with glitches GI Flicker @ Frame 100. The ways in which Shotgun and Nuke can be leveraged are extensive, but at present each and every script or tool has to re-invent the wheel in order to function. If I have a shot note, read node and deadline system all in one script I have to specify What Shot is this? 3 times. I also have to provide my Shotgun Username 3 times and so on and so forth. So there needs to be a single unified repository for this information. When someone is setting up a Nuke comp they should only need to enter in the Shot Meta-Data once. They should only need to log-in once (I'm not really happy with that bit but I'll get to that in a minute as well). And they definitely shouldn't have to specify the shot every time they add a Sg (Shotgun) aware tool such as a read node or submit a script to Deadline. Yes, deadline can pretty easily store in an INI file all that information, but it should be carried within the script--and it should be easily exposed within the script. But there's another challenge, while sometimes you might only have one shot/output per script--sometimes you have different shots and outputs within the same composite. In this case a universal Sg setting wouldn't work. Similarly, sometimes you read in render elements from different shots. Maybe you rendered off a few explosion elements for Shot '0020' but you want to use it in Shot '0030'. Maybe part of your composite will be used in a couple shots so you keep them in one comp. Regardless of the reasons, a single global shotgun link per Nuke Comp isn't going to be a good long term solution, eventually there'll need to be a per-tree 'override' for defaults in addition to local ones. Another challenge is that you don't want to be hammering your Shotgun server every 2 seconds. Most of the time you just need to pass along the Entity GUID so that future queries know what to request. For example, if you had an sgEntity node at the root of your comp and submitted to deadline you wouldn't even need to use the Entity Browser. Assuming the GUID passed down was still valid that's all that would need to be passed as meta-data to the Repository. I do like the Deadline concept of having a single Shotgun Entity Browser. I like it so much that I think Shotgun should write one which is unified and open to all shotgun integration efforts. I believe it needs to return just 4 things: Entity Type, GUID, Plain-text Name and Plain-Text Entity-Type. Everything else could be queried easily through scripting from that data. Most tools would need a button which launches the Shotgun Entity Browser. But they could also walk up the node-graph and find a sgEntity node and just steal its 'cached' copy. I think Shotgun integration efforts would benefit from Shotgun defining the node structure and offering a Python Module for Nuke which would enable a variety of tools to use a single unified repository for shotgun settings. I know that Thinkbox is concerned about fragmenting their user experience, but with this system you wouldn't need to worry about that. You could still have the exact same UI you have now, the only difference would be that you would also check to see if there is an override in the composite/scene that has already defined the settings. So when you launch the Deadline Submission script in the short-term it could just check the composite, see if there are any shotgun nodes and if so, pre-fill the fields accordingly. If not--no harm no foul, the user uses the slower and less efficient universal Deadline experience. After all, the only point of the whole shotgun window for deadline is to aquire: Entity Type GUID and Version Name. There is no reason you couldn't just pull that from a node in the script instead of the pop-up window. Or you could use the Pop-Up window. The deadline submission script shouldn't care where it gets those 3 pieces of
[Nuke-users] Aligning plates: A clever way?
So aligning plates is a task that we have to do all too frequently. I have always maxed the two plates together, dropped a corner pin after the plate that needs alignment, and eyeballed it into place. Sometimes, F_Align can do this task quickly and effectively. Sometimes neither of these two tricks work. Maybe the folks on set decided not to spend the money on the proper equipment, so instead of a motion control shot, they just tell the jib arm operator to make his move look real similar to the last take. :) What I have done in the past would be to solve the two shots in a tracking package ( Boujou, PFTrack ) and then bring the two solves into Maya, and manually align them. I know that the new version of PFTrack gives you the ability to import multiple pieces of footage and will solve multiple cameras, allowing you to connect points between the two camera solves. The question is, is there an automated way to do this with Nuke? I'm pretty sure this is impossible, but I would like to select a 3D point in one solve and say that it is equal to a 3D point in another solve? Perhaps this could be done with Ocula? ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
[Nuke-users] SplineWarp python question
Hello!I trying to figure out how to access the control points of the destination curves of the SplineWarp node via python.The points of the source curves are easy:
node = nuke.selectedNode()curves = node['curves']
sourcecurve = curves.toElement('Ellipse1')
With sourcecurve[0], sourcecurve[1], etc i can access each control point.Any help?-- **Magno Borgowww.borgo.tvwww.boundaryvfx.com___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] SplineWarp python question
Each control point has both the source and destination attributes. The
confusing part is that the naming of those attributes makes more sense for
a standard roto shape.
So, your source curve is:
controlPoint.center
and the dest curve is:
controlPoint.featherCenter
Also, if you're getting the position data out of each attribute, keep in
mind that the dest points are stored as an offset relative to the src
point, instead of an absolute position.
Have a look at the output of this:
node = nuke.selectedNode()
curves = node['curves']
sourcecurve = curves.toElement('Bezier1')
for p in sourcecurve:
print p.center.getPosition(nuke.frame()),
p.featherCenter.getPosition(nuke.frame())
Hope that helps.
Cheers,
Ivan
On Wed, Dec 14, 2011 at 4:21 PM, Magno Borgo mag...@pop.com.br wrote:
**
Hello!
I trying to figure out how to access the *control points *of the* **
destination* curves of the SplineWarp node via python.
The points of the source curves are easy:
node = nuke.selectedNode()
curves = node['curves']
sourcecurve = curves.toElement('Ellipse1')
With sourcecurve[0], sourcecurve[1], etc i can access each control point.
Any help?
--
**
Magno Borgo
www.borgo.tv
www.boundaryvfx.com
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] SplineWarp python question
Yeah the naming was not helping! Thanks Ivan, that was exactly what i needed.Magno.Each control point has both the source and destination attributes. The confusing part is that the naming of those attributes makes more sense for a standard roto shape.So, your source curve is:controlPoint.center
and the dest curve is:controlPoint.featherCenterAlso, if you're getting the position data out of each attribute, keep in mind that the dest points are stored as an offset relative to the src point, instead of an absolute position.
Have a look at the output of this:
node = nuke.selectedNode()
curves = node['curves']
sourcecurve = curves.toElement('Bezier1')
for p in sourcecurve:
print p.center.getPosition(nuke.frame()), p.featherCenter.getPosition(nuke.frame())
Hope that helps.Cheers,IvanOn Wed, Dec 14, 2011 at 4:21 PM, Magno Borgo mag...@pop.com.br wrote:
Hello!I trying to figure out how to access the control points of the destination curves of the SplineWarp node via python.
The points of the source curves are easy:
node = nuke.selectedNode()curves = node['curves']
sourcecurve = curves.toElement('Ellipse1')
With sourcecurve[0], sourcecurve[1], etc i can access each control point.
Any help?
-- **Magno Borgowww.borgo.tvwww.boundaryvfx.com
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
-- **Magno Borgowww.borgo.tvwww.boundaryvfx.com___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
[Nuke-users] Re: pts lens correction coefficients to Nuke
So, forgetting about the newer LensDistortion coefficients which are two values, it seems that the three pts lens correction values are closely related to the old Card lens distortion method - they both output a cubic, sqaured and linear coefficient value - but if I plug the squared value (also the b value) from the pts into the Nuke card b value (squared) it doesn't match up :/ I'm sure DD would have done this a lot back in the day though, with pan and tile setups. On 13 December 2011 11:03, Michael Garrett michaeld...@gmail.com wrote: I'm sure this problem's been around for a very long time in various forms, but does anyone know the magic combo to get an exact correspondence between the lens correction coefficients in a pts (panotools/ptstitcher) script file and Nuke's new-ish lens distortion node? We are auto generating a pan and tile dome of nuke cards from the pts. Without really delving into the maths involved, I have done a bit of background reading on the lens correction model and the pts script file format: http://wiki.panotools.org/Lens_correction_model http://wiki.panotools.org/PTStitcher http://www.panotools.org/dersch/barrel/barrel.html The lens correction coefficients are represented by the o-line options (a b and c values) in the script and it seems that in all the pts scripts generated, the b value is the only one which is relevant - the others are at 0. But the last URL I pasted suggests that in most cases the b parameter is all that's needed to get satisfactory results. What we are currently doing is plugging the b value into the radial Distortion 2 knob which is close but looks like it could be a bit tighter. We've also tried putting it into the b value of the lens distortion knobs directly on the card but that looks worse. Thanks for any insight! Michael ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] Aligning plates: A clever way?
This would still require manually positioning, rotating, and scaling the scene so that the rough geometry would be in the same place between cameras, and this is assuming that there is no error in the solves, so the 3D solved points are in the same place... I think? Am I missing something? Brain not working that well today... :) On Dec 14, 2011, at 5:21 PM, Deke Kincaid wrote: Camera track the shot and project the plate on rough geometry. You can use the pointCloudGenerator, then fill it with a poissonMesh to create the rough geo. Use selectGeo so it doesn't fill every point. Export the mesh to an OBJ so it have to recalc every time you open the script. After you have this you can use any 3d camera you want. -deke On Dec 14, 2011, at 16:20, Ned Wilson nedwil...@gmail.com wrote: So aligning plates is a task that we have to do all too frequently. I have always maxed the two plates together, dropped a corner pin after the plate that needs alignment, and eyeballed it into place. Sometimes, F_Align can do this task quickly and effectively. Sometimes neither of these two tricks work. Maybe the folks on set decided not to spend the money on the proper equipment, so instead of a motion control shot, they just tell the jib arm operator to make his move look real similar to the last take. :) What I have done in the past would be to solve the two shots in a tracking package ( Boujou, PFTrack ) and then bring the two solves into Maya, and manually align them. I know that the new version of PFTrack gives you the ability to import multiple pieces of footage and will solve multiple cameras, allowing you to connect points between the two camera solves. The question is, is there an automated way to do this with Nuke? I'm pretty sure this is impossible, but I would like to select a 3D point in one solve and say that it is equal to a 3D point in another solve? Perhaps this could be done with Ocula? ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
