BOINC RENDER FARM 64 BIT
So using a service like BOINC would be terrible for something like Renderman for instance, there is no way to ensure everyone is using the same system, for all you know it could be a mix of 32 and 64 bit CPU’s from Intel, AMD, SUN etc… even though they all do the same thing (compute) - the differences are there and this is reflected in the software you use. While the still frames would be barely different to the naked eye, in motion you will notice right away.
BOINC RENDER FARM FULL
So when you render two different frames from two different architectures there can be a noticble flicker when viewed in full frame rate. Not everyone uses the same CPU type and this becomes a problem when working with procedural texturing, the shaders are compiled for that system and things like fractals and noise render slightly different. This is not so much an issue when your render engine is internal to an app like Maya, Max, Blender or LW however when working with Renderman or MentalRay all your assets are external to the app so again that factor of ensuring a duplicate environment is nearly impossible when dealing with a cloud.
Another reason is as mentioned above, the rendering software NEEDS to be exactly the same as your system and there is no sure way to make sure that it does. One reason is that you are not in control over other people’s systems nor their network connection. This would be a possible solution to cloud computing but it is not always the best option. If you are transfering data to massive cluster like Google or Amazon it should not be a problem on their end but there will be a a LOT of data being shuffled around from your system, or server or wherever. Most production rendering consists of large files, such as texture maps and objects, so unless you have a high bandwidth connection these will take time to transfer. Something so simple as a single missing shader can cost a fortune. Grant you it would be foolish to NOT ensure that all your libraries, code, assets and so on are not on the cloud first but we are human and we do make mistakes. Not all render engines are the same, some such a Renderman use a lot of custom shaders, shadow and baked passes etc… The only way to ensure that there is consistent environment is to have the farm on a network, otherwise you run the risk loosing things, say a single shader that did not make it to the cloud for some reason will RUIN your render, and just imagine 1000 bad frames. I have to agree that cloud rendering is not the best option when dealing with high end rendering. Like a crime one has ask a core question when the push for the cloud is brought up… There is a reason why we moved away from it. In the old days we used to hate this kind of dependence on a SINGLE POINT OF FALIURE.
So why not call the Cloud by its true name. Why do this at all, and to be frank GPU rendering promises to erase any advantage in speed cloud computing might offer?Īnd btw way, call me an old fart, but I heard of this tune before. What happens when you have a close dateline and the cloud is not there? (rigs, shaders, etc) you may have on your scenes?Īnd how about the liability issues with your clients over their Ip being share with another third party?Įven Google has dropped the ball in terms of dependability of the cloud.
How well do you trust that vendor in handling your data?Īre you sure you want to trust them with all the intellectual property of your company
Well when was the last time you rendered a project that you did not have to tweak?įirst you would have to send your assets, to a third party to render. I would only use this for finals you say? You would have to pay, either by instance or subscription, to be able to With the cloud, you would be moving towards a Rendering as a service economy. The big three in my book are: Cost, Security and Reliability. My biggest issues about the cloud are simple.
0 kommentar(er)
