The RANCH supports Terragen 2 and 3!

[RenderFred]

Hi everyone,

I am glad to announce that the RANCH will be soon (when Terragen 2.4 is released) offering a high performance rendering service for Terragen users. For those not familiar with the concept, it is quite simple: you upload your Terragen project, and we render it for you, much faster than you can do on any single system. Our prices are the best you can find among big rendering facilities, and we will do our best to provide a great service for Terragen, as we do for all software we support.

We have been working for months now with the Planetside team to adapt Terragen 2.4 to our pipeline (we develop all our software ourselves) and I believe you will be impressed with the results. I will be happy to answer all your questions in this sticky thread but first, I recommend you read our PDF manuals, that is the RANCH General Guide and our Terragen-specific Guide. Most questions you can have will find their answers in them.

As you probably know, the Garden animation was rendered on the RANCH, but I have also spent a lot of time to ensure that we could also render still images with a very good performance. The introduction of the GI cache functions in 2.4 was essential, as it lets all the render nodes use the same GI solution, thus avoid typical lighting problems associated with GI on a network.

If you have used other rendering facilities before, you will find that the RANCH works differently than most. There is no time sharing on the RANCH, all the power is put to good use on every project. So the performance is the same, every time. For instance each Terragen still image is rendered on a grid of 176 nodes (currently up to 80 megapixels stills).

I hope that our service will give a new dimension to your projects and help Terragen gain new markets (particularly in animation)! 

Cheers,

Fred

UPDATE: the RANCH is now supporting both Terragen 2.x and 3.x

[FrankB]

That sounds very good, Fred (is this your name?).

Do you have any info on still render pricing yet?

Regards,
Frank

[RenderFred]

Hi Frank,

Pricing will be the same as for the other software we support (from 2.5 to 5.9 €-cent per GHz-Hour + discounts for quantities). And yes my first name is Frederic  

[FrankB]

Thanks Frederic. Can you help with an example? Let's say an image takes 10 hours to render on my i7 920, how fast would it be on your farm and how much would I pay?

Thanks,
Frank

[RenderFred]

Thanks Frederic. Can you help with an example? Let's say an image takes 10 hours to render on my i7 920, how fast would it be on your farm and how much would I pay?

Thanks,
Frank

It's a question that a lot of people may have, so I will give a detailed answer here. For animations, computing an estimation of cost and render time is relatively easy if you know the number of frames and the average render time per frame on your system. For still images, it's not possible to do so because it depends on the repartition of the complexity in the scene, and this varies with each scene. On the RANCH a still image will be split into many regions (176, so one region per RANCH Runner node). So lets' take an example.

Imagine that your image is 4000 x 3000. It means that each node of the RANCH Runner will compute a region of approximately 364 x 188 pixels (4000/11 x 3000/16 as the grid is 11 x 16 = 176). Now let's consider the best case scenario: the image is completely homogeneous, that is, all the regions take the same time to render, let's say 10 minutes: in that case the RANCH will take 10 minutes to render all the regions. So the total processing time will be 10 minutes + the time needed to recombine all the regions into the final image (which can take 1 to 5 minutes). Let's say 15 minutes for the entire project, that would be around 33 euros with the Sapphire formula.

Of course the "completely homogeneous" case is hypothetical; there are always regions which take longer to render than others. In that case the total render time will be the render time of the longest region. In a worst case scenario imagine that the longest region takes 2 hours to render: then the total render time will be 2 hours, and that would be around 265 euros with the Sapphire formula. So it really depends on how complexity is distributed in your scene, and we have no way to know that beforehand. We could subdivide into more regions of smaller size, but in that case it would be even more difficult to predict. With more than 176 regions, each node would have to compute several regions, and for each the populator time would have to be added (and that can add a significant overhead, independant of the definition, on complex scenes). With 176 regions we know that it is done in one pass, and the preparation/populator time has to be done only once per node.

To give you an idea of a typical project, during our tests, a 12000 x 6750 image of the St Helens scene which takes 145 hours on a Core i7-920 and almost 73 hours on a Core i7-2600K overclocked to 4.6 GHz has been rendered in 53 minutes on the RANCH Runner. A 8000 x 4500 version of the same image is done in 30 minutes. As a general rule performance will always be better in animation than on still images (on the Garden scene the RANCH Runner was 250 to 300 times faster than a Core i7-920 

[FrankB]

Thank you for the comprehensive explanation, Frederic. That was very interesting, and I understand the cost model much better not

I still have trouble to understand the GHz-hour, though, as a measure for forecasting the cost.

So what I understand is that when the ranch is used for 15 minutes, it approximately achieves so much and costs x Euro for that time. In your example, the 4000px render would cost 2.2 Euro per minute, and it is capable of finishing the job in 15 minutes. (I understand that this will vary depending on the scene and that the example is based on the assumption of a homogenous scene with all crops rendering at the same speed).

Do you actually charge the idle nodes? Let's say there is this one bucket that's taking forever, while all other buckets on the other nodes have already finished rendering?

Cheers,
Frank

[RenderFred]

Do you actually charge the idle nodes? Let's say there is this one bucket that's taking forever, while all other buckets on the other nodes have already finished rendering?

Cheers,
Frank

Yes but they are not idle, as soon as a node has finished its job it works on another region which has not yet been rendered. That way, if a node crashes for whatever reason the render will still finish as another node will have done the job in its place. It's a necessary safety mechanism which guarantees that the render will finish and not be stuck forever in case of a problem.

[Kadri]

Congrats Frederic! Looks like it could be affordable in very long stills too probably.

'File / Export Gathered Project...' this will come handy to me. I sometimes loose the amount and whereabout of used files . Good for archiving

The cache settings will hopefully bring an end to some long standing animation and panorama user feature requests and it looks like from the image in the pdf above for stills like this too (i hope) :
http://forums.planetside.co.uk/index.php?topic=14225.0

Where is the link  for 2.4  , Planetside ?  

Edit: Frederic i read the other pdf. Obviously TG2 isn't there yet. But the "rendering time limit per project" looks like could be a problem especially for high res  animations made with TG2. Will you change it for Tg2?

[RenderFred]

Edit: Frederic i read the other pdf. Obviously TG2 isn't there yet. But the "rendering time limit per project" looks like could be a problem especially for high res  animations made with TG2. Will you change it for Tg2?

No I don't think we will change it. As all the power is dedicated to each project (no sharing on the RANCH) 3 hours on the RANCH Runner is equivalent to weeks of rendering on a single machine. If the project is really too long then it should be easy to split it into several projects (we did this for the Garden animation). And for frames longer than 3 hours each then there is the Elite formula which has a 6 hours time limit. We sincerely hope that HD frames which take more than 3 hours each on a Dual Xeon node are an exception  rather than the norm with TG2

[Kadri]

Thanks 

[rcallicotte]

Hey, this sounds cool.

[coremelt]

Hi Frank,

Pricing will be the same as for the other software we support (from 2.5 to 5.9 €-cent per GHz-Hour + discounts for quantities). And yes my first name is Frederic  

ok but help me out here, is it Ghz hour per core or per physical CPU? Lets say I have a render that takes 20 hours for 200 frames on a 6 core i980 i7 3.3 Ghz.  How much do I pay at the ranch and how long will it take?

[RenderFred]

Hi Frank,

Pricing will be the same as for the other software we support (from 2.5 to 5.9 €-cent per GHz-Hour + discounts for quantities). And yes my first name is Frederic  

ok but help me out here, is it Ghz hour per core or per physical CPU? Lets say I have a render that takes 20 hours for 200 frames on a 6 core i980 i7 3.3 Ghz.  How much do I pay at the ranch and how long will it take?

It is GHz per physical core (we do not charge for hyperthreading like some renderfarms do to artificially rise their prices). So for us, a Dual Xeon E5645 is a 12-core node (even though it is a 24-thread system). We will have an online cost estimator for animations which will tell you that the animation you give as an example (6 minutes per frame on average on a Core i7-980) should be done in around 10 minutes on the RANCH (if your scene use 100% cpu on a Dual Xeon system while rendering). So it is around 20 to 50 euros depending on the priority level you choose.

[coremelt]

ok wow, at those prices you'll be hearing from me sometime next week
I've got the TG 2.4 beta and the project is already setup with that.

[rcallicotte]

coremelt, please let us know the details, if you do this.  We're eagerly awaiting 2.4.

ok wow, at those prices you'll be hearing from me sometime next week
I've got the TG 2.4 beta and the project is already setup with that.