Is there a way to cut the RAM consumption when rendering multiple Write nodes? When I selected more than 20 Write nodes in the script and F7 to render, the Memory usage and VM size (under WinXP 64bit) went up and up to a degree that slows down the whole operation of OS. (I have 12 GB of RAM)
All the images being written are only 640×360 in resolution though are multi-channel EXR.
Thanks.
at Scenespector we are about to release a major upgrade to our software product VooCAT. The new version will include new features, a new GUI and a new installer system.
For stability testing we are currently searching for additional beta testers who would be willing to try out this new version before release.
The main focus of the test will be 3 things:
– bugs in the main program in general. including non working exports
– bugs in the installer routine (the first betas might not have an installer yet though)
– comparison between the old and new version (what do you like/dislike in which version)
If you are interested in helping out, please give us a short notice at beta@scenespector.com for more details. For more info about the program itself, please check our website…
many thanks and best regards
Markus
"C:/Program Files/Nuke6.1v1/Nuke6.1.exe" -x Z:/PROJEKTE/Egypt/SHOTS/PLA_310/2D/PLA_310_1_Comp_ak_v005.nk Write7(600,851)
my problem – Nuke is rendering all Enabled write nodes and not only specified one, how can i render only the node i want?
Btw here is a python script i wrote to send a script to bg render (i know it is not so aesthetic but better than type it 🙂
you need just select the write node, run the script, copy the command and paste in cmd
I’d like to point any interested parties at the latest work on the Aqsis renderer.
http://blog.aqsis.org/2010/11/intera…-aqsis-20.html
One of the negative points of comparison that has always been that of speed, Aqsis is perceived, often correctly, as being significantly slower than alternative RenderMan compatible renderers. We, specifically Chris Foster, have been working to address that. This post and screencast, constitute the first demonstrable results of this work. While there is some way to go before this work is fully capable and integrated back into the core product, it is clear to see that significant progress has been made in this area.
We welcome all feedback and questions, you can post on the blog, visit our forums (http://community.aqsis.org) or come and speak with us in the #aqsis IRC room on irc.freenode.net (or visit http://chat.aqsis.org).
Cheers
Paul Gregory
Project Lead – Aqsis
The reel itself is entirely motion graphics and has my temporary low quality renders of works that were made specifically for the reel, but I didn’t think that would bother anyone. And since it is a wip, please give any advice since now would be a convenient time for me to rework things or, if need be, start from scratch.
There is an attachment, and I will also embed.
Version
Nuke 6.1v3
Release Date
1 November 2010
Supported Operating Systems
Mac OS X 10.5 Leopard and 10.6 Snow Leopard (32- and 64-bit)
Windows XP SP2, XP64
Linux CentOS 4.5 (32- and 64-bit)
New Features
There are no new features in this release.
Feature Enhancements
BUG ID 13880 – You can now zoom in and out in the Keyer node’s keying range control and set values above 1.0.
Bug Fixes
BUG ID 12629 – A crash occurred when clearing a customer script.
BUG ID 13345 – Pro-Res 422 HQ output gave a low quality result.
BUG ID 13803 – QuickTime: Clicking Advanced when a node didn’t have an input produced unexpected behavior.
BUG ID 14221 – The default squeeze ratio of an exported FBX camera was 0.5 and not 1.
BUG ID 14239 – The playback rate was rounded incorrectly with Avid DNxHD movies.
BUG ID 14305 – QuickTime was crashing Nuke when using a Japanese locale.
BUG ID 14317 – Write: A customer script hanged when advanced was clicked.
BUG ID 14483 – Nuke crashed at launch when GenArts OFX plug-ins were installed.
BUG ID 14508 – There was a color shift in pro-res encoded QuickTime movies exported from Nuke.
BUG ID 14766 – There was an error with the EXR edge code metadata that prevented rendering.
ETC…..
Nuke seems to be pretty unstable for me (vista 64), especially a few nodes (i.e F-depth). Though, it’s not so bad. For when I’m at the computer, an occasional program restart is not so painful, given the auto recover feature. BUT, if I’ve left the computer over night for a render, and it crashes mid sequence, the bugginess is a problem.
An idea:
One solution that I implemented for an art installation was to have python send me a text message if my program crashed. cool, but still requires me to go to the computer.
My preferred solution: have some script detect an error/crash and have it abort, restart, reload my filel, and continue rendering at the place it left off. I’m using vista 64, but I can imagine a solution that isnt OS specific.
Is this possible? Ideas? Surely the big (and little) studios have dealt with this problem.
Thanks!
p
This is site is run by Sascha Endlicher, M.A. during ungodly late night hours. Wanna know more about him? Connect via Social Media by jumping to about.me/sascha.endlicher.
