Have to agree with Diogo here. Unless the node you're creating behaves in a way that requires persistent dynamic internals, Gizmos are easier to manage from a pipeline standpoint. When Grizmos have to go under the knife, you will spend a lot more time telling artists to re-create/re-configure any nodes they've already created, which ultimately wastes everyone's time.
That being said, Grizmos have their place. If you find yourself creating them on a regular basis, I recommend you establish your own method of "tagging" them with class names, and also a Grizmo callback management system that utilizes your class system instead of Nuke's. This has worked quite well for me in the past. -Nathan On Sep 3, 2012, at 9:55 AM, "Diogo Girondi" <[email protected]> wrote: > Sure. > > Usually you use gizmos when you don't want people to go wildly creative on > things without knowing what they are doing, and want to easily maintain > certain bits throughout a project. Since gizmos are external to scripts you > can easily update a single file and have it updating every script that is > using it. This doesn't happen when you're working with groups. > > Each one has it's advantages and disadvantages, so there is not right or > wrong. > > But debugging a gizmo is not that different than debugging a group. They are > basically the exact same thing from a dev pov. > > > -diogo > > On Mon, Sep 3, 2012 at 1:13 PM, sh4dow <[email protected]> > wrote: > Well... I think what is "proper" depends on one's approach to things. I like > to keep things as open as possible, so that capable people have an easy time > changing things if they need to. > > Also, gizmos can be a pain to debug. For instance, nuke is for some reason > creating key frames on a gizmo even though it doesn't if I change it to be a > group inside the gizmo. Plus, I can't easily see what the code I put into the > callbacks is actually doing inside the gizmo. > So... from my perspective, it only makes things unnecessarily annoying. > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
