Queries about rendering services.

[earlye]

I thought I would answer an honest rendering service question from a separate thread that is rather flame-laden at the moment and at the same time start a discussion about rendering services in general. Hopefully this one can stay flame-free and technically-oriented.

Please note that I am pointedly avoiding making this a ResPower-specific thread, although I can obviously only field questions related to ResPower or make comments based upon my competitors’ websites. Competitors, feel free to join in, but for the good of the community, let’s please try not to make this into a marketing battle - i.e., let’s try to keep it to answering other posters’ questions and on a wholly technical level.

@toontje

Hey Early, is it possible for the Respower renderfarm to bake a fluid or softbody simulation? Or is it just pure rendering?

It’s pure rendering at the moment.

@toontje

What are the gains in respect to AO, radiosity, scanline and raytracing?

The primary gain is that as long as your frames finish in the alotted time frame based on your subscription level (15,30,or 60 minutes), you can do a lot more frames in the same amount of time. What we do is give each computer one frame. Since there are so many computers all crunching at one time, they all finish that much faster. So if your frames finish in 15 minutes a piece, you can do roughly 700 frames in 15 minutes. Which algorithm you use (AO/radiosity/etc…) is essentially irrelevant once you optimize your scene to fit in the subscription level limits.

@toontje

Am I asking questions that are answered already on your website?

Nope. But we may incorporate them soon, time allowing.

@toontje

But seriously, I want to know this things, because escpacially fluid baking stuff makes it really worthwhile to subscribe to Respower.

We’ll definitely have to focus on doing something about this. Unfortunately, fluid sims are notoriously hard to parallelize, since the initial state of each frame is the ending state of the prior frame. However, there are ways to speed up individual frames’ baking - we’ll try to schedule some time to look into it when we work on making it where you can even render an already-baked fluid.

– Early Ehlinger, President, ResPower, Inc.

[LetterRip]

Unfortunately, fluid sims are notoriously hard to parallelize, since the initial state of each frame is the ending state of the prior frame.

I emailed this to Nils,

might be of interest to you also,

“Robust Grid-based environment for large scale lattice-Boltzmann simulations”
http://www.allhands.org.uk/2005/proceedings/papers/465.pdf

and

“Lattice Boltzmann Simulation of Fluid Flow under Grid Computing Environment”
http://www.cs.uiowa.edu/~jni/projects/lbm/grantProposal.html

Basically the algorithm chosen by Nils is well suited to parallell processing for fluid sims.

LetterRip

[earlye]

@LetterRip

Unfortunately, fluid sims are notoriously hard to parallelize, since the initial state of each frame is the ending state of the prior frame.

Basically the algorithm chosen by Nils is well suited to parallell processing for fluid sims.

Indeed, but still only on an intra-frame basis. I.e., one can only proceed to the next frame once one knows the results of the previous frame. The LBM algorithm has the nice effect of only needing to know the results for the nearest neighbors, and only needing to produce results for nearest neighbors, rather than having to produce an entire frame before proceeding, but there is still a lot of interdependency there that makes the problem somewhat less than trivial.

@earlye edited this and

I.e., even if an individual cell in the latice can proceed, it can’t get too far ahead, because it will have to wait for its neighbors at some point.

– Early Ehlinger, President, ResPower, Inc.