Blender's Cycles vs. Eevee (Ray Tracing vs. Real Time)

[Music] easy vs. cycles how are they different which one's better there's still a lot of questions up in the air about avian cycles and I'm going to answer some of those today hey guys how's it going my name is grant and I'm the host of Remington graphics and today we're taking a look at the differences between Eevee and cycles and how they have different uses in the computer graphics world we'll be taking an in-depth look at each individual factor to help you guys recognize the advantages and limitations of each engine so let's go ahead and hop right in when it comes down to it comparing avian cycles is more or less just comparing real time engines in general and rate racing engines in general so let's take a look at those two by definition rate racing is a technique for generating an image by tracing the path of light as pixels in an image plane and simulating the effects of its encounters with virtual objects now that definition is a little bit of a mouthful and a little bit hard to comprehend so I decided to throw together a particle system within blender to show you exactly what a ray tracing engine does in this case we're actually looking specifically at the way cycles those ray tracing so there's only a few things going on in this scene you can see we have a camera over here a light a big boundary which is the cameras farthest viewpoint ground plane a sphere for the light to bounce off of and we also have this little catching light catching plane back here which is more of just for visualization doesn't actually exist so this is what happens if we actually run the simulation you'll see it's really quick and something happens but it's not really anything that's because it's going so insanely fast this is actually what happens every single time your computer takes a sample so let's go ahead and slow it down so we can actually visualize what is happening in the computation process so now you can see that the particles are moving significantly slower and this allows us to see every single light bounce that they take so you can see they bounce off of the sphere off of the ground plane and when they hit the world boundary I guess it kind of disappears except for the ones that hit the light which go through onto our image catching planes this is more or less how cycles works it emits a bunch of light particles from the camera they bounce off of everything until they either disappear to existence which is the cameras view boundary or they hit a light in which case they are recorded as data and that's what you see when you render now that being said this is a very simplified model there is a lot more going on behind the scenes of cycles but this is a good start just to give you a little bit of an idea of exactly what happens so that's how cycles works but what about Evie obviously they can't go through the whole rate racing process every time a frame recalculates because that would take way too long so how do they do it the method is actually relatively simple however it's a lot harder for us to comprehend because when you're working with a rate racing engine it seems like something in the physical world whereas real time engines use mostly math in geometry which is a little bit harder for at least me to visualize but I'll do my best to explain it to you regardless the whole process starts with calculating and recognizing vertex data the CPU finds each coordinate of each vertex in the entire scene and then hand it off to the GPU for the next few steps the next step is vertex processing the GPU takes the data given to it by the CPU processes it analyzes it and if it makes sense it creates a point in 3d space and that becomes your vertex then it does a few quick calculations to see where a face or a line could possibly exist given the data it had received from the CPU and if everything seems like it's in shape then it goes ahead and actually draws the faces and lines and individual vertices if those are present in the model this step is called rasterization and it also goes through a few other steps in this process as well including multi sampling and anti-aliasing to improve the quality of the image coming out of your rendered then it goes through a step called the fragment processing where it takes things like textures alpha depth and lighting into consideration to make a color or I guess multiple colors for your face so it looks more realistic if that applies this data to the rasterized image from before and kicks out the data as pixels on your monitor so that does the two different engines work but what is the difference between them what pros and cons they each have let's take a look at that now in general ray tracing engines usually provide more photorealistic renders than you would get with the real-time engine this is because they take a lot less shortcuts and use a physically-based model to calculate what is what in addition they often support more features than real-time engines do as well especially in the case of cycles now Eevee is still under development so there are things that may change but as of right now Eevee doesn't support hair but lots of different parts of particle system you can't make fancier materials and stuff like that there's just a lot missing for most real time engines that rate to rate the engine tab and this ties in directly with the diversity and customizability of the engine because if you're missing features obviously you can't do as much with it ray tracing engines also support crew volumetrics and true reflections and refractions with as opposed to the short cutted version that real-time engines like Eevee use so it provides a much more normal looking a much more natural and a much more realistic image than you get typically with something like eating that being said there are also a lot of negatives that come with these great image qualities these include long render times because again it has to physically calculate each individual ray of light it's prone to noise and fireflies while rendering it's more prone to rendering issues and it's hard to preview what you're working on without actually rendering the image and therefore wasting even more time so when it comes to time oriented work ray tracing engines aren't the most effective so what do real-time engines hold over ray tracing engines well for one it instantaneously updates every time you make a change or even without making a change it'll update it's easy to preview things it's great for visualization there is virtually no render time because it's doing it as you're working and it has a much simpler interface in settings so while it might not be as versatile and customizable as ray tracing engines it certainly does hold the ground in simplicity and usability some of the cons include the fact that it lacks realism and it's never going to be quite as good and quite as normal-looking as realistic as as cycles or other ray tracing engines will be it's heavily limited in terms of what it can do at least Eevee is at the moment I know there are some engines that can do a lot but in the end they are still limited by one factor or another they take shortcuts so what you're seeing isn't actually like a real world sample often it's usually approximated or just some some weird I programming trickery that will make some things look okay but it won't make it look absolutely perfect and these include things like false shadows false reflections and refractions so you won't be getting the true data out of those they're usually approximated and also many real-time engines lack simulation ability or have very poor performance with simulations because in addition to having to calculate the graphics in real time it's also having to calculate the physics in real time so in the end what is each best for and which one best suits you well if you're planning on making something VFX or CGI oriented something that needs to be very realistic or absolutely stunning I would strongly recommend you use a ray tracing engine such as cycles because it provides a much more photorealistic image and gives you a lot more control over what you're working with however if you're planning on either doing something that involves work with real time engines such as a game asset design or perhaps some sort of concept art or visualization I would strongly recommend using a real time engine because they're very useful for that and they have a lot of great capabilities available for that purpose so there you have it that's difference between ray tracing and real time rendering engines or in the case of blender the difference between cycles and easy hopefully this provides you guys with a little bit more insight about what they do and what they're best for and you have any questions please feel free to leave a comment down below I read almost every single comment that come through my channel and I try to apply to all of them in addition if you notice any false information or errors I made in this video please leave a comment down below so you can correct it I'd also like to say thank you to my patrons for making this video possible you guys are the best if you guys would like to become a patron you're more than welcome to however you don't have to you can just enjoy the content for free forever anyway that's about it thank you all for watching and I'll see you guys next time adios you

Channel: Remington Creative

Views: 271,165

Rating: 4.8103251 out of 5

Keywords: blender, education, 3d, cg, cgi, pbr, tutorial, guide, how-to, remington, graphics, lesson, vfx, ray, tracing, rendering, engine, real, time, scan, line, scanline, realtime, eevee, render, vray, cycles, octane, optix, game, raytracing, trace, raytrace, science, math, geometry, physics, internal, vs, comparison, pros, cons, pro, con, tessellation, rasterization, fragment, processing

Id: fAiai0fCBOw

Length: 8min 34sec (514 seconds)

Published: Sat Aug 12 2017

Reddit Comments

[u/Goranimation]

Not to nit-pick but just to make sure mis-information isn't being spread.

Cycles is a Path-Tracer not a Ray-Tracer. The big difference between the two is how they calculate light, While both tracers do fire rays from the camera, a Ray-tracer doesn't actually bounce around the scene, what it does is fire a ray until it intersects with an object, then fires a ray at all the lights in the scene to calculate the value of that pixel. This means a Ray-tracer can only trace direct light (which is why Ray-tracing engines had to do a second calculation for GI)

A Path-tracer on the other hand traces a path from the camera to a light source, it fires a ray from the camera, hits a material, and based on that materials properties it bounces in a different direction, this process is repeated until either the ray hits the ray-bounce limit or hits a light source.

[u/EilonaArt]

It does seem that the blender development team wants to integrate the workflows between the two. So that you can use Eevee as a better view port in the future.