Independent project implementing new renderers for BURP?


Advanced search

Message boards : General talk : Independent project implementing new renderers for BURP?

1 · 2 · Next
Author Message
PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3972 - Posted: 20 Aug 2006, 0:57:43 UTC

Maybe you see this interesting. It\'s just an idea. http://debian.povaddict.com.ar/pov/forum_thread.php?id=15#160

____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 3979 - Posted: 27 Aug 2006, 21:32:26 UTC
Last modified: 27 Aug 2006, 22:16:18 UTC

Very. And I remember we talked about this some 4-5 months ago too.
As I said back then I would very much like BURP to support POVray as a renderengine. However, I haven\'t got the time to do the coding work to build a set of patches for the POVray engine. If you are interested in making such a patch set and compiling the binaries for the major platforms out there it will be a simple matter for me to add the remaining stuff. Let me put it this way: it\'s a lot easier to \"glue\" a 3D renderer to BURP than it is to start all over and basicly build something like BURP again.

I don\'t think I ever actually listed the technical requirements for a renderer to be compatible with BURP? Well, here\'s the details in any case:

- The renderer MUST be opensource and have an open license allowing BURP to distribute a compiled patched version of it to the clients
- The patched version SHOULD support more than one platform (Windows, Linux, Unix, Mac, etc.)
- The patched code MUST generate a specific set of messages on stdout:


  • When started the renderer MUST output the string \"[-->] Booting...\\n\"
  • The renderer MUST send updates on the progress using the following syntax quite often:
    \"[-->] Progress:\\n\" concatenated with round(10000*fraction_done) concatenated with \"\\n\" concatenated with round(1000*CPUtime_spent) concatenated with \"\\n\"
    If it doesn\'t send these updates it will be considered \"crashed\" and will be shut down. A good guideline is to send an update at least every 10-20 secs.
  • When the renderer closes it MUST output the string \"[-->] Exit\\n\"
  • At any point in time after having sent \"booting\" and before sending \"exit\" the renderer may send text to be logged using \"[-->] Info:\\n\" concatenated with the string that should be logged concatenated with \"\\n\". This is nice for debugging...
  • The renderer MAY output any text at any time. If it is not one of the above text messages it will be considered \"garbage\" and discarded (or the wrapper may choose to log it anyways)


- The renderer MAY NEVER access files outside the BOINC toplevel project directory or the current application directory (and subdirs).
- The renderer MUST create none or one image file as output. The name of this image MUST be statically determined (ie. the same every time)
- The renderer MUST be able to take the framenumber (for the frame to be rendered) as input on the commandline. It MAY support additional commandline parameters (such as for rendering only part of a frame).
- The renderer SHOULD be deterministic (or at least have only very slight differences for the same frame)
- Additionally the render MUST respect the usual signals (SIGTERM, SIGSTP, SIGCONT) - but this is usually not an issue since mostly all programs do that by default.
- The set of input files MUST be the same for every frame in a particular animation. Ie. the files must contain all the information needed to generate all the frames in the animation one by one (and in random order).

If you can make POVray follow every one of these simple requirements then you wont even have to think about all the remaining stuff - since that is already part of the BURP framework. The BURP wrapper will then be able to launch and control your patched POVray; pure magic, eh?

Profile KSMarksPsych
Avatar
Send message
Joined: 12 Mar 06
Posts: 39
Credit: 1,002
RAC: 0
Message 3980 - Posted: 28 Aug 2006, 1:22:36 UTC

simple requirements????

lol
____________
Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3981 - Posted: 28 Aug 2006, 4:10:07 UTC - in response to Message 3979.
Last modified: 28 Aug 2006, 4:30:49 UTC

- The renderer MUST be opensource and have an open license allowing BURP to distribute a compiled patched version of it to the clients

I can\'t really tell about this. It\'s not GPL-compatible, they have their own license. Have a look at the distribution license and source modification license, you can probably get the details about what\'s allowed and what\'s not better than me.

- The patched version SHOULD support more than one platform (Windows, Linux, Unix, Mac, etc.)

Supports those 4. In fact, I think POV 1.0 ran on Amiga :)

- The patched code MUST generate a specific set of messages on stdout:

There is some sort of \'frontend\' code separated from the actual renderer, so that the GUI version can start and stop renders without starting process again, and looks like option parsing can be customized too. If progress can be shown in the GUI titlebar, then I guess there are callbacks. So I can use that for the progress report format you need.

POV-Ray parsing stage (and photon preprocessing) can be long on some scenes, and there no progress report. I guess I would just return 0%?

- The renderer MAY NEVER access files outside the BOINC toplevel project directory or the current application directory (and subdirs).

The POV-Ray scene language supports reading and writing files, usually to create files with POV syntax and then include it (to workaround the lack of an eval() :P). This can be dangerous since it can #fopen any file the OS would let it open. To avoid this, there is an I/O Restrictions system. It\'s also platform-dependant, so there is some kind of callbacks.

Also, the configuration (ini) file can have shellouts, which are commands to be run before/after each frame/scene. This is useful to automate some tasks, such as make it add the image files to a zip archive after they are rendered, encode an MPEG file after all frames finish, or generate input data using an external program. However, this is of course dangerous for distributed rendering (and if you render files from untrusted sources). I/O restrictions affects this as well, so it would be simple to do something like: int allow_shellout(char* command) { return false; }

Additionally, you could just make a server check on the ini files to see if those kind of options are being used.

- The renderer MUST create none or one image file as output. The name of this image MUST be statically determined (ie. the same every time)

The renderer creates a PNG/TGA/PPM file, while the image is being rendered. I think file is saved on each line. This would make it relatively easy to support checkpointing! Filename can be chosen, although it is appended the framenumber. scene42.png is the default for frame 42 of scene.pov, you can make it be output42.png.

- The renderer MUST be able to take the framenumber (for the frame to be rendered) as input on the commandline. It MAY support additional commandline parameters (such as for rendering only part of a frame).

Absolutely all options are given through either command line switches or an .ini file. With options I mean image size, output filename and image format, antialiasing quality, animation clock, frame count and subset (render from frame 2 to 5, can be same number), partial render (useful to render tiles), etc. None of these exists on the .pov file.

- The renderer SHOULD be deterministic (or at least have only very slight differences for the same frame)

That\'s a message for users who upload sessions :) \"Never use \'crand\' texture, or antialiasing jitter, since these are truly random features\".

- Additionally the render MUST respect the usual signals (SIGTERM, SIGSTP, SIGCONT) - but this is usually not an issue since mostly all programs do that by default.

Not a problem, I guess.

- The set of input files MUST be the same for every frame in a particular animation. Ie. the files must contain all the information needed to generate all the frames in the animation one by one (and in random order).

This is also something that would depend on the scene and not on the renderer. The renderer gives you the posibility of having #include concat(\"frame\", frame_number), use of such a feature would be scene author\'s \"fault\".

If you can make POVray follow every one of these simple requirements then you wont even have to think about all the remaining stuff - since that is already part of the BURP framework. The BURP wrapper will then be able to launch and control your patched POVray; pure magic, eh?


I successfully compiled POV-Ray under Windows using MinGW, command-line renderer only (default binaries have a GUI with an integrated editor on Windows, X and SVGAlib display on Linux, and an even more complete GUI for Mac). I haven\'t modified anything on the code yet (other than the COMPILED_BY macro). I just looked around for interesting things, since the code documentation on some places is void and null...

Anyway, having my own project is still fun :) Even though sometimes I get 10 users uploading files at the same time, on my 256kbps bandwidth...

____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 3982 - Posted: 28 Aug 2006, 16:39:40 UTC - in response to Message 3981.
Last modified: 28 Aug 2006, 16:43:18 UTC

simple requirements????

lol

Yes, simple =)

- The renderer MUST be opensource and have an open license allowing BURP to distribute a compiled patched version of it to the clients

I can\'t really tell about this. It\'s not GPL-compatible, they have their own license. Have a look at the distribution license and source modification license, you can probably get the details about what\'s allowed and what\'s not better than me.

Hm... seems that this isn\'t particularly good:
3.4. Except as explicitly set out in this agreement, nothing in this
agreement permits Distributor to make any modification to any part
of the Software.

Basicly the distribution terms limit POVray to be distributed with Linux/Unix distributions... However the source terms state:
2.3. It is the intent of POV to permit modifications to the Licensed Version
which are Custom Versions within the meaning of clause 2.2 and which
incorporate a means of being controlled by other software where that
other software has as its express primary purpose the ability to
control or co-ordinate POV-Ray (or other programs in general) remotely
for parallel or network rendering purposes.

In other words they seem to have been cought up in some internal licensing issues that, for some reason, they cannot get out of. It appears they would LIKE to specifically allow distributed rendering modifications. And they would LIKE to allow you to distribute binaries of those changes. You\'ll probably have to send them an email to make sure, though.

- The patched code MUST generate a specific set of messages on stdout:

There is some sort of \'frontend\' code separated from the actual renderer, so that the GUI version can start and stop renders without starting process again, and looks like option parsing can be customized too. If progress can be shown in the GUI titlebar, then I guess there are callbacks. So I can use that for the progress report format you need.

POV-Ray parsing stage (and photon preprocessing) can be long on some scenes, and there no progress report. I guess I would just return 0%?

Yes, I think I\'ll change the current wrapper to allow renderers to take exceptionally long to \"render\" the first 0.1%. This issue is relevant for all renderers and not just POVray.

- The renderer MUST create none or one image file as output. The name of this image MUST be statically determined (ie. the same every time)

The renderer creates a PNG/TGA/PPM file, while the image is being rendered. I think file is saved on each line. This would make it relatively easy to support checkpointing! Filename can be chosen, although it is appended the framenumber. scene42.png is the default for frame 42 of scene.pov, you can make it be output42.png.

out.png (for any frame) would do the trick quite nicely - that\'s what is used for the Blender renderer so far.

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3983 - Posted: 28 Aug 2006, 21:59:27 UTC - in response to Message 3982.
Last modified: 28 Aug 2006, 22:09:31 UTC


In other words they seem to have been cought up in some internal licensing issues that, for some reason, they cannot get out of.


Quoting the actual license:
As people contributed code to POV-Ray over the years - and there have been many instances of this - they contributed it to us on the understanding that it would be covered by the POV-Ray license, as it stood at the time. Now, in 2001, we find that in many cases we don\'t know who wrote what part of the code, or that the author is uncontactable. We simply don\'t have the right to arbitrarily change the terms under which their source code is distributed. Even though it was contributed to us, we feel that we must honor the terms under which it was given. Therefore, POV-Ray will remain on this existing license until we do a full re-write (which is intended for v4), at which time a new license will be instituted that is far more liberal in terms of reuse.


POV-Ray parsing stage (and photon preprocessing) can be long on some scenes, and there no progress report. I guess I would just return 0%?

Yes, I think I\'ll change the current wrapper to allow renderers to take exceptionally long to \"render\" the first 0.1%. This issue is relevant for all renderers and not just POVray.

Great. POV-Ray language is a real scripting language now. There are scenes that take hours to parse and minutes to render :) I have seen particle systems made in POV-Ray scene description language.


The renderer creates a PNG/TGA/PPM file, while the image is being rendered. I think file is saved on each line. This would make it relatively easy to support checkpointing! Filename can be chosen, although it is appended the framenumber. scene42.png is the default for frame 42 of scene.pov, you can make it be output42.png.

out.png (for any frame) would do the trick quite nicely - that\'s what is used for the Blender renderer so far.

I don\'t think I take out the frame number from the filename without modifying the code, but the filename is at least completely predictable. You could just rename it after rendering.

Progress report: I added the Booting and Exit messages to main(), but then I found this isn\'t really the correct way to do it. I\'m now making a BoincRenderFrontend class based on the Default one and some from the Windows one (all derive from RenderFrontend, which in turn is derived from others... owh, this is messy)

By the way, POV-Ray doesn\'t give CPU time used, so I would have to code it myself, using different code for the various platforms. BOINC sample application \'wrapper\' does this, I might borrow the code from there xD


____________

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3984 - Posted: 28 Aug 2006, 23:56:33 UTC
Last modified: 28 Aug 2006, 23:58:14 UTC

Believe it or now, I\'m done :) Code can be said to be more a hack than a clean patch, though.

To remove the progress messages POV-Ray gives on its own, I\'m just doing strstr(buffer,\"Rendering\") to filter out the \"0:00:05 Rendering line 10 of 480 (100 supersamples)\". I had to remove them, no \\n\'s on them so it made a mess with the \"[-->] Progress:\" messages. No, I can\'t check for \"Rendering line\", message is printed in sections using separate function calls. There is probably a cleaner way to filter those out.

No CPU time is reported yet.

I can make an unified patch of my changes. It\'s based on the source archive for Windows, but I have only touched the crossplatform code, so any should work. However, it has a new C++ file, so it needs a makefile change (which is platform specific). I have the Windows executable for it, compiled with MinGW.

Note that you would probably need to include all the standard .inc files as part of the application, since most if not all scenes use at least colors.inc for convenience (it\'s completely possible to make a scene without any of them though).

I did a quite simple animation of a bumpy glass-like sphere rolling on the floor, doesn\'t use any include file, you may use it for the tests.


____________

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3985 - Posted: 29 Aug 2006, 2:17:38 UTC - in response to Message 3984.

Believe it or now, I\'m done :)

I mean \"or not\" (doesn\'t let me edit post anymore).

Unified diff of changed files, and added files. Based on POV-Ray for Windows code. I still haven\'t tested applying the patch on Unix code.
____________

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3986 - Posted: 29 Aug 2006, 3:47:27 UTC

Tested on Unix... the build system is so different that I had to change more things. Plus, there is a povproto.h I\'m including but doesn\'t exist on the Unix archive. I think it was removed. Windows source isn\'t updated to 3.6.1 I think...
____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 3988 - Posted: 29 Aug 2006, 7:11:59 UTC - in response to Message 3983.
Last modified: 29 Aug 2006, 7:20:25 UTC

By the way, POV-Ray doesn\'t give CPU time used, so I would have to code it myself, using different code for the various platforms. BOINC sample application \'wrapper\' does this, I might borrow the code from there xD

You may skip this part for now since the new release of the BURP wrapper will automatically take care of this (like it is done in the official BOINC wrapper).

The most important thing is that it produces the progress messages, start and stop messages and that it doesn\'t access files outside its allowed scope.

Btw I can\'t seem to get your compiled binary for Windows to output PNG images (which would be the preffered format). I\'m using the -FN16 commandline option. Am I doing something wrong?

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3990 - Posted: 29 Aug 2006, 15:09:52 UTC - in response to Message 3988.
Last modified: 29 Aug 2006, 15:10:06 UTC

Btw I can\'t seem to get your compiled binary for Windows to output PNG images (which would be the preffered format). I\'m using the -FN16 commandline option. Am I doing something wrong?

Try +fn. General guideline on POV switches: - disables, + enables. For switches like image size, both do the same.
____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 3992 - Posted: 31 Aug 2006, 9:17:20 UTC - in response to Message 3990.

Try +fn. General guideline on POV switches: - disables, + enables. For switches like image size, both do the same.

Ah, that seemed to do the trick.

However it fails the -->Exit requirement it seems, I saw -->Booting, -->Info and -->Progress messages, though.
You may wish to include a \"\\n\" before the info messages to make sure it starts on a new line - otherwise there\'s no guarantee that it will be parsed correctly.

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 3993 - Posted: 31 Aug 2006, 16:35:18 UTC - in response to Message 3992.

However it fails the -->Exit requirement it seems, I saw -->Booting, -->Info and -->Progress messages, though.
You may wish to include a \"\\n\" before the info messages to make sure it starts on a new line - otherwise there\'s no guarantee that it will be parsed correctly.

Oops, it says -->Exit when the render finishes, but not if there is an error. I will have a look at this.
____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 4008 - Posted: 3 Sep 2006, 9:10:25 UTC
Last modified: 3 Sep 2006, 10:12:35 UTC

I\'ve started to add the few remaining pieces of code to be able to support multiple renderers. Basicly this includes som file detection code and other upload related stuff.

POV seems to fit in nicely with pretty much everything here - it even supports the multipart rendering settings with a commandline like the following (where the proper parameters (#) are of course plugged in by the server):

povray_burp +KFI#frame_number +KFF#frame_number +SC#x_fraction_start +EC#x_fraction_stop +SR#y_fraction_start +ER#y_fraction_stop +FN16 +Oout.png +Q9 +W#x_size +H#y_size +Linclude +I in.pov

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 4012 - Posted: 3 Sep 2006, 18:37:16 UTC - in response to Message 4008.
Last modified: 3 Sep 2006, 19:29:22 UTC

I\'ve started to add the few remaining pieces of code to be able to support multiple renderers. Basicly this includes som file detection code and other upload related stuff.

POV seems to fit in nicely with pretty much everything here - it even supports the multipart rendering settings with a commandline like the following (where the proper parameters (#) are of course plugged in by the server):
povray_burp +KFI#frame_number +KFF#frame_number +SC#x_fraction_start +EC#x_fraction_stop +SR#y_fraction_start +ER#y_fraction_stop +FN16 +Oout.png +Q9 +W#x_size +H#y_size +Linclude +I in.pov


Just to let you know, partial rendering makes PNGs that programs have trouble to open. There are alternatives though. I\'m currently rendering an image using 100 tiles, using zoomin.inc, so I get 100 completely normal 160x120px PNGs :) Works only with perspective camera though.

By the way, if you want to render a single frame of an animation, for example a total of 100 frames, render only frame number 42:
+kff100 +sf42 +ef42 +oout.png

Note that this will save the image as out42.png.

EDIT: I tried to edit this message and it took like 5 minutes. Then whole BURP website wasn\'t working for me. And now I see my edit isn\'t here...
____________

Profile Steve Cressman
Avatar
Send message
Joined: 27 Mar 05
Posts: 142
Credit: 3,243
RAC: 0
Message 4022 - Posted: 5 Sep 2006, 4:03:09 UTC

EDIT: I tried to edit this message and it took like 5 minutes. Then whole BURP website wasn\'t working for me. And now I see my edit isn\'t here...


That is why when I do a long post I Ctrl+A then Ctrl+C just incase there are problems. I too hate to retype something that took a while to type. Those couple of key presses only take a second to store what you have typed into the clipboard.

Steve
____________
Win98SE XP2500+ Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

PovAddict
Avatar
Send message
Joined: 25 Apr 05
Posts: 347
Credit: 4,618
RAC: 0
Message 4023 - Posted: 5 Sep 2006, 4:05:58 UTC - in response to Message 4022.

EDIT: I tried to edit this message and it took like 5 minutes. Then whole BURP website wasn\'t working for me. And now I see my edit isn\'t here...


That is why when I do a long post I Ctrl+A then Ctrl+C just incase there are problems. I too hate to retype something that took a while to type. Those couple of key presses only take a second to store what you have typed into the clipboard.

Steve

Yeah, a good idea. But what I meant with \"took 5 minutes\" is since I pressed OK until the page finally loaded with the post...
____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 4025 - Posted: 5 Sep 2006, 6:47:33 UTC

Well the site was offline for a few moments at about that time due to a CPU cooler malfunction. It was offline for more than 5 mins, though. Probably something like 10 mins.

animate1978
Send message
Joined: 18 Sep 05
Posts: 2
Credit: 0
RAC: 0
Message 10621 - Posted: 29 Oct 2010, 21:02:15 UTC

Just stumbled on this thread.

So take for instance Aqsis - http://www.aqsis.org

Could in a sense work correct? The reason I am asking is because earlier today I ran across this story about Windows Azure cloud computing : http://thenextweb.com/microsoft/2010/10/28/microsoft-and-pixar-team-up-to-bring-renderman-on-azure/

So this got me thinking about the short film project I have been working with. Currently the ONLY real option we have to render this 5 minute short is to use a private renderfarm owned by an acquaintance however this isn't working out too well since right now we could use the farm to test render the lighting and shading stages, since rendering at HD tends to be a bit slow and working with 1000 frames for just one shot just takes too damn long to render even basic shading. Problem is that the farm is still up in the air, me and this guy just cant seem to secure a date so that I can log in and setup the whole thing myself, an irritation and has me looking elsewhere for options. I have looked at SunGrid, Google and Amazon, of course Azure as well but the price is an issue, something if needed I could afford, would rather not though since already investing a good amount of paychecks into utility and internet bills.

Having the rest of the pipeline setup has been a task but am willing to take on new challenges so I again looked at BURP. This patch idea is a good one, after all Aqsis is available for all popular OS's (Win, Linux and Mac) plus is open source, under very active development and I have close ties to the devs, they are very much involved with this short film providing new features, bug fixes and so on because of what we are trying to accomplish. This could work, however the technical and programming side of things is not my forte', I am more of a technical director with skill in Renderman lighting and shading but not skilled in programming myself (though I can relatively follow it to a degree).

Would such a thing be turned down? After all it could be a benefit to all involved, this would be a new renderer that can join the BURP and Renderfarm.fi network, the object is collaboration right? I believe this could work. Just wondering how many people would be interested in this? Renderman (in my experience) has been subject of criticism in the Blender community, some people are very interested and well some are not so thrilled, either way it's not about the size of the muscle - it's about what the muscle can do, that's all.

I for one would help in any way I can. Any thoughts????
____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4469
Credit: 2,094,806
RAC: 0
Message 10622 - Posted: 30 Oct 2010, 15:01:46 UTC - in response to Message 3979.
Last modified: 30 Oct 2010, 15:10:55 UTC

I see no reason why Aqsis shouldn't be able to work with BURP. The only problem is to find someone who knows how to make a patch for it so that it will act nicely when distributed to BURP clients.
What kind of timeframe do you have on your project? Adding a new renderer could very easily prove quite a lot more challenging than it sounds.

Since this thread was originally made BURP has been changed a lot. Most of the requirements still hold and some have changed a bit. I'll just reiterate for clarity:

- Opensource is still required
- It should only access files inside the "sandbox" of the current directory and subdirectories
- The protocol has changed slightly but the overall idea is still the same
- PNG support is required, OpenEXR and Radiance support is on its way

- The renderer MUST be able to take the framenumber (for the frame to be rendered) as input on the commandline. It MAY support additional commandline parameters (such as for rendering only part of a frame).

Renderers can now use per-frame files and the requirement that they have a framenumber (or even that the renderer knows that a frame is part of a greater whole) has been lifted.

- The set of input files MUST be the same for every frame in a particular animation. Ie. the files must contain all the information needed to generate all the frames in the animation one by one (and in random order).

As above, this requirement has been lifted slightly. It is now possible to have zero or more files that are the same for all frames and an additional zero or more files which are specific to each frame.
Sending the whole scene for every frame is a bad idea, though - keep in mind that things need to go over the web. I've been looking into supporting RIB-style (or XML-style) input files by using a master file + a diff for each frame.

On a side note: Check out LuxRender, this looks like an interesting renderer as well.

1 · 2 · Next
Post to thread

Message boards : General talk : Independent project implementing new renderers for BURP?