Hey Nukers,
I didn’t include the proxy mode feature in the last build because we haven’t decided if enabling proxy mode should be coupled to the Nuke viewer proxy toggle or if there should be some new xmesh global/local toggle.
The motivation for using a proxy sequence would be if you had very heavy geometry and wanted to reduce the amount of disk reading. Using a proxy mesh for speeding up displaying and rendering probably won’t make a big difference in most cases since graphics cards are fast. The downside of having a second toggle for xmesh proxying is ensuring it always does what is intended. The rendering of frames should always use the render setting.
Ben
I would vote for a separate xMesh proxy mode from the resolution proxy. Just because I’m working in a lower resolution doesn’t mean I don’t want to see the real geometry and vice versa.
Would you need local or named proxy groups?
Or would a single global toggle per nuke script?
Where should this toggle reside? I don’t know if the viewer ui could be customized this way. I’ve never tried.
I also need to make sure no one leaves this toggle on accidentally when they produce an image sequence. Any advice here?
I would be OK with a single global switch. You could potentially create a enumeration dropdown in the project node.
Nathan Rusch says there is a nuke.addBeforeRender(python) command.
You could even link that to every xMesh reader so if you changed it inside the reader it would push the update to the project settings or vice versa.
This looks like a good idea. I guess my main concern is that the user feel like this setting isn’t buried and forget to toggle it back to full. I need to find if there is render callback I could hook into? Would it only be for rendering? GeoWriter should probably trigger this as well.
I think there are callbacks for most major events.
As to being burried, like I said, I would reference this into every xMesh reader node under a proxy tab. They would all just be linked to the nuke.root node.
I guess the next logical question is if this should be a hybrid python/NDK plugin? If we are controlling two way communication with a python setting for the global proxy mode, we need to have the callbacks correct to keep everything in sync. On the other hand it might be pragmatic to make the entire UI in python and just leave the core in c++.
If you make it Python, people could break the connection and/or set the proxy mode through scripting. I wouldn’t hard-code it into something that isn’t accessible. Your callbacks could be on the project level setting. Have a Render Proxy Level option and a Working Proxy Level and then link the Render Proxy level by default to the root Project knob. Having one node which was independent then would be as easy as right clicking and breaking the expression.
Actually now that I think about it, I see what you’re saying. Dropdowns don’t really work like all the other nuke knobs. So users wouldn’t be able to configure it anyway.
The two advantages to making a python UI would be: 1) studios can make the ui exactly how they like it. 2) I still haven’t figured out how to set a filter on the file browse, and also haven’t seen best practices for calling python in an NDK button.
Ok, here is my proposal. (obviously there would be callbacks on the Use Project Settings checkbox to enable/disable the sequence).
Python scripts could then easily change/uncheck the Use Project Settings. You would just need a callback when replaces the displayed Display/Render sequence drop-downs with linked versions in the visible track when you check/uncheck use Project Settings.
Looks good. I’m just working on the callbacks now. KnobChanged, addBeforeRender, addAfterRender.
I just want to make sure this makes sense.
Determining if the request is in a render means look for the “beforeRender” Callback. It does not mean opengl view verses scanline renderer. Correct?
I believe it’s the difference between Write Node vs Viewer Node for callback.
Yuck. Then that’s the opposite of what one would want. Write geo should be the same as scanline render.
What about a setting per view? Would that make more sense?
