Nuke 4.7 Stability (or lack thereof...)

[alkali]

Ok, I may be all alone on this one (though I don't know how that could possibly be...) but has anyone else noticed the major downturn in Nuke's stability between 4.6 and 4.7? It's unbelieveable... and predictable. I can be working with any op, any comp, any input format(s), any level of complexity, and it will randomly crash and burn 7 or 8 times an hour like clockwork.

Sometimes it's when I scrub the timeline or zoom in on a viewer. Sometimes it's when I start to increment a value. Sometimes it's when I connect a pipe. Sometimes it's when I adjust a curve. Sometimes it's when I get up to go make a sandwich. But it's like the tide... freakin' inevitable.

The only thing keeping me from junking it until 4.7v2 (or whatever the next release is) is the fact that it autosaves so often that I rarely lose more than a couple digit entries or maybe a node creation. That, and I actually like it despite all this. Luckily, Fusion is still my app of choice, so I'm not dead in the water or anything.

And an interesting bit of poetic justice for anyone who has ever complained about Fusion's stability: It's only crashed on me twice in 2 years of use. Seriously. I notched my belt.


Anyhoo, just wondering if anyone else is even near my boat on this one.

[digitallysane]

Anyhoo, just wondering if anyone else is even near my boat on this one.

I have noticed some instability (although not so drastic as you describe). I think it's related to the graphic card mainly. I say that because I got crashes mainly related to viewport manipulation (dragging, bezier editing). I have a GeForce 8800 and they are not famous for their reliable drivers :) . What card do you use?


Dragos

[alkali]

I use an old 256 MB Radeon X600 with Catalyst 7.2 drivers, and it's been flawless for everything I've ever done on this machine, both 2D and 3D. I don't think the actual Nuke UI really uses any sort of hardware-based graphics API though, so I don't see how that could be causing problems (it hasn't crashed in the OpenGL viewer... yet). Not only that, but the crashes come from such a mixed bag of situations that I can't, in good conscience, blame it on my system.

Nevertheless, thanks for the suggestion

[nathan]

I'm not doubting the problems your having but you know from the people I talk with it almost seems like some of these problems are windows only. I've had a few people send me 4.7 scripts that they say barf when you do a certain operation in a script and under Linux I just can't reproduce the errors, I'll spend a good 5-10 minutes trying to recreate the problem they say happens and I just can't do it. Granted this sure don't help you none but it is just something I have no explanation for.

Diogo Girondi and me were talking just yesterday about how he is having the grain node give him invalid channel errors with scripts. He said if you changed the parameter in a node above a grain that every so often an error would occur. The basic error text that Nuke displays is roughly the same as if you told a node to use the depth channel for a mask when the incoming image doesn't have a depth channel to begin with. He sent me his script and I spent a good 10 minutes changing every knob for every node above the grain and couldn't get it to happen like he could. He also said you could reproduce this error by disabling a knob above the grain node, this also I could not reproduce myself in the 10 or so minutes i spent going to town on his script.

I don't know what to say other then "Ha ha you use Windows". Nah I only kid, if anyone else is also having issues and can easily reproduce these problems it would be nice to see if they could post example scripts to see who else can reproduce the error. Most of the problems I've seen I kinda get what is going wrong from the error message but I'm kinda curious as to why certain bugs happen for some users and not others.

[alkali]

Incidentally, I actually use Linux for a number of things as well, but I don't have a Nuke license for it... Perhaps I should change that.

Anyway, this seems like a good time to bring up the fact that I too occasionally get completely random error messages from nodes (mainly from shuffle and shuffle copy thus far).

For example, I might pipe in several render passes and copy the channels to new layers and channel sets, and then keep going just fine. But then later downstream, I'll get an error at a random point in time that references one of the shuffle ops waaay upstream. The message basically says there's a problem with the way the node was coded, like "error calling something_or.other(). This is probably due to a coding problem with blank-ity-blank." (it almost sounds apologetic) and the shuffle node will throw the big red ERROR sign.

However, if I go back to the shuffle controls and change one of the IO switches (like reassigning a green input to a blue output) and then immediately switch it back to the way it was, everything goes back to normal, and the viewer spits out the render.

Now, this is waaay too random to keep track of, but it has happened at least 10 times this far. Just thought I'd bring it up...

[nathan]

I get what you mean, errors like that almost always are a _validate not called or channel(f). I could be completely wrong but from my work with Nuke and its NDK when you see them errors you get a general sense of what they mean.

Validate is the function for a Nuke node that does certain things as well as calls validate on the inputs of the node if it has any. So a "_validate not called" error basically means a node somewhere has not called a validate for either one of its Iops, itself, or any number of other things. After validate is called Request is then called on the inputs of the node or any internal Iops, nodes, etc.., you can think of this as the part where the node grabs a bounding box and group of channels from the input or internal nodes etc. The next step in the chain is Engine or PixelEngine which does the actual image manipulation for the node. Now this can get more complicated depending on how the node is coded. Here is an example of what NFXPSColor does inside _validate, this is only a small portion.

void NFXPSColorIop::_validate(bool for_real) {
input(0)->validate (for_real);
input(1)->validate (for_real);
PixelIop::_validate(for_real);
}
As you can see 3 validates are called inside NFXPSColor's _validate, if I didn't call validate on one of my inputs then you would see the same validate not called error that you randomly get as you said. Another area that could be the problem is Invalidate isn't operating properly or being called and thus causing issues.

A channel(f) error is basically telling you Request somehow screwed up and didnt request a channel that a node is trying to work on. Now how Request got messed up I do not know, you usually setup the channels your going to be requesting inside Validate so any error on Request means that somewhere it wasn't setup properly.

My point is errors like that are usually some screwup thats happening in the tree, now why its happening I do not know. It could be the node correctly sets up everything but isn't updating with new information after a node upstream changes or its just not setting things up properly to begin with. Sorry for all the mumbo jumbo but I figured I would at least give you a general idea so you could better understand what the errors are saying to you.

[alkali]

No, that's a huge help in terms of understanding what's going on. Thanks a lot.

Now if only the program would run long term...

[nt65]

Sounds like Fusion 5 all over. I guess all I can say is hang in there. Been there before. They will definitely fix it. They'll have to.
cheers.

[alkali]

I hope you're not comparing Fusion's stability to this mess... ;)

But yeah, I suppose they can't exactly go with a twice-yearly releases anymore when the software doesn't run.

[Diogo Girondi]

I just upgraded to 4.7v1 and I'm also experiencing some problems as nrgy pointed out. But I'm sure they will fix them really soon.


I don't think the actual Nuke UI really uses any sort of hardware-based graphics API though

For what I know it does use and it pretty picky about it. Nuke always had it's issues with ATI boards. I use nVidia Quadro boards and have never experienced any sort of graphics board related problem.


Incidentally, I actually use Linux for a number of things as well, but I don't have a Nuke license for it... Perhaps I should change that.

As far as I know the license is the same you only need the Linux installer

Get in contact with thei support, let them know what you're experiencing

support <at> thefoundry.co.uk

[alkali]

For what I know it does use and it pretty picky about it. Nuke always had it's issues with ATI boards. I use nVidia Quadro boards and have never experienced any sort of graphics board related problem.



Well, that might be a valid point, except 4.6 runs like a champ on the same computer. Graphics issues more often relate to driver/software conflicts than actual hardware compatability issues anyway, so I'm pretty positive my graphics hardware isn't a problem (unless they completely overhauled the program's graphics API between 4.6 and 4.7).

If the new version doesn't support the same hardware as the old, then that would be a pretty big black mark on The Foundry's common-sense-o-meter. I really doubt they would inadvertantly implement that big of a change.

Nevertheless, thanks for the reply.

[agentex]

For production work none of the Foundry releases are acceptable, 4.6 was really unstable for me. The D2 4.5 builds are very nice. :)

[grafikus]

Yes 4.7v1 is little bit over the edge with stability. Sometimes I just hit Alt-F and get crash. I hope there will be fix soon, because 4.6 was running relatively smoothly. Running on XP.

[Diogo Girondi]

This release could be described as randomly useful :rolleyes:

[beaker]

For what I know it does use and it pretty picky about it. Nuke always had it's issues with ATI boards. I use nVidia Quadro boards and have never experienced any sort of graphics board related problem.Ati makes some of the worst opengl drivers out there. Directx great, but opengl I have had nothing but problems with them with all operating systems and all pro opengl apps. 9 out of 10 times people have a problem with maya, it is because they are either using a ati card or not using the proper driver version for an nvidia one.

[alkali]

What amazes me is that companies still bother developing software that uses OpenGL instead of adopting DirectX (at least for the Windows version).

[ShadowMaker SdR]

at least for the Windows version
That's probably the reason: if you have applications that need to run crossplatform, there's a good reason not to have DirectX on Windows, OpenGL on Linux etc. It creates extra work without much benefit.

[nathan]

Well both DirectX and OpenGL have advantages and disadvantages but none is king of the hill. If your trying to develop a cross platform application then choosing OpenGL is obviously the only option. Using OpenGL for your Linux and Mac versions and DirectX for Windows is just adding more problems to deal with then just choosing one for all platforms.

*edit*

I also might add that using DirectX on windows would screw with the 3d workspace in more ways then one. First and foremost are shaders, if you write plug-ins for Nuke that are shaders for the 3d workspace you would have to create a separate Windows version using DirectX.

[hevonen]

OpenGL is platform independent, Direct3d is not. This makes porting easier.

Wikipedia says:
"The many extra features of OpenGL that were previously mentioned as not useful for game development are also a factor in OpenGL's professional market advantage, because many of them are useful in professional applications."
http://en.wikipedia.org/wiki/Comparison_of_Direct3D_and_OpenGL

[Diogo Girondi]

Ati makes some of the worst opengl drivers out there. Directx great, but opengl I have had nothing but problems with them with all operating systems and all pro opengl apps. 9 out of 10 times people have a problem with maya, it is because they are either using a ati card or not using the proper driver version for an nvidia one.

I couldn't agree more. ATI does some pretty decent hardware but when it comes to the software side of things they let you down big time.

In nVidia at tops you would have to go for a certified driver or tweak some settings for your app of choice in the current (latest) drivers and you're fine.


What amazes me is that companies still bother developing software that uses OpenGL instead of adopting DirectX (at least for the Windows version).

OpenGL is fine and it's cross-plataform, leave it that way. The problem is with bugs that are not related with ATI drivers or even a specific graphics card. That's what makes me sleep less and drink more coffee then usual.

[beaker]

What amazes me is that companies still bother developing software that uses OpenGL instead of adopting DirectX (at least for the Windows version).DirectX and specifically Direct3d aren't made for professional applications, but instead for Games and now with Vista for the ui. Back when Microsoft owned Softimage, they supposedly tried to get them to move XSI from opengl to directx, but there were many issues with it.

I'm sure this has been fixed, but the big deal in the old days why they didn't use direct3d is that it doesn't support acceleration for multi windowed displays. So in 3dsmax which supports direct3d, you only get the perspective viewport acclerated and nothing else. I haven't used 3dsmax since version 2.5, so I'm sure this has changed since then.

[FKMaster]

i had also some problems with nuke and maya/shake with ati cards....
after switching to nvidia.... everthing runs more stable !

[alkali]

Yeah, I know the REAL reason(s) they use OpenGL... I was just ranting more than anything. :D

Nevertheless, the problem's I've been having are all isolated in Nuke 4.7, and they don't occur during any 3D viewing, which is why I initially tried to steer suggestions AWAY from hardware problems. Maya and Nuke 4.6 both work flawlessly, so OpenGL/driver compatability isn't the issue.

[beaker]

Nevertheless, the problem's I've been having are all isolated in Nuke 4.7, and they don't occur during any 3D viewing, which is why I initially tried to steer suggestions AWAY from hardware problems.Nuke, like Shake uses opengl to draw the entire UI. It's pretty common now with Aeroglass and Quartz 3d where windows are essentialy 2d textures on flat 3d planes. So it still requires opengl even when your not in 3d view.

If 4.6 and Maya are running fine then your probably right that it's less likely to be a card/driver issue.

[Diogo Girondi]

Don't forget that Nuke 4.7v1 now uses OpenGL antialiased on curves and what a nots, so it's requirements on terms of 2D OpenGL are different from those from 4.6. So if it works in nVidia and not with ATI it is a ATI problem and not a Nuke problem. You should get in contact with The Foundry support and see if the have any suggestion on a driver version that is working for ATI boards and check if your graphics card is in fact supported by it.

I know a few people that are running Nuke on Mac's with ATI graphics and don't share your problem.


Cheers,

[FKMaster]

now, i´ve worked on new shots and 4.7 crash 3-4 time per hour.... nuke4.6 is really stable....
i´ll hope they get it fixed soon...