I think there is a little misunderstanding of how ORC actually works, so let me explain.
so in my understanding, when rendering a still image on ORC, it still limit to 20gpus, which giving me around ~800ob and it's the MAX vaule I can render a still? for 2.x will be even worst(12x40=480ob), if I want to say 200gpus for a still, it will never gonna happen due to v3 20gpu limitation, so for a still render it's a dead end ?
ORC doesn't allocate multiple nodes to render one frame, instead it assigns many nodes to animation jobs. That means if you're rendering a still image you'll get only one render node which is a 4GPU node. Multiple nodes per still frame is a feature for the future and won't happen anytime soon.
for animation, does the orc split a frame to a group of 20gpus(assuming the scene use v3)? and then split another of 20gpus to render next frame etc..and it run all across the whole animation range? ok if this formula is correct, which means:
For rendering a frame will cost: 10$/50min * frame render time = 0.2$ (If a frame rendered using 20gpus will cost 1min rendertime, then this frame cost 0.2$ , if the frame cost 10min rendertime, then this frame will cost 2$,etc....you get the point...), also, does the scene data transfer will get charged during render time?
Not quite.. Again, there is no network rendering involved yet, only a render node per frame.
Best,
Vladimir
