Nuke wish list????

[Anonymous]

SANDOKAN:
2. Plugins? I use the plugins of Shake and DF and the import all in Nuke.

-Why? i don’t know about this… may be is impossible or impossible script 😯

or i don’t correct translate? 😳

[Anonymous]

Hi guys,

We’ve been using NUKE for about 2 years now here at ReelFX, and here is a wishlist we compiled:

Enjoy!

–Jay

1. NUKE Viewer – Because the NUKE viewer uses disk caching only, in almost all cases it’s impossible to get realtime playback at any resolution. This makes any animation-sensitive task such as rotoscoping extremely difficult. I realize that that the flipbook function is supposed to alleviate such problems, but for solving complicated animations such as roto tasks demand it is extremely unwieldy to make a small change and then re-flipbook the entire sequence. If NUKE’s viewer moved to incorporate some RAM caching so that realtime playback was always possible (even in small segments) this would improve workflow in such tasks as roto enormously. It would be also very helpful to implement some intelligent background caching as well (i.e.. DFusion), to speed up response. Some of our users would also like to be able to subdivide the viewer into 2 or 4 sections for a more 3D app feel. This is already possible by creating 2 or 4 viewers but it would be much more efficient and streamlined to be able to have one resizable window. Also, to be able to select a “viewer LUT” to be applied independently to the scopes would be helpful (i.e.. NTSC color bars display on the scopes as they would on a waveform monitor). It would also be nice to be able to set the zebra-stripe limits instead of them being hard coded.

2. Tracker – Although NUKE’s modular tracking implementation is superior to any I have used (ability to created unlimited tracker/stabilize nodes, ability to link trackers with expressions, etc…), I find that the tracking algorithm it uses is substandard in comparison with similar packages. NUKE’s tracking algorithm (in all modes) has a severe tendency to drift in all but the most obvious cases. Whenever I need to track something I always find myself reverting to Combustion because the Discreet tracking algorithm (imported from Flame) is bullet-proof in comparison to NUKE’s. However, this is highly frustrating, as Combustion’s tracker implementation is extremely ineffective and makes tasks that are easy in NUKE impossible in C*.

3. 3D Scene optimizations – NUKE’s 3D scene sets it apart from it’s competitors, but it still has a long way to go. One example is the axis functionality in NUKE. It was be much more intuitive to actually move the XYZ coordinates instead of the dotted line that currently serves as the axis. It would also be an extreme improvement to be able to interactively place the axis rather than through a dialog. Also, hotkeys for rotation translation and scale a la most 3D programs would be more intuitive than the current implementation. Lights are also not implemented very well currently (should cast shadows, illuminate objects, be visible to camera, etc..). A node that would be incredible would be an Extended Bicubic a la Flame…I’ve asked for this before and I know it would be rather simple to implement (I would think), as the grid-based warper is almost already doing this (I’ve heard it uses 3d rendering), and really it would just involve adding subdivisions to the bicubic node. 3D Displacement is a BIG one…this would be extremely helpful as our current 2D displacement gizmo is rather cheap in comparison to real displacement. Also, the ability to select 3D objects on the fly is very important when dealing with a large amount of objects in the 3D scene (I realize this is rather antithetical to the NUKE node workflow, so perhaps it could be achieved by opening a node that detects whatever 3D object you click on and then opens the node for that particular object?). Also, one should be able to instance objects by attaching as many axes as one likes or a similar methodology.

4. More access to the nuts and bolts – NUKE’s major selling point is its low-level access to the “nuts and bolts” of the program. This is extraordinary as no other compositor allows so much freedom as NUKE. However, there are still a few things that could be added and tweaked that would explode the capability of NUKE. Something I’ve always imagined would be akin to Maya’s “Script Editor”, which depending on what mode it’s in, will feed all of the commands that the UI is passing to the program. This is invaluable when creating a MEL script, because Maya itself runs on MEL just like NUKE runs on TCL. So if every command or modification made could be recorded or output in a “debug window” this would make creating TCL scripts and gizmos that much easier. Also, there are a few knobs that are not ported and available for user menus.

5. Commit to Disk Functionality – It would be quite helpful to have a smart commit to disk node that could intelligently render everything above it to disk, and disable nodes above it when something is rendered or viewed below it or leave them alone when rendering or viewing above it. Also if it could warn the user when something has changed above it and give the user the option to recommit. It should also be able to turn everything else off intelligently when committing to disk in order to make it farm friendly.

6. Etcetera – It would be nice to be able to configure hotkeys through a GUI instead of modifying a conf file (preferably saving the modifications to the local level instead of the global level). Bookmarks do not implement correctly most of the time unless hard coded. Network floatable preferences would be very helpful.

[Author]

Posts