Thanks for all your answers! :)
@Olivier:
There is no problem in interactive mode. I can select the last write
node and
see it.
Actually, it appear once two or three frames are computed (both in
interactive
or terminal mode).
From my experience in Linux dev (I'm on Linux), Linux is less ticklish with
memory. Windows often crash at the first time of the memory overflow.
I didn't test on Windows. I'm not even sur there is a Windows computer here
(maybe Photoshop... as usual...).
But there is an exception:
If I do not render with our Python script (which actually just set some
already
setted things and just execute the write node), it work.
If I only select the write node and click on "render", it work.
@Frank
Thank a lot for this, I will try! :)
@Diogo and Deke
We are on Linux here. :)
@Ben
Thanks for this tip! I will also test that. :)
Thank again all, I will do test and back again.
See you!
On 10/05/2011 10:53 PM, Deke Kincaid wrote:
yes, it is linux only.
-deke
On Wed, Oct 5, 2011 at 12:36, Diogo Girondi <[email protected]
<mailto:[email protected]>> wrote:
I'm not too sure but I think performance metrics is also working
under OSX.
On 05/10/2011, at 16:16, Frank Rueter <[email protected]
<mailto:[email protected]>> wrote:
> if you are on linux you can try the -P flag when launching Nuke,
which shows some info in the DAG per node regarding performance
>
>
> On Oct 6, 2011, at 6:40 AM, Olivier Jezequel wrote:
>
>> I don't know about the evaluation of nodes and it sure would
be usefull, but the way i deal with that kind of problems is to
get the viewer from the top of the tree and gradually looking
trough to find where it is crashing.
>> Not having a viewer should make it load without crashing unless
a postage stamp is guilty, you can disable them too in the pref.
>>
>> hope it helps in waiting of a script
>> Olivier
>>
>> Dorian Fevrier wrote:
>>> Hi all!
>>>
>>> We have nuke crashing without any messages, nothing... I'm
currently trying to know where this happen and, it happen (of
course...) within the:
>>>
>>> nuke.execute( writeNode, f, f, 1, forcedViews )
>>>
>>> I would like to know what are nodes that could do Nuke crash.
So I would like to know what are nodes running during Nuke crash
(doesn't seems to be a memory prob).
>>>
>>> I know this is not something easy to follow with
multithreading but something like:
>>>
>>> node1 -> Start
>>> node2 -> Start
>>> node3 -> Start
>>> node2 -> End
>>> node4 -> Start
>>> node1 -> End
>>> node3 -> End
>>>
>>> Could be really enought for me. To find the part where nuke crash.
>>>
>>> Is there a way to script during a evaluation start and end to
print the node name?
>>>
>>> How deal with this kind of prob?
>>>
>>> Thank in advance.
>>>
>>> Have a good day!
>>> _______________________________________________
>>> Nuke-python mailing list
>>> [email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
>>>
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>>
>> _______________________________________________
>> Nuke-python mailing list
>> [email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
>>
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
> _______________________________________________
> Nuke-python mailing list
> [email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________
Nuke-python mailing list
[email protected]
<mailto:[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
