Hi Carl. Please correct me if I'm wrong but it seems to me that your final
line of code above, namely:


*nuke.delete(temp)*
should be indented to be part of your for loop:


*    nuke.delete(temp)*
So that it gets deleted after every frame.

Hope that helps.
Pete


On Thu, Feb 27, 2014 at 11:08 PM, Carl Schröter <ad...@l-rac.de> wrote:

> Hi all,
>
> thanks for all the replies! Much appreciated.
> I'm already using the CurveTool "hack" (as can be seen in my code example
> from the beginning) and still having update problems from time to time. But
> at least I know, that this is the common method for now.
>
> Fingers crossed for a nuke.refresh() as Ben said...
>
> Cheers,
> Carl
>
> PS: is there some offical and public list of bug-reports / feature
> requests so we can bump up the exact issue?
>
>
> Am 2014-02-27 09:04, schrieb Ben Dickson:
>
>  Example of the CurveTool workaround:
>>
>>
>> fr = nuke.FrameRange(1, 100, 1)
>>
>> ct = nuke.nodes.CurveTool()
>> ct['label'].setValue("Temp curvetool to update frames")
>>
>> for frame in fr:
>>     nuke.execute(ct, frame, frame)
>>
>>     # ...vertexSelection stuff...
>>
>> nuke.delete(ct) # Clean up hacky CurveTool
>>
>>
>>
>> Theoretically this should be the same as doing nuke.frame(2)
>> nuke.frame(3) etc, but.. as Frank described, it's not.
>>
>>
>>  Afterwards don't forget to log a bug report to get this resolved
>>> finally. Maybe we could ask for a flag to set that forces Nuke to
>>> re-evaluate during a python loop, then set another flag to turn off that
>>> behaviour again if it means staying more efficient.
>>>
>>
>> It seems like nuke.frame(framenum) should trigger the update always..
>> but I guess there might be cases where this wouldn't be desired..?
>>
>> Alternatively nuke.frame(framenum, refresh=True) or something, or just a
>> generic nuke.refresh() type method that could be called might be a good
>> compromise
>>
>>
>> On 27/02/14 06:47, Frank Rueter wrote:
>>
>>> Many of us have been fighting this for years.
>>> One of the quick& (very) dirty workarounds is to create a dummy node
>>> that can be executed (i.e. CurveTool), execute it to force Nuke to
>>> re-evaluate the stream, then delete it. Do this for every
>>> iteration/frame and you should get the correct values if I remember
>>> correctly.
>>> I don't think the dummy node has to be connected to the nodes you are
>>> working with but haven't done this in a while myself.
>>>
>>> Afterwards don't forget to log a bug report to get this resolved
>>> finally. Maybe we could ask for a flag to set that forces Nuke to
>>> re-evaluate during a python loop, then set another flag to turn off that
>>> behaviour again if it means staying more efficient.
>>>
>>> Cheers,
>>> frank
>>>
>>> On 27/02/14 06:35, Elias Ericsson Rydberg wrote:
>>>
>>>> Maybe you could force it by adding a writegeo downstream. I would
>>>> imagine that would make nuke evaluate geometry positions upstream?
>>>>
>>>> Maybe adding the positions as metadata in the stream could be a valid
>>>> alternative.
>>>>
>>>> Cheers,
>>>> Elias
>>>>
>>>> 26 feb 2014 kl. 12:56 skrev Carl Schröter <ad...@l-rac.de>:
>>>>
>>>>  Hi guys,
>>>>>
>>>>> I've been experimenting with vertexSelection lately (in nuke7) and
>>>>> noticed something strange (at least it seems strange to me).
>>>>>
>>>>> When I run the code below on selected vertices of an animated abc
>>>>> file, Nuke does not update the vertex-position values in the loop. 
>>>>> However,
>>>>> if gives me the correct position when I execute it on single frames. To
>>>>> make it even stranger: when I connect a scene-node to the ReadGeo, the 
>>>>> code
>>>>> outputs 2 points for the same selection on different positions in space.
>>>>>
>>>>> ##########
>>>>> temp = nuke.nodes.CurveTool()
>>>>> for frame in range(1100,1150):
>>>>>    nuke.execute(temp, frame, frame)
>>>>>    nuke.frame(frame)
>>>>>
>>>>>    selectedVertexInfo = nukescripts.snap3d.selectedVertexInfos()
>>>>> #it's the same for selectedPoints()
>>>>>    print nuke.frame()
>>>>>    for point in selectedVertexInfo:
>>>>>        print point.index, point.objnum, point.position, point.value
>>>>>    print
>>>>>
>>>>> nuke.delete(temp)
>>>>> ##########
>>>>>
>>>>> To make my confusion complete: it sometimes (very rarely) just works
>>>>> as expected...
>>>>>
>>>>> Is there something I am missing here? A way to force update the
>>>>> 3d-system?
>>>>> Also is there a way to get the geo containing node from selected
>>>>> points (so I could temporarily disconnect the scene node downstream)?
>>>>>
>>>>> Any help is greatly appreciated!
>>>>> Cheers,
>>>>> Carl
>>>>> _______________________________________________
>>>>> 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
>>>
>>>  _______________________________________________
> 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

Reply via email to