Support of the 'merge' ROP on houdini
Quote from SciMunk on 25. January 2019, 14:45Hi, so I realised I'm making lot of ROP node in my houdini scene and twice as much render export job on prism, so I was wondering if it was possible for prism to support the merge rop and basically rendering multiple rop at once ?
for exemple, I have . redshift rop (Background, Character, Extra), all render the same camera, but have different setting and script to render different part of the pic.
on prism, I need to create a export job for each of these rop AND for each of the camera I want to export
Background_Cam1 / Character_Cam1 / Extra_Cam1
Background_Cam2 / Character_Cam2 / Extra_Cam2it basically grow exponentialty for each new rop and camera.
when submitting to deadline, each of these job will need it own instance of houdini to run and execute network, for me they need each 90s before they start rendering (multiply that by the number of frame and rop)
if we could use a merge, and make houdini succesively render each rop on the same instance, it do not need to recook everything, and it far easier to manage less export job on prism.
I know deadline have their own 'deadline' node on houdini, in which you can input multiple rop, and then use a 'submit to deadline' button, this is super handy for automation, if we could have the same kind of node for prism that would be a blast !
Thanks!
Hi, so I realised I'm making lot of ROP node in my houdini scene and twice as much render export job on prism, so I was wondering if it was possible for prism to support the merge rop and basically rendering multiple rop at once ?
for exemple, I have . redshift rop (Background, Character, Extra), all render the same camera, but have different setting and script to render different part of the pic.
on prism, I need to create a export job for each of these rop AND for each of the camera I want to export
Background_Cam1 / Character_Cam1 / Extra_Cam1
Background_Cam2 / Character_Cam2 / Extra_Cam2
it basically grow exponentialty for each new rop and camera.
when submitting to deadline, each of these job will need it own instance of houdini to run and execute network, for me they need each 90s before they start rendering (multiply that by the number of frame and rop)
if we could use a merge, and make houdini succesively render each rop on the same instance, it do not need to recook everything, and it far easier to manage less export job on prism.
I know deadline have their own 'deadline' node on houdini, in which you can input multiple rop, and then use a 'submit to deadline' button, this is super handy for automation, if we could have the same kind of node for prism that would be a blast !
Thanks!
Quote from RichardF on 27. January 2019, 14:20Interesting topic, since I want to improve the Houdini part of Prism a lot.
Are you looking for a way to create multiple export states in Prism at once or do you want to manage multiple ROP nodes with one export state? In that case the settings of the export state would be applied to all the connected ROP nodes, which could be less flexible.
Does the Deadline node create one job on the farm or does it create a job per ROP? Currently I haven't installed Deadline so I can't test it.
Interesting topic, since I want to improve the Houdini part of Prism a lot.
Are you looking for a way to create multiple export states in Prism at once or do you want to manage multiple ROP nodes with one export state? In that case the settings of the export state would be applied to all the connected ROP nodes, which could be less flexible.
Does the Deadline node create one job on the farm or does it create a job per ROP? Currently I haven't installed Deadline so I can't test it.
Quote from SciMunk on 27. January 2019, 15:38managing multiple rop with a single export state, the point is that I have to render the same frame with different rop setting, but exactly the same frame number or camera (so the export state applying their setting on each rop is fine)
deadline create a group of job :
managing multiple rop with a single export state, the point is that I have to render the same frame with different rop setting, but exactly the same frame number or camera (so the export state applying their setting on each rop is fine)
deadline create a group of job :
Quote from RichardF on 27. January 2019, 16:28But I guess each ROP needs a different taskname. Otherwise all export/render states would create different versions in the same task. This could be handled by a dialog which lets you set those task names in a table, which lists all ROPs connected to that merge node. But I could imagine that someone wants to use different outputtypes or different deadline submission settings.
I thought a bit about it and maybe there is a more advanced and future-proof way:
The state list is already a tree view. But currently the only state which can have child states is the folder state. When the export state could have child export states, which would inherit the parent settings that would be very flexible. Then you could create an export state and connect a merge node to that state. Then the export state checks the inputs of that merge node and creates a sub-export state for each rop, which are collapsed by default. You can set settings on the parent export state, which will be applied to all subexport states. You could expand all the sub-export states and override individual settings on them, which should not be inherited from the parent.
But I guess each ROP needs a different taskname. Otherwise all export/render states would create different versions in the same task. This could be handled by a dialog which lets you set those task names in a table, which lists all ROPs connected to that merge node. But I could imagine that someone wants to use different outputtypes or different deadline submission settings.
I thought a bit about it and maybe there is a more advanced and future-proof way:
The state list is already a tree view. But currently the only state which can have child states is the folder state. When the export state could have child export states, which would inherit the parent settings that would be very flexible. Then you could create an export state and connect a merge node to that state. Then the export state checks the inputs of that merge node and creates a sub-export state for each rop, which are collapsed by default. You can set settings on the parent export state, which will be applied to all subexport states. You could expand all the sub-export states and override individual settings on them, which should not be inherited from the parent.
Quote from RichardF on 30. January 2019, 2:09That would be nice, but it's probably not that easy to read and understand all the code. Let me know when you have any questions where to find what.
That would be nice, but it's probably not that easy to read and understand all the code. Let me know when you have any questions where to find what.
Quote from SciMunk on 30. January 2019, 12:35It a little bit more difficult with monolithic file, I personally prefer abstract and well organized small file, but it still doable, I used to read the whole minecraft code back when I was moding it ^^
It a little bit more difficult with monolithic file, I personally prefer abstract and well organized small file, but it still doable, I used to read the whole minecraft code back when I was moding it ^^