Also, if you use a version control system such as git - you might stand a
chance at recovering that old version you saved over.
On Aug 5, 2015 12:54 AM, "Frank Rueter|OHUfx" <fr...@ohufx.com> wrote:
> There is, but not a very elegant one:
> You can simply use nuke.knobDefault() and set a default value for all
> knobs of the given name (regardless of the parent node's class).
> E.g.: if your group has a knob called "_myKnob" you can use this to set a
> default for it:
>
> nuke.knobDefault('_myKnob', '.5')
>
> Of course if you use a knob name that other nodes use as well, those
> knobs' default value will be changed too.
> You can narrow it down a little bit to only effect group nodes:
> nuke.knobDefault('Group._myKnob', '.5')
>
>
> I have never understood why people decided to demonize gizmos at some
> stage though. The stuff that people list as reasons against using gizmos
> are all true for plugins as well. So it simply comes down to managing
> production gizmos properly and, as pointed out before, version them up if
> changes effect the output or default knob values.
>
>
> I prefer a gizmo over a group any day as you know your script size won't
> explode and you can work with the actual gizmo class in pipeline code (like
> for setting knob defaults).
> Anyway, everybody has their own ways I guess :).
>
>
> Cheers,
> frank
>
>
> On 5/08/15 1:18 am, Charles Taylor wrote:
>
> So, I take it there is no way whatsoever to set the default value on a
> Group node (or other custom knob)?
>
> This can only be done for gizmos?
>
> On 08/02/2015 05:30 PM, Johannes Hezer wrote:
>
> Or project environments, we do store project environments and their
> configs.
> so we the outcome wont change, and I mentioned it because it is from my
> perspective sth that can be seen as a strength ... depends on what you are
> after...
>
> Am 8/2/15 um 14:18 PM schrieb Michael Habenicht:
>
> Hi, that is no problem at all if you do proper versioning of your gizmos.
> Very simple rule: as long as the result stays the same the version stays
> also, no matter what optimizations or new knobs you do. But as soon as the
> result differs the slightest you version up. With this you never have
> problems opening older scripts. But optimizations and new options are still
> picked up automatically.
>
> Best regards,
> Michael
>
> On August 2, 2015 12:00:29 PM CEST, Erwan Leroy <er...@erwanleroy.com>
> <er...@erwanleroy.com> wrote:
>
> That's one of the exact reasons why we want to avoid them. Let's say
> you
> work on a shot, finalise it, ship the project out and forget about it.
> A
> few month go by, and you add stuff in your gizmos, make them more
> efficient, more useful. Suddenly you get a request by a client to do a
> minor tweak on that shot you did a year ago and forgot about. You
> reload
> the archive, open the script and... It looks nothing like the original
> shot, because all your gizmos now produce different results.
> Sure you could convert all gizmos to group before archiving your
> project,
> but it can be a big amount of work. Also this could happen in an
> ongoing
> production, although most places will be smart enough to not make a
> massive
> change in a gizmo in a middle of production.
> On 2 Aug 2015 17:51, "Johannes Hezer" <j.he...@studiorakete.de>
> <j.he...@studiorakete.de> wrote:
>
> Another advantage of gizmos is that you can add knobs and make
>
> changes the
>
> way it is setup, and it will be reInitialized everytime you load a
>
> script
>
> with the gizmo.
> A Group is stored within a nuke file and wont update if you change
>
> the
>
> "master".
> Is that the same with toolsets ?! (Have not tried yet...)
>
>
>
>
> Am 8/1/15 um 3:28 AM schrieb Erwan Leroy:
>
> It would be nice to have an option to do that without having to make
>
> a
>
> gizmo. At work we decided to try to go gizmo free, using toolsets
>
> only, for
>
> improved compatibility both internally and externally.
> The only single thing I miss from gizmos is the ability to save
>
> default
>
> values.
>
> Is there a way to do that?
> On 1 Aug 2015 05:05, "Rich Bobo" <richb...@mac.com> <richb...@mac.com>
> wrote:
>
> Charles,
>
> Yeah, that’s what was tripping me up. I was working on the toolset
>
> as a
>
> Group. Kind of annoying that it you have to save it as a Gizmo to
>
> set the
>
> default reset values… (8^\ But, at least I know now.
>
> Rich
>
>
> On Jul 31, 2015, at 4:47 PM, Charles Taylor <ctay...@spinvfx.com>
> <ctay...@spinvfx.com>
>
> wrote:
>
> What about groups? We don't use gizmos here for a variety of
>
> reasons, but
>
> rather groups. It seems that groups always default back to the
>
> knob's
>
> default.
>
> - Charles
>
> On 07/31/2015 04:44 PM, Matt Plec wrote:
>
> Hey Rich -
>
> It should reset to whatever value the knob was set to when you
>
> initially
>
> created the gizmo. You can edit the value saved in the .gizmo file
>
> in a
>
> text editor or in nuke convert back to a group, set the knob to the
>
> default
>
> value you want, and then save the gizmo again.
>
> For instance, if I've got this at the head of the gizmo file:
>
> Gizmo {
> amount 0.1
> }
>
> It should reset to 0.1. Just change that to another value, save the
>
> file,
>
> and that's the new default.
>
> Be careful about this changing the behavior of existing scripts. If
>
> you
>
> have scripts using that gizmo that didn't set the knob different
>
> from
>
> default, it isn't saved in the nuke script. When those scripts
>
> reload after
>
> you change the default, they'l get the new value. If you want that,
>
> super!
>
> If not, save a new version of the gizmo so old scripts can still
>
> pick up
>
> the original and render the same.
>
> Matt
>
>
> On Fri, Jul 31, 2015 at 12:19 PM, Rich Bobo <richb...@mac.com>
> <richb...@mac.com>
>
> wrote:
>
> Hi,
>
> Is there a way to set the default “reset” value for a knob that you
>
> have
>
> added to a menu?
>
> For instance, in a gizmo, I have added a Floating Point Slider
>
> knob.
>
> When the user does a CNTRL-click (or CMD-click) on the slider, I
>
> would like
>
> it to reset to 1.0 — not 0.0.
>
> Can it be easily done…?
>
> Thanks,
> Rich
>
>
> Rich Bobo
> Senior VFX Compositor
> Armstrong White
> Email: rich.b...@armstrong-white.com
> http://armstrong-white.com/
>
> Email: richb...@mac.com
> Mobile: (248) 840-2665
> Web: http://richbobo.com/
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk,
>
> http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
> _______________________________________________
> Nuke-python mailing listnuke-pyt...@support.thefoundry.co.uk,
>
>
> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk,
>
> http://forums.thefoundry.co.uk/
>
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk,
>
> http://forums.thefoundry.co.uk/
>
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> _______________________________________________
> Nuke-python mailing listnuke-pyt...@support.thefoundry.co.uk,
>
>
> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
> ____ ESET 12026 (20150731) ____
> The message was checked by ESET Mail Security.
>
>
>
> --
> STUDIO RAKETE GmbH
> Johannes Hezer, Compositing TD & Stereoscopic SV
> Schomburgstr. 120
> D - 22767 Hamburg
> j.hezer@studiorakete.deTel:+49 <+49> (0)40 - 380 375 69 - 0
> Fax:+49 (0)40 - 380 375 69 - 99
>
> ------------------------------------------------------
> Pflichtangaben laut Handelsgesetzbuch und GmbH-Gesetz:
>
> STUDIO RAKETE GmbH
> Schomburgstr. 120 D - 22767 Hamburg
> www.studiorakete.de / i...@studiorakete.de
>
> Geschaeftsfuehrer: Jana Bohl
>
> Die Gesellschaft ist eingetragen im Handelregister des
> Amtsgerichts Hamburg unter der Nummer HR B 95660
> USt.-ID Nr.: DE 245787817
>
>
>
> ____ ESET 12030 (20150801) ____
> The message was checked by ESET Mail Security.
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> --
> [image: ohufxLogo 50x50] <http://www.ohufx.com>
>
> *vfx for storytellers <http://www.ohufx.com> *
>
> *vfx compositing <http://ohufx.com/index.php/vfx-compositing> | workflow
> customisation & consulting <http://ohufx.com/index.php/vfx-customising> *
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
