Who''s whining?

If there''s a problem, why not fix it?

Since render time is obviously long for just about everyone, why the @#$# is it bad to find a solution?

So let me get this straight for the record... if you could click a button, and have your render time cut down to a fraction of what it was before, you would NOT do it? am i correct here?

quote: Original post by aegrimonia
So let me get this straight for the record... if you could click a button, and have your render time cut down to a fraction of what it was before, you would NOT do it? am i correct here?

No, his point is that it is not as simple as that. If you''ve got a scene that''s complex enough to take more than an hour or so to render (and hence is a candidate for networked rendering) then you''re going to need at least several megs of bandwidth to transfer it to client PCs. And you''re going to need to send it to several PCs... Also, rendering a complex scene can take up tens or even hundreds of megs of RAM, another resource which people can''t just give out willy-nilly.

The reason most distributed systems (like SETI, etc) work is because the amount of bandwidth and memory needed to do the calculation is insignificant next to the amount of CPU time required.

codeka.com - Just click it.

Well, sure, it would be MB of information.. but it would be raw binary data... and that compresses very well during transfer... ever notice the send speed of a .bmp or a .txt file? uncompressed data like that would send very very fast. Most people, especially those that can afford to buy 3DSMAX in the first place, have Cable or DSL, so uploading a 10MB uncompressed file to someone would take a minute or two at most, though i can''t tell you for sure, because i have never sent anyone a 10mb text file. But the compression ratio has to be around 10:1 at least.

ok, lets pretend that ppl would run this app if it was availible.

downfalls to expect:
1. as said before someone shutting the client down to play games, or shut the pc down when down using it. it would suck to have to wait on that person for your data if they went on vaction.

2. that aside, network rendering only helps when rendering animations. when rendering a single image, you have to worry about breaking it up into rects and hope that the clients dont need to render too much redundent data to correctly render the image. some scenes just cant be rendered well like this and would actually be slower to render. this is assuming a lan where 100% cpu speed, memory and scratch disk space is availible for the render. in a seti@home deal, your lucky to get 10% of cpu, ram, and about a few megs of scratch space. ppl will NOT run a client that requires all their cpu time and massive disk space or memory usage.

3. since rendering animations is the way to go and you would split the animation bewteen mulitple computers (each one gets a different set of frames to render). a compressed image will get a ratio of 3:1 if your lucky using lossless compression, 5:1 if using something like jpg (but now your losing quality). which means about 200k-500k per 800x600x16 image. not too bad bandwidth wise. 5secs at 24fps would be about 60mb worst case (assuming 500k per image). takes about 10mins or so to transfer on a cable/dsl line IF they allowed full usage of the line. expect to get 10-20% of that which means your back to almost modem speeds and it will take 2hrs or so. this of course is saying that they server only one person at a time. if the resources are split, explect longer delays. uncompressed data can be compressed, but comparing a text file to an image file is just plain ignorent, and you cant compress data thats already compressed.

4. resource usage. if the client is allowed to handle multiple requests, then the other requests being handled will take longer with the already capped resources. if a client can only handle one person, then there may be a shortage of clients for the render and you will have to wait in line for the next slot to open. also a user may cancel your request midway if he notices a friends request on the queue, making you lose all the time invested waiting for the client to finish. you CANT safegaurd against that, otherwise your creating a viral application that no one will use.

out of curiousity how long does your avg render take and what do you consider to take too long? i hate to say it, but something like this is virtually impossible to implement in a usable way. no one will give up the cpu/ram/disk/bandwidth required to speed up the render process for some total stranger. especially when its possible that YOU turn off your pc while the client is rendering data which means they have to store it to disk until you turn on your pc. this of course means they lost you unless there is some master server that mediates between every one.

here is a good question. would you give up 100% cpu/ram/bandwidth to render a strangers data for 2 or more hours straight?

Man, you guys are about as visionary as a blindfolded Mormon Preacher

Ok, let''s look at this another way, and we''ll break it down so the children can get it.

1000 people (that''s 10 times 100) are using the rendering client, allowing their people to use their computers.

You''ve got an animation you want to do.

It''s 5 min long.

each frame takes your computer about 1 hour to render one frame, you''ve got say a P3 1.1ghz.

Now..

5min x 60sec/min x 24frames/sec x 1hr/frame = 7200 hours.


7200 hours / 24hrs/day = 300 days total rendering time.

7200 frames/7200 hours.

Do it yourself, and it''s going to take you 300 DAYS!!!

do you get it now?

Ok, enter the Network assistance.

Add a timeout feature.. when the rendering client is installed, it does a benchmark, a simple one to get a basic estimate of the overall speed of the machine it is being installed on. And, since apparently some of you cannot connect the dots yourself, the software has a select menu:

Allow rendering only:

_ When comptuer has been idle (XX) minutes
_ During the hours of (XX) PM/AM and (XX) PM/AM

(user selects whichever he wants)

I''m sure some of you sleep occassionaly, and there is theoretically time when you aren''t in front of it, that is prime time for donating your computer time.

Now... back to the benchmark and the artist wanting to render his project.

His software goes out and finds a client that meets the required criteria (it has been idle (XXX) minutes, and it is between the hours of (XXX) and (XXX). It''s ready to render. His software asks the client (how fast are you?) the client says (my benchmark is (XXX). His software calculates it''s going to take this computer about (XXX) to do this scene. It sets a timeout at (XXX+YY) minutes or hours or days.

Send the computer the information.

Rendering, rendering, rendering.
(user gets on his computer)
Rendering stops.
(user stops using his computer)
rendering continues.

If the timeout time is exeeded, the original host program asks the client software how much is done of the scene, the client software replies back (XXX%), a window pops up on the artist''s computer

"computer X has exceeded the time alloted to render the scene, the scene is XXX% completed, would you like to wait?".

Yes: continue with render
No: Cancel render and find another host.

Want to get fancy? have the client pass the data onto another client when a spot is available, where it will pick up where that one left off.

Scenes don''t have to be rendered in linear order, they can be rendered in any order, and put together by the host software. Something very similar happens all the time.. it''s called TCP/IP, maybe you''ve heard of it?

break it up into pieces, and handle each piece separately.

If it reduces the overall time by only 10%, in this 5min animation.. that is ONE FREAKING MONTH.

green?

AND.. if you want to make a further incentive..

Let someone get paid for their renderings...

$x.xx per frame.

I''d bet you lots of people would leave their computer online allowing renderings if they were getting say $.25 or $.50 a frame...

And that''s cheap compared to going into a rendering house and having them do it for you, or buying 10 more computers to handle the workload.

sorry this is a VERY long post, but interesting read.

first off reducing 300 by 10% means it still takes 270 days which is quite a long time. let me throw some numbers at you since you like them so much.

lets pretend you have your 5min animation. we will also saying that there is some master server that allows everyone to log int so that they can find each other even after ip addresses change. after all you dont want to lose your work after it you shut your pc down.

1000 clients availible. pretty good number to use, not too high, but maybe a bit low but if its for broadband only then it might even be perfect. thats ok, after all since we ant to look at the avg case, and most likly only 1000 clients would even be up, running, and accessible by someone at any given location on the net depending on there connection. this is a very good estimate that shows you are at least thinking things through and are not being mindless.

using the 1hr per frame AND assuming that the network rendering software is completly free (i guess blender''s rendering is pretty good so its not completely out of the question). it takes 300 days to render 5mins of animation.

also i will put forth that the software has a screen saver feature and starts working after X mins or between certain times of the day. i will also put forth that many ppl have there pc goto a low power mode after 45mins of idel time. i do, and so do many of the ppl i know. ang pc config is likly to be a 600mhx p3 with 128mb and a modem connection. forcing to broadband only is an option, and reduces the number of availible clients.

now having a benchmark is a smart idea, and could potential give a rough esitimate of the time to render a frame. though it would not be useful to gauge since ram plays an important role, and how much is actually availible for use also affects this. thankfully the OS will dump apps that are not using the ram to the swap disk so its usable by other apps (like your network renderer). also if a user is tight on diskspace it could cause problems if the rendering app needs it.

also you assume many ppl leave their pcs on 24/7 and will have constant contact during the rendering of the scene. many times ppl will shut there pcs off during your render and will not be able to contact you in a timly fashion. naturally you will then have some other client do the work, and the original client will delete the work that it did. so its wasted time, because unless a pc stays idle for X*numberOfTimeIdle+1hr+transfertime you will never get anywhere. numberOfTimeIdle is a number for how many times ptentially a user may stop the work in progress because they left the pc idle a short time to get a drink or goto the bathroom.

again all hypothetical, but a rendering may take 1-12hrs or even a few days realtime instead of an 1hr per frame. depending on if the person leaves the pc on overnight (then you are lucky and get tons of rendertime) or like the avg joe who will install this, shuts the pc off after each use not getting much of any rendering time. unfortunatly due to the invaisive nature of the app (ie uses all avaiblible ram and cpu) you can expect it to be always running quietly in the background like seti@home. this is how come seti@home works well, it uses little ram and can be configured to run when the cpu is idle. so a user typing a message like this can be crunching numbers for seti and not notice an impact on performence of the pc. on the other hand running a rendering app will make typing difficult and surfing impossible because of all the ram required. cpu can always be throttled, but using only 10% of the cpu means now the render takes 10hrs realtime per frame. though that could be done constantly while the pc was on, however like said before the ram requirement makes this impractical and you are back to hoping the clients keep their pcs on long enough to be idle.

i am not saying its a terrible idea, just saying its impracticle to expect much if anything from a system like this where the client can stop rendering for long periods of time. what you should do is get some friende to install BOB and use blender to render across the net. see how things go. you can get the software from http://www.photopro.co.uk/blender/Index.asp, but beforewarned that it only renders blender files and you have to convert your file to the blender format. this is pretty easy once you get blender which is the tough part since the official site no longer has it. check the forums since ppl have placed links there (a whole topic is devoted to this). you can also check places like fileplanet.com or download.com for blender. please tells us the results of your findings. is it actuall that much faster (btw this system always uses 100% cpu so its not exactly what you want but i am pretty sure its open source (i know the offical client/server is opensource, but not sure if).

i will agree on a small scale with ppl you know that can contribute 100% to the system it would work wonders, but on a large scale with ppl contributing varing amounts of time it becomes useless.