renderfarm.ca looks down for a while now.
http://forums.planetside.co.uk/index.php?topic=6058.0
Any news about a cloud rendering service who are terragen friendly ?
Somebody on the forum ever try something in this way as a customer ?
The only 2 I know are GaragaFarm and EmecStudios...
When I ever get my personal site finished I'd like to render multiple animations for a showreel and at that stage I'm personally interested in being a customer.
garagefarm.net will open for TG2 next time, ask if it is available now....
http://www.garagefarm.net/index.php?option=com_content&view=article&id=95&Itemid=89
In addition to the existing commercial renderfarms - I'm extending and rewriting my TG2 batch program to allow distributed rendering over the net for any licensed TG2 user who chooses to join the "Community farm".
You will be able to:
- verify that its not possible to hijack and run a virus on your machine - uses tgd files only.
- submit jobs that are tiled single images, crops, animated sequences, or panoramas (everything TG2 Batch does).
- batched variations of params in the TGD files
- choose when to offer rendering services
- share your cpu with the community
(compositing or assembly will occur on the submitter's machine).
There will be a server that you submit jobs to, then parcels out the individual render tasks to remote hosts. Resulting frames will accumulate in dedicated ftp directories for download by the job submitter....At least that's the probable mechanism right now...
I am aiming for Jun 30 as a release date as I just lost a big job and have time on my hands right now... :-(
In Python and QT UI. Needs to run TG2 command line so you must be a licensed TG2 user to offer rendering help...
but anyone can submit a job...
more news soon....
sounds great ^^
This is the program I was talking about last week Seth. Could be very useful for smaller farms and the web rendering sounds prommising.
Richard
yup ^^
sounds good neon22...
When i wrote the first message, i was thinking to the apophysis community rendering system and i forgot to talk about.
http://community.electricsheep.org/node/325
This kind of system looks very good to me but i don't know how much power we can get of this. Hard to know how many users will share computing time, i feel like a bad ratio Client/renderer every days. But i could be wrong.
An other way to proceed will be to create an association...
with a year subscription, the people who subscribe get acces to a private render farm manage by the association (rent by the association ).
I really need to create a excel sheet just to know how much we need for this.
Just to know,how much you will pay for an non commercial rendering association year subscription ?
That, of course, totally depends on what you get for it.
i send a mail to a render farm i've already contact and work with.
I asked them the price for 5 computer*4core*3ghz 1 year 24/24 with multi-users system.
Not the best computer in the world...
It can give a price idea...I will forward what they reply to me.
so in fact the website was non updated since a long time and they have super death computer now.
So
5 computer
24 core
700 euros *5 computer =3500 euros*12 month= 42 000 euros
42 000 euros !!!!
60 419,136 dollars !!!!!
mmm ::)
if 10 user : 4200 euros for one year !!!!!!!
if 50 user : 840 euros
if 100 user : 42 euros
mmm
100 user who pay 42 euros for 5 computer....no i don't think so.
50 user 840 euros : no i don't think so.
10 user yeah looks great...but we don't think so.
So next step : find the same thing cheaper,and cheaper, and cheaper ;D
fact 1 : if you want to render terragen animation it can cost money at full HD ;D
fact 2 : if you want to render terragen animation at home alone it can cost you your lifetime.
fact 3 : The community farm idea rocks
fact 4 : i need to find something cheaper in india.
I would be totally fine with paying 42 euros/year. Even 100 euro's/year.
The difficult thing with this is, is how is it shared?
If you share it with 100 users, for E42,-/year, that would mean 3,65 days/user/year.
In this case the money wouldn't be a no go for me, but the availability.
Or am I too pragmatic here?
no you're right.
It's too expensive and have any chance to go with 100 user.
I keep looking for alternative.
Any idea, welcome.
I've been involved with the community sharing of resources since about 1990 in the UK when I got all the big 3D post houses to share their source codes and hacks (it was called s-hacks) for a 3D system (long gone) I worked on at the time.
It was inspiring to see so many people and companies - in competition in the marketplace - working together for their mutual gain. Although it did help that we didn't all go and tell upper management what we were doing... :)
Specifically I am proposing that anyone, who can see the advantage, can add their machine to a distributed renderfarm at the time of their choosing. For an example where this works right now check out - http://www.renderfarm.fi/
Their model is slightly different on two counts. Its always free and it uses the BOINC distributed render mechanism. BOINC is very nice - it is well established and uses the screensaver kind of approach seen in seti@home and folding@home etc.
I should probably just use this mechanism - it has many advantages. But the curve for me to use it is too high in comparison to what I already have. If someone else wanted to setup using BOINC I would happily support them. It would probably last longer...
However I also have some specific issues I would like to address:
1. We need to use only licensed copies of TG2 to render. Happily the licensed TG2 allows CLI launch. Therefore we can safely keep within the terms of the license and allow only people with licensed copies of TG2 to render. This means our community can't encompass all the people who might want to help. We instead have a closed community of licensed users.
2. IWBNI we knew there was no chance of a virus infection.
- The engine code will be in python and quite small. This will be a human readable program.
- The data transferred will be tgd files which will be launched by executing TG2 with the file as an argument. So therefore safe.
- The webserver will serve html. ftp will gather the data
3. There are several use cases it would be good to support:
- rendering large images as distributed tiles (GI is better behaved these days but still this may be unworkable)
- rendering animations
- rendering panoramas (just an extension of tiled rendering)
- rendering cropped portions with varying parameters to:
- better understand the effects of params
- to find a sweet spot nearby in parameter space
- to see the effect on rendertime of parameter changes
(TG2 batch does all these currently but its hard to install and out of date for the latest version of TG2)
4. I have an idea for an addition to make also. This involves setting preferences for the render client to select what gets rendered. I propose two methods:
- One is to wildcard the name of the job submitter. In this way I can submit my own job to the farm and indicate that I would like my system to preferentially choose to render my own jobs.
This ensures I spend all my resources on my own work first. This invites me to use the renderfarm all the time even for my own simple stuff. If there are cpu cycles left over in the morning then they will be used to render other people's work when mine is done.
I can also indicate that I want to render (say) Dandelo's work because I think the current crazy and ill-advised project he is doing is interesting and I want to help out. :P
- Two is for monetary gain. If I submit a job and its important to me to get it rendered as soon as possible. I could ask everyone to wildcard my name or I could put a value on rendering it. This value would be distributed across all the members who helped me render it (based on weighted rendertime).
So as a renderer I can say I also prefer jobs with monetary reward. This will preferentially have me rendering frames I will be paid for. Its not going to come to much - no one's going to get rich doing that but its a way to increase the render pool, get recompensed for helping the community, and offset electricity costs. I guess we'll be trading carbon credits one day...
If you own a renderfarm - you can play as well - if you buy a TG2 license...
Anyway that's my 2 cents... I have to upgrade TG2 batch anyway and I've always wanted an excuse to play with django...
Feel free to critique, comment, abuse, etc. I'd like to make it useful above all other considerations
QuoteThis ensures I spend all my resources on my own work first. This invites me to use the renderfarm all the time even for my own simple stuff. If there are cpu cycles left over in the morning then they will be used to render other people's work when mine is done.
I can also indicate that I want to render (say) Dandelo's work because I think the current crazy and ill-advised project he is doing is interesting and I want to help out.
perfect.
QuoteTwo is for monetary gain. If I submit a job and its important to me to get it rendered as soon as possible. I could ask everyone to wildcard my name or I could put a value on rendering it. This value would be distributed across all the members who helped me render it (based on weighted rendertime).
So as a renderer I can say I also prefer jobs with monetary reward. This will preferentially have me rendering frames I will be paid for. Its not going to come to much - no one's going to get rich doing that but its a way to increase the render pool, get recompensed for helping the community, and offset electricity costs. I guess we'll be trading carbon credits one day...
just yeah...
all of this sounds good.
It sounds very interesting so far. I especially like the idea of being able to prioritize users in the queue so you could use it as your own render manager as well as for other people's stuff and basically just leave it up all the time.
One issue that arises, both out of the idea of prioritizing your own work and also just generally, is what happens with longer renders. Will there be limits on maximum single render time? Or maybe each user can set their own limits? Let's say someone starts up an animation that takes 1 hour for each frame and they're half way through a frame (30 minutes in) when they decide they want to render something of their own. Does the existing render and 30 minutes of render time just get killed and lost, or is it paused, or do you have to wait for it to finish? 1 hour isn't even necessarily that long for some renders, and without limits I could see people just cranking the render settings and submitting jobs that will take hours or days. So I guess my point is to be wary of (and build in limits/defenses for) abuse of the system, both intentional and accidental.
- Oshyan
Yes its an interesting problem. I hope it will become self limiting and its also one reason why I have tiles.
I intend the render client user to be able to say when the rendering process can run. I typically use my CPUs and only want to allocate them to the community in (say) the evening when I go to sleep (hopefully). Also if the batch portion does its job I will have many choices to make informed decisions about param settings available to me when I start the next days work.
- So you set the start time and indicate the likely end time (you generally know when you leave the computer but not accurately when you will return)
- You manually choose when to stop the renderer. So if you arrive and a frame is partway through rendering - its up to you to determine to throw the render or not. The more accurate you are with your timing indication, the less you will waste your own CPU resources. I would suggest that if you are being paid for a frame and it was 3/4 through and you were early to your system - then maybe you would let it run to completion. YMMV...
- When asking for a frame the system indicates how long until the expected end of service is. If the time is "soon" then the server will only send you short frames (statistically derived on average). This is to prevent sending an hour long frame down 10 minutes before you think you will return and stop the renders. Of course - if there aren't any short frames in the queue, then you get a long frame and we all gamble...
In this way we try to minimise the wasted time.
As a job submitter - If you submit a job and you get very few frames back you have a couple of choices. You obviously want more frames. So you can choose to tile the image, or you can try to reduce the rendertime.
Tiling will get more optimal use of the community resources. (Your own machine will reassemble the tiles). The issue of GI artifacts between tiles has attempted to be addressed but I am unsure as to its final state and the applicability of timing and optimal tile size... Maybe we will do trials and find out...
Ultimately its frustrating if you never get any frames back because they take 6 hours each. So modify your behaviour so you get frames completed.
I think you have some good ideas for addressing the issues I mentioned without putting in hard limits or being too intrusive. It's great to see you've got all that in mind already. There's a lot of potential for a system like this. Thanks for spearheading the development!
- Oshyan
All sounding really great, just one issue that springs to mind. How would you handle imported assets, both from a licensing and purely practical way. Many of my scenes are not purely procedural and rely on displacement maps, these "can" although not by any means always, be up to a gig in size, more usually down in the 200k region. How would you propose sending these across a network and secondly when imported assets are used such as X-Frog models how will you get about the licensing issue since the animation will be rendered on machines that do and do not have a license?
Cheers
Richard
Good questions Richard, I second these.
Another possible "problem" is the renders itself. Rendering animations is fine, but I couldn't stand it at all if I'd notice that the project uses stupid rendersettings which makes things utterly slow. In my eyes it would become "useless" if I simply know it could be much faster.
Good documentation is critical in regard to this and maybe the current rendersettings sticky thread is a bit outdated with the new raytracing options for atmosphere for instance. Also, somehow, people don't seem to find their way to it anymore. Which is strange, as it's clearly a sticky thread and should ring a bell to everyone visiting the forums for the first couple of times.
I'll think about a (re)new(ed) rendersettings guide with more practical examples.
Quote from: cyphyr on June 01, 2011, 02:54:11 AM
... one issue that springs to mind. How would you handle imported assets, both from a licensing and purely practical way. ... displacement maps, ... up to a gig in size, more usually down in the 200k region. How would you propose sending these across a network and secondly when imported assets are used such as X-Frog models how will you get about the licensing issue since the animation will be rendered on machines that do and do not have a license?
Cheers, Richard
Size - the program parses the tgd, captures all referenced files, zips them into a dedicated directory along with a modified TGD pointing to relative paths for the assets. This gets ftp'd up to the server and redistributed to render clients. Its the smallest mechanism I can think of.
The licensing issue is a great question. Others address this problem by adding a license to the submitted file.
E.g. copyright or one of the CreativeCommons licenses. Basically by submitting it you are saying it is (say) copyright and not to be copied. All users who render have to agree to abide by the copyright rules and not use the assets. E.g. a choice about not participating in copyright scenes, or agreeing to abide by the copyright.
In practise any IP protection is lost except by "agreement". Anyone could look inside your files and see how you did things, or get hold of assets you may heve licensed yourself. In practise sending the same information to a commercial renderfarm exposes the user in the same way but you have a more legally sturdy framework to apply legal redress.
I suspect that this mechanism may not be strong enough for some people and they will choose NOT to use the community renderfarm...
Quote from: Tangled-Universe on June 01, 2011, 03:20:13 AM
... Another possible "problem" is the renders itself. Rendering animations is fine, but I couldn't stand it at all if I'd notice that the project uses stupid rendersettings which makes things utterly slow. In my eyes it would become "useless" if I simply know it could be much faster.
Yes this could be annoying to you. However if you did look inside and see this - you (or someone else) might send them a note - and overall everone would improve.
But many non-"animation" and non-"big image" renders will flow past unseen - if it's all working smoothly.
Hopefully the end result will reward positive effort and encourage people to get "better" at these aspects....
Neon, did you ever get anywhere with this? I'm toying with the idea of starting a renderfarm service for TG2, since I already have a healthy chunk of gear.
I kept on it for a while but it lapsed when I had some paid work.
Must admit to letting it go for too long. I clearly still need it and I'd like to get back and finish it.
Perhaps I'll have some time over the Holidays...
Thanks for asking.
Hey! Any news on this? I'd be happy to donate some cycles and help with the renderfarm if possible. I'm currently taking part to the renderfarm.fi but I don't use blender so I'd much rather support tg2 renderfarm!
-NRJ
We are starting a render farm service in direct competition to the others that are out there now. When fully operational, we'll be better than any other farm out there in every aspect. We're trying to go beta by June, with public release hopefully in July.
Sounds great. Do keep us updated!
You can bet I will. 8)