> "MattM" <mat### [at] hotmailcom> wrote:
>> You're right actually, I don't want to compromise on this, I'd like as much
>> detail as people want to put in.
>>
>> So to overcome that we'll have to render many images and stitch them
>> together. That way we can circumvent the limits on memory etc (with careful
>> thought there shouldn't be many artifacts visible with shadows of objects
>> overlapping others as each object will have a fairly small discrete area
>> within the image.
>>
>> As a scale the final object should fit nicely into a <0,0,0> <1,1,1> box.
>> Must use #local not #declare (unless you've really come up with a good
>> uniquename) to avoid name clashes.
>>
>> So fitting in the box and in the #include requirement (I mentioned
>> earlier)should make a pretty straightforward guideline.
> 
> Maybe MegaPOV XRS would be a viable rendering solution for this?
> 
> 

I have a better rendering system, it's currently quite messy (lots of 
manual stuff needed to get a scene going!) but if I get time and 
motivation (and this project seems to give me the latter) I could work 
on automating it more.

Tile rendering and animations are both supported (including combining 
both; that is splitting each frame in tiles). Resuming a render is 
supported (you *don't* want to know the hacks I had to use on POV-Ray 
code to get that working; I can't wait for POV 3.7 which uses a state file).

Currently hosted by IMP, and with few users (but one of them has a few 
8-core machines): http://impfarm.imp.org/boinc/

Post a reply to this message