Page 2 of 4
Re: Suggestion needed for Render job graph
Posted: Wed Nov 02, 2016 8:00 am
by calus
doca wrote:My point is that we have to define output and frame range much earlier in the workflow, and that will allow to run multiple render target jobs at once.
Right, that was also my point.
Frame range could fit in the
animation node, file format options and output path could fit in the
imager node.
Or they could fit alltogether in a new nodeType connected in a new renderTarget pin.
But let's be realist, that's not going to happen,
mainly to keep compatibility simple with older Octane version,
and with how the plugins work.
Re: Suggestion needed for Render job graph
Posted: Wed Nov 02, 2016 9:04 am
by doca
But let's be realist, that's not going to happen,
mainly to keep compatibility simple with older Octane version,
and with how the plugins work.
Hmm, isn't the point to make software better? If you do not make things good at start, what could you expect later?
Anyway, even considering your skepticism, node with framerange and output path placed between render target and render job will be better than current situation. Like this:
Re: Suggestion needed for Render job graph
Posted: Wed Nov 02, 2016 10:16 am
by calus
doca wrote:
node with framerange and output path placed between render target and render job will be better than current situation. Like this:
[/attachment]
I guess your example is exactly the
"render job group node" option proposed in the first post of this Topic

:
- "out file / frame range" = how the current "batch render job"already works ( "output folder" will be added )
- the "batch render job" in your example = "render job group"
But as in the node-flow these nodes are after the render target instead of before, they are more tedious to use.
Though, I think there's plenty of room to improve them, for example:
why this unintuitive way to add inputs instead of the one already existing in the UI for the geometryGroup node ?

- octane_2016-11-02_11-29-56.png (14.25 KiB) Viewed 5262 times
Ideally we should have 3 buttons :
add input,
remove input and
edit inputs(open a checkable list of existing targets).
Same thing for editing the Job list in the "render job group node" .
Re: Suggestion needed for Render job graph
Posted: Wed Nov 02, 2016 1:41 pm
by gah5118
calus wrote:doca wrote:
node with framerange and output path placed between render target and render job will be better than current situation. Like this:
[/attachment]
I guess your example is exactly the
"render job group node" option proposed in the first post of this Topic

:
- "out file / frame range" = how the current "batch render job"already works ( "output folder" will be added )
- the "batch render job" in your example = "render job group"
But as in the node-flow these nodes are after the render target instead of before, they are more tedious to use.
Though, I think there's plenty of room to improve them, for example:
why this unintuitive way to add inputs instead of the one already existing in the UI for the geometryGroup node ?
octane_2016-11-02_11-27-33.png
octane_2016-11-02_11-29-56.png
Ideally we should have 3 buttons :
add input,
remove input and
edit inputs(open a checkable list of existing targets).
Same thing for editing the Job list in the "render job group node" .
I like this idea of the buttons to add /remove/ edit... way simpler in regards to adding removing nodes; especially with the edit list.
Re: Suggestion needed for Render job graph
Posted: Thu Nov 03, 2016 12:51 am
by vijay
Thanks all for your valuable inputs. Noted all the points, will discuss with the team and try to get the best possible solution.
Cheers
Vijay
Re: Suggestion needed for Render job graph
Posted: Fri Nov 04, 2016 10:31 am
by abstrax
Hi all,
Vijay tried to incorporate your requests by adding more features to the render job graphs and adding a render job group node. You can render either a single render job graph or a render job group (or a group of groups) and you can specify the output directory in the render job graph pins. This directory can be overwritten by the directory specified in the render dialog.
I made a test build of 3.04.3 incorporating his changes. Please let us know if that is going in the right direction or what you would like to have changed:
Windows Standalone (ZIP archive)
Cheers,
Marcus
Re: Suggestion needed for Render job graph
Posted: Fri Nov 04, 2016 3:35 pm
by calus
abstrax wrote:
Please let us know if that is going in the right direction or what you would like to have changed:
Yes this is nice improvement and going in the right direction
Rendering several shots at once is now possible, thanks.
possible improvements :
In the "Render job group"
- add a third button "edit list" giving access to a checkbox list of
all "render jobs" in the scene. This is important for quick connection of lot of jobs.
In the "Batch render job"
- replace the "target count" by the same feature as in "group job": 3 buttons "add" "remove" and "edit list"(quick connection of lot of RTargets).
- need better arrangement and sections for the pins, seems kind of a random list at the moment,
also sub script node for logical group of pins (e.g. all format relative) would reduce the number of visible pins in the nodegraph editor.
- replace "override resolution" and "resolution" by "resolution percentage" defaulting to 100%.
- "render priority": "frame first" , "render target first" seems confusing,
what about "render sequence": "per frame"," per render target" ?
Re: Suggestion needed for Render job graph
Posted: Fri Nov 04, 2016 8:59 pm
by gah5118
AWESOME!!!!
I agree with calus except for one thing. resolution percent.... I would much rather it the way it is since there is a specific resolution I set my production renders to and I reset the resolution back and forth all the time when setting up my scenes. overriding by percent would give undesired results since it's not set in stone and based off the last setting in the render target.
Re: Suggestion needed for Render job graph
Posted: Fri Nov 04, 2016 9:10 pm
by calus
gah5118 wrote:
I agree with calus except for one thing. resolution percent.... I would much rather it the way it is since there is a specific resolution I set my production renders to and I reset the resolution back and forth all the time when setting up my scenes. overriding by percent would give undesired results since it's not set in stone and based off the last setting in the render target.
I Agree it was a debatable improvement suggestion,
let's leave "resolution" as it is.

Re: Suggestion needed for Render job graph
Posted: Sun Nov 06, 2016 8:13 pm
by abstrax
calus wrote:abstrax wrote:
Please let us know if that is going in the right direction or what you would like to have changed:
Yes this is nice improvement and going in the right direction
Rendering several shots at once is now possible, thanks.
possible improvements :
In the "Render job group"
- add a third button "edit list" giving access to a checkbox list of
all "render jobs" in the scene. This is important for quick connection of lot of jobs.
Ok, we can do that.
In the "Batch render job"
- replace the "target count" by the same feature as in "group job": 3 buttons "add" "remove" and "edit list"(quick connection of lot of RTargets).
The render job graph is just a Lua script graph sitting on top of the render job graph Lua API, allowing everyone to write his/her own render job implementation. Lua scripts can't create an arbitrary GUI in the node stack editor, but only input linkers, i.e. what you are asking for is currently not possible. What is wrong with the setting the render target count for the batch render job graph anyway?
- need better arrangement and sections for the pins, seems kind of a random list at the moment,
also sub script node for logical group of pins (e.g. all format relative) would reduce the number of visible pins in the nodegraph editor.
We will try to implement groups for input linkers, which should help here.
- replace "override resolution" and "resolution" by "resolution percentage" defaulting to 100%.
I think we will leave it as it is for now.
- "render priority": "frame first" , "render target first" seems confusing,
what about "render sequence": "per frame"," per render target" ?
Ok,noted.