The expressions can be in unobvious places, like inside gizmos.
The bug Elvis Au mentioned sounds similar to "Bug 35703. Expressions
force tree to validate unnecessarily, when changing unrelated parts of
the tree", which I reported as such:
On 06/05/13 20:24, Ben Dickson wrote:
Attached another example, which doesn't involve the RotoPaint:
>
The ImagePlane gizmo (available from Nukepedia) contains an "width"
expression in a crop. This combined with the motionblur option in
the Card3D causes the same UI sluggishness
>
Adjust the slider in the Keyer node, or try and type something in a
label - it is noticably laggy.
>
If the motion blur is setting is set to 0, it is much quicker.
>
The UI slowness gets progressively worse the more copies of the
ImagePlane there is, to the point the comp was not workable..
>
I haven't tested in older versions, but this behaviour would very
much explain many of the slowdowns we have experienced in the past..
Especially because we automatically create a Crop node above our
Write nodes, and this contains input.width and input.height
expressions (to prevent writing out EXR's with oversized bbox)
>
It seems like a relatively serious bug, as it will exacerbate any
inefficiencies in any nodes - worse as it can be very hard to track
down as the cause of a slow script..
Attachment was essentially this script:
https://gist.github.com/dbr/2f3faff433d59f58be7d
Reported for 7.0v5 in 2013 - but remains same in all current Nuke versions.
Some variant of this is usually the cause of a majority of "my script is
slow" complaints I've seen here - some slow node is upstream of a
time-based node (TimeEcho or lots of TimeOffset's, transform with the
"motion blur" setting enabled, ScanlineRender with many motion
subsamples etc)
The only way I have found to narrow it down is to delete half the
script, see if it speeds up or not, then repeat (using the Keyer slider
as a good way of checking - it's easy to see if the slider control
tracks quickly with the mouse cursor or not)
This doesn't exactly sound like the original problem Daniel described
(particularly "i can sometimes work in the same script for hours, then
suddenly the symptons start to show up"), although it can be made
sometimes seem quite random if the slowness is in part due to network
file access slowdowns.
Something similar also happened with a script containing a lot of
ReadGeo nodes loading Alembic .abc geometry with a relatively complex
scene hierarchy.
On 07/03/16 18:34, Daniel Hartlehnert wrote:
@Lucy:
another question though: if it really is the expressions that are
causing this. how is it possible that nodes that do not have expressions
in them are causing this behavior?
Thats the way it was happening for me. I have scripts with many
expressions in them, but even opening nodes that have none may cause the
freeze.
Oh and sending you a scrlpt is unfortunately not possible. NDA reasons
and its not really reproducable.
Daniel
Am 04.03.2016 um 17:39 schrieb Lucy Wilkes <l...@thefoundry.co.uk
<mailto:l...@thefoundry.co.uk>>:
Hi Daniel,
I've answered on your forum thread. I also wondered whether
expressions might be causing this
(http://community.thefoundry.co.uk/discussion/post.aspx?f=189&t=120025&p=1008064).
If you have a script and repro steps, please do send them in to our
Support team so that we can take a look.
Regards,
Lucy
_______________________________________________
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
--
ben dickson
2D TD | ben.dick...@rsp.com.au
rising sun pictures | www.rsp.com.au
_______________________________________________
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
