/3/ - 3DCG

Not all rendering engines are built the same. They all operate under a different algorithm which produces different results.

>How can there be good or bad renderers?
this is 4chan, aka pleb central. people will argue about anything vs anything else. /g/ is still arguing about which operating system is best. /mu/ aruging which music is best.. etc.

the answer is the same. there is no best or worst renderer. there are good renderers for certain cases and there are renderers with more features than others it's hard to just slap the label "better" onto any one of them.

that said, i don't know why you think renderers should produce the same results because each one tries to solve the rendering problem using their own methods and shaders and global illumination.. etc. you can produce similar results on different renderers but you're gonna have to set them up differently.
real-time renderers are a totally different ball game and we can argue to eternity about unreal vs unity vs marmoset vs id tech5

>>464724
>there is no best or worst renderer.

there is a best renderer - vray 3.0. There is also a worst - cycles.

>>464727
>cycles
>not blender internal

>>464729
blender internal is fast and production proven. Cycle is not.

>>464727

>vray 3.0

what is Arnold?

>>464734
arnold a shit

>>464727
Perfect example right here.

>>464727
I use V-Ray 3.0 too, but come on dude. There is no best renderer. If there is, I think the title should go to something that has been proven in production to great extent, like RenderMan.

>>464747
There sure is. Renderman is crap, only as good as the scripts and DSOs your shader monkeys give you. With V-ray 3.0 its astounding quality out of the box, no b.s. required, and just download a crack from cgp. Just get 8 nodes of overclocked 4790k's and some quality ddr3 and you're in business for real, no gpu bullshit, no nothing else.

>>464724
>that said, i don't know why you think renderers should produce the same results because each one tries to solve the rendering problem using their own methods and shaders and global illumination.. etc.

OP here. Thanks for that answer!

Let me make my initial question more clear. I understand the "job" of a renderer this way: I am giving the description of an object to it, and I ask it what that thing would loook like from angle A with lightning B.

To me, that seems like a question that has a "correct" answer. If that's the case, how could multiple renderers end up delivering different results?

Theoretically, I think one should be able to solve the question ("how does it look?") with a calculator, one dot at a time. And each tiny dot would have a "correct" value. But somehow that seems to be wrong, and I don't know why.

>>464799

You should've stopped at this post >>464675

Basically, all render engines try to solve the rendering equation.

http://en.wikipedia.org/wiki/Rendering_equation

There are different approaches to solving this equation, which give different results. Also, there are some aspects that are missing from the rendering equation, such as subsurface scattering. Rendering engines solve these issues in different ways, again giving different results.

Basically, try to see it as a group of painters all trying to paint the same scene. They all try to copy it as precisely as possible, but they all have their own techniques to come to the final result.

To answer your original question:

What makes a good renderer? Skipping things as speed and usability, a good renderer solves the rendering equation giving the most physically accurate results while integrating all the possible exceptions as good as possible.

People like to argue which renderer is best, but people judge on different criteria, which makes it impossible to come to any kind of agreement. There are always particular strengths and weaknesses, so it makes sense to pick the renderer which is best for what you want to achieve, or pick a good all-rounder.

I'd like to add that even all of the different algorithms should produce the same result (at least if we only speak about unbiased ones); the differences are in material models or dropping or handling different parts of the RE. If you pick the same exact material models and other parameters, different renderers should indeed produce identical results.

It could obviously be argued that you don't have to be unbiased and then it can be a matter of taste. As is the usability of the given software.

>>464807

>>464812
>If you pick the same exact material models and other parameters, different renderers should indeed produce identical results.

OP here. Thanks again!

The last few lines were very helpful, at least I think they were. I take it that the models are NOT exact/complete descriptions of the object that will be rendered? The artist gives an incomplete description and leaves it to the engine to fill out the gaps? Is that true?

Like just saying "That wall should look like marble" but not explicitly stating how marble looks (very abstract example). That way it would be clear why the results are different. Is it like that?

>>464910
Yes, very much -- there is quite a large body of different material models. There are also more global parameters, how many bounces of light and how light is treated in the first place (which is usually determined by the algorithm used and is thus fixed).

I come from a graphics programming background though, I know some of the theory but not much about the actual software..

>>464727
you're stupid.

>>464969
>not giving raisins

>>464727
>not knowing about blender internal

>>465005
>thinks BI is worse than cycles b/c its not raytrace-based

learn 3d

>>465005
>>465006
Thinking that either of those are anywhere near as good as V-Ray.

>>465011
>thinking anyone was referring to high end
Blind as fuck keyboard warrior

>>465018
>not going for the best results always

>>464969
>>464970
>>465005
>>465006
>>465011
>>465018
>>465028

Hey kids, go out play in the mud, this discussion is over.