#Batchfiling Investors
14 messages in this thread
I would like to explore an idea with the Forum group. A few of us have
indicated that we have a need for a executeable routine that would:
1. permit remote execution of 3DS projects
2. permit "renderfarm"-type applications where multiple machines are
brought to bear on a rendering project
3. permit other "sophisticated" executeable render applications of 3DS
files.
I would like to suggest that, if we can find a group of "investors" (which
I, for one, am willing to be) and a competent 3rd party to develop the
routine(s) at a reasonable cost, that we consider hiring the work out as a
group. Those who participate would get the program, of course, and could
also participate in potential profits from further sale of the program to
other users. It seems a bit non-traditional, I know, but that's what a
Forum like this is all about. Right?
Comments?
Ken Loss-Cutler
Ken:
Actually, not that non-traditional! I recently followed a thread on the
Internet where 50 or 60 companies got together to hire a firm to write a
specialized Unix program. They raised $250,000 to hire the programmers,
each become beta-testers, got a copy, and are now selling it in the Unix
world.
What other features for this remote-control renderer would users on the
Forum like to see? Either interested or just people with good ideas?
Autodesk people are allowed to contribute ideas, also!
Greg Pyros
I like the idea. I've actually thought of writing some such thing since I
now have a small lantastic network to test it on.
Great, Martin. Keep in touch with the group here and we'll see what
develops!
Ken
BTW, Martin, how about adding your wishlist of features here so we can
begin to gel a sense of what it needs to do.
Ken
Greg and I discussed doing this back in September and I've done some
thinking on it myself since then. I'll have to consolidate my thoughts and
put them in some meaningful form. Without going in to a lot of detail I
think the routine would create batchfiles with a unique name for each
station, bearing in mind each stations relative performance. The stations
would either be checking for the existence of a particular batch file on
the server's disk by means of a tsr or looping batch file; or, the stations
would be told somehow remotely to execute the batch statement. It would be
nice to do this all remotely via modem or at least from the server.
Martin / Ken:
The problem with "bearing in mind each station's relative performance" is
that it then requires you to do as much calculating as it does to just do it
manually, with no way to take into account faster/slower groups of frames,
and no way to compensate if a machine hangs.
To do this right, the program needs to monitor the file output and determine
the relative speed by itself, and would then distribute the frames
accordingly.
It's the old tradeoff of programming time (and $$) vs. usage time (and $$).
And yes, it would have to be capable of being done remotely by modem or why
bother?
Greg Pyros
I think the monitoring of frame output on the server by the program and
it's making adjustments would be too hard to implement – the onus for that
is still going to be on the person monitoring the server locally or by
modem. If a system hangs you would probably still need some kind of
operator intervention, IMHO.
I also think a station's performance is not going to vary relative to the
other machines, so long as it doesn't start paging to disk. Therefore, I
would propose creating a configuration file when the program is setup with
a relative performance index for each station. This could be gleaned by
doing a standard benchmark for each machine (100 for the fastest machine
and a percentage for the slower machines – 56, 89 etc.?), *not* each time
you do a rendering. Of course, if this were found to be inaccurate you
could edit the config file to make adjustments to a machine's index.
Just a few thoughts, ta ta!
Martin
Martin:
Naaaahhhhh! I have some ideas on how to do this rather easily!
If the controller machine can monitor the progress of individual frames,
(that's easy) and then feed the information back to the rendering stations,
if a single station hung, the controller would then simply give it's frames
to other stations and distribute the load!
I don't WANT to have to go into the office at 2:00am again! The only person
there would be you, anyway, trying to get the shadows right on the walls and
ceiling of the ballroom! <big g>
Greg
We'll see if it can be done if/when this project gets off the ground.
>> do the progress monitoring itself
Ya, as each frame is rendered a file on the server could be incremented. As
the next machine is ready to render, it would simply "check-out" ( #42 …
does anybody have #42!?) the next frame. Locally, maybe some majic can be
done with incrementing EnvirVar's like when rotoscoping.
Ang
Yup, that's it. I'm just trying to decide on a language for the control
program – a portable C would be nice for running on either SUNs or PCs,
but Visual Basic may be faster to program…
We're interested. I've seen this in some systems integration work before,
and it can be a great idea. Be forewarned that controlling the program
spec will be a headache. I'd suggest that at some point – after getting
far-ranging input on the forum, perhaps – a small group (2 or 3 MAX) hammer
out a detailed spec, get a price for the product as spec.'ed, and let
others either subscribe or not subscribe: all subscribers having equal
benefits.
Secondly, I'm curious as to how the program would interface with 3DS. But
I guess figuring that out is half the fun.
–Noah / CADP,Inc.
One of the amazing things about 3DS is how its "accessibility" encourages
dialogues like these. Real hands-on personal enhancement is now a reality
for the enduser. Pretty exciting, I think <g>. Thanks for your ideas.
Ken Loss-Cutler