Some general questions about the terminology

General project and community related discussions and offtopic threads.
Storen
Posts: 20
Joined: Tue Jan 14, 2020 3:27 am

Some general questions about the terminology

Post by Storen »

I trying to get a better understanding of the terminology used for differentiating the capabilities of different 3D rendering software - ray tracing vs path tracing, physically-based vs non-physical, spectral vs nonspectral, etc.

For example, both Cycles and Luxcore use path tracing, both are physically based and nonspectral. Yet, Luxcore produces significantly more realistic results. What are the technologies Luxcore uses to achieve a higher level of realism?

Another thing that I find confusing is raytracing vs path tracing. From what I have been reading online, in general, raytracing is less intense as calculations and produces less realistic results. However, when I compare images from Vray (ray tracer) with Cycles (path tracer) the ones from Vray often look more realistic. What makes Vray outperform Cycles in terms of realism?
CodeHD
Donor
Donor
Posts: 437
Joined: Tue Dec 11, 2018 12:38 pm
Location: Germany

Re: Some general questions about the terminology

Post by CodeHD »

First about the terminology:
Storen wrote: Thu Jan 06, 2022 4:22 pm ray tracing vs path tracing, physically-based vs non-physical, spectral vs nonspectral, etc.
  • "Ray tracing" is really the top-level term to describe the general method, i.e. following the path of a ray of light. Other terms decribe how that is done, for example:
  • "Light tracing" starts at a light source and will end at the camera (same as in reality)
  • "Path tracing" is inverse, starts at the camera and ends at the light. This works because (geometric) light paths are reversible.
  • "Bidirectional" starts at both ends and can additionally connect in the middle.
  • "Physically-based materials": Here, the software algorithm is taken from some scientific description of a material, i.e. an equation found in a text book.
  • "Non-physical" materials may use any made up equations to describe them.
  • "Spectral": The most important difference is that in a spectral rendering engine, the light paths can depend on the color of the light. I.e. when a light hits a surface, and a new direction for the next ray is calculated, the color is included in the equation somehow. Additionally, each ray does not carry RGB information but only intensity.
  • As opposed to that, in a "non-spectral" engine, the color is not inlcuded in the geometry calculations. Each ray has an RGB color that is modified at each intersection.
Storen wrote: Thu Jan 06, 2022 4:22 pm For example, both Cycles and Luxcore use path tracing, both are physically based and nonspectral. Yet, Luxcore produces significantly more realistic results. What are the technologies Luxcore uses to achieve a higher level of realism?
Now, this is not so easy to answer. While this is an observation of what typical LuxCore vs Cycles images look like, realistic-looking images can be created with anything given enough effort from the artist. There are some pronounced differences as a result of the underlying algorithms that, for example:
  • Cycles is not good with caustics because it doesn't have light tracing and caches like LuxCore, which are needed.
  • Also, volumetric scattering can be very different.
Storen wrote: Thu Jan 06, 2022 4:22 pm Another thing that I find confusing is raytracing vs path tracing. From what I have been reading online, in general, raytracing is less intense as calculations and produces less realistic results. However, when I compare images from Vray (ray tracer) with Cycles (path tracer) the ones from Vray often look more realistic. What makes Vray outperform Cycles in terms of realism?
Here I am not sure what you mean. Reagrding the ray-tracing terms, read above first and perhaps specify further questions.
About the "often look more realistic", first consider the userbases of these engines, and don't compare completely different scenes that may have been produced with very different amount of time and effort spent.
Storen
Posts: 20
Joined: Tue Jan 14, 2020 3:27 am

Re: Some general questions about the terminology

Post by Storen »

CodeHD, Thank you much for the detailed response! It is very useful and appreciated.
CodeHD wrote: Thu Jan 06, 2022 9:11 pm "Path tracing" is inverse, starts at the camera and ends at the light. This works because (geometric) light paths are reversible.
My understanding is that even the most simple examples of basic shading in the 3D viewport of every 3D software, game engines, etc. start the rendering calculation by projecting the rays from the camera. In such a case would it be correct to call any 3D software in existence "path tracer"?
CodeHD wrote: Thu Jan 06, 2022 9:11 pm "Light tracing" starts at a light source and will end at the camera (same as in reality)
Do you know of software employing this method exclusively?
CodeHD wrote: Thu Jan 06, 2022 9:11 pm here are some pronounced differences as a result of the underlying algorithms that, for example:
Cycles is not good with caustics because it doesn't have light tracing and caches like LuxCore, which are needed.
Also, volumetric scattering can be very different.
I suspect there are other core diferences that help LuxCore achieve a higher level of realism. Even in scenes without caustics and volumetric scattering the overall illumination and/or the way colored metals are reproduced (for example) are significantly more realistic. There is something in the algorithms that makes the difference. It would be great if some of the software engineers shed light on that.
CodeHD wrote: Thu Jan 06, 2022 9:11 pm first consider the userbases of these engines, and don't compare completely different scenes that may have been produced with very different amount of time and effort spent
Of course, but I wanted to focus entirely on the technical aspects that differentiate the rendering software and the terminology used to describe these differences.

Vray is a "biased" ray tracer. If I understand the term correctly that means the software "guides" the rays so they can find the light sources in the scene faster, with fewer calculations. It calculates fewer reflected/refracted rays (set by a parameter) and tries to guess and approximate the behavior of the other rays based on that data. This typically results in a more synthetic-looking image.

Cycles and Lucxcore are unbiased, often called "brute force renderers. The rays reflect in a random direction and only a few of them reach the lighting sources with each rendering pass. Multiple passes are necessary to calculate enough "successful" rays to achieve acceptable rasterization and reduce noise (missing rays). The process is not guided nor approximated by the software therefore it resembles closer the natural behavior of the light.

With that being said I wonder how a "biased" ray tracer such as Vray could achieve a more natural look through simplified calculations and approximation, than an unbiased, brute-force software like Cycles? Is there any specific known technology or algorithm that helps the Vray developers to achieve that?
CodeHD
Donor
Donor
Posts: 437
Joined: Tue Dec 11, 2018 12:38 pm
Location: Germany

Re: Some general questions about the terminology

Post by CodeHD »

Storen wrote: Thu Jan 06, 2022 11:14 pm My understanding is that even the most simple examples of basic shading in the 3D viewport of every 3D software, game engines, etc. start the rendering calculation by projecting the rays from the camera. In such a case would it be correct to call any 3D software in existence "path tracer"?
"any 3D software in existence" is just way too hard a statement to be 100% correct. But sure, I have no doubt that the path tracing is by far dominating such applications.
Storen wrote: Thu Jan 06, 2022 11:14 pm Do you know of software employing this method exclusively?
None that I know of in (artistic) 3D rendering. Optical Simulation software for engineering or scientific applications would be an example though.
Storen wrote: Thu Jan 06, 2022 11:14 pm It would be great if some of the software engineers shed light on that.
I would leave this to someone like Dade who has more insight on the inner workings of other engines.
Storen wrote: Thu Jan 06, 2022 11:14 pm With that being said I wonder how a "biased" ray tracer such as Vray could achieve a more natural look through simplified calculations and approximation, than an unbiased, brute-force software like Cycles? Is there any specific known technology or algorithm that helps the Vray developers to achieve that?
And this one to someone who has hands-on experience with V-Ray ;)
Since LuxCore or Cycles can both achieve extremely good results, I am 100% sure the answer is just about simplicity of acheiving a good looking (!) result. Good looking, because not everyone has the goal to make something that IS realistic, it just needs to look like so.

P.S.:
I mentioned scientific/engineering applications above. The most well known examples of these are probably "Zemax" and "CodeV", used for Lens Design. They fall into yet another distinction of ray tracing engines not covered by 3D-graphics software as discussed here:
  • Lens design is typically done with "sequential" ray tracing. Imagine a camera lens: The main rays forming the image will go through the lens one surface by one in order. This elimintes the step of finding which surface is hit next, because you already know. (Even for lens flares, you jsut change direction, go back a few, then forward again)
  • LuxCore, Cycles etc. are built around being "non.sequential". Rays may bounce from any surface to any other. Software like Zemax can do this too, e.g. to compute stray light from the lens mount, but It's not their main application.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Some general questions about the terminology

Post by Dade »

Storen wrote: Thu Jan 06, 2022 11:14 pm I suspect there are other core diferences that help LuxCore achieve a higher level of realism. Even in scenes without caustics and volumetric scattering the overall illumination and/or the way colored metals are reproduced (for example) are significantly more realistic. There is something in the algorithms that makes the difference. It would be great if some of the software engineers shed light on that.
If you keep out of the picture the features LuxCore has and Cycles doesn't (light tracing, metropolis, photon mapping, BiDir, etc.), it is true LuxCore and Cycles are both unbiased path tracers. However the default settings are very different.

Cycles defaults settings will cut a lot of possible light paths (pretty much anything not noise free in few samples).

LuxCore defaults settings will render all possible light paths (no matter of the noise and the rendering time required).

You can configure LuxCore to render exactly the same subset of light paths Cycles does but you will have to change a LOT of settings.

Actually, the opposite is also true, you can configure Cycles to render as LuxCore plain path tracer does (again, this is true if you keep the features LuxCore has and Cycles doesn't, out of the picture).
Support LuxCoreRender project with salts and bounties
Storen
Posts: 20
Joined: Tue Jan 14, 2020 3:27 am

Re: Some general questions about the terminology

Post by Storen »

Dade wrote: Fri Jan 07, 2022 10:59 pm features LuxCore has and Cycles doesn't (light tracing, metropolis, photon mapping, BiDir, etc.)
The light tracing option is very interesting. If I set the "Glossiness Threshold" to 1 does that mean LuxCore would use the "Light Tracing" method for the entire scene tracing all the rays in the scene starting from the light sources instead of the camera? Basically, Luxcore won't be path racing anymore?

Screen.jpg
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Some general questions about the terminology

Post by Dade »

Storen wrote: Sat Jan 08, 2022 4:27 pm If I set the "Glossiness Threshold" to 1 does that mean LuxCore would use the "Light Tracing" method for the entire scene tracing all the rays in the scene starting from the light sources instead of the camera?
"Glossiness Threshold" affects only Glossy and Glossy-like materials so what you write is true only for them.
Support LuxCoreRender project with salts and bounties
JulianoLisboa
Posts: 146
Joined: Sat Feb 22, 2020 3:29 am

Re: Some general questions about the terminology

Post by JulianoLisboa »

Dade wrote: Fri Jan 07, 2022 10:59 pm
You can configure LuxCore to render exactly the same subset of light paths Cycles does but you will have to change a LOT of settings.

Hi Dade, this part up here left me with a doubt. How about implementing presets in luxcore with 3 settings: Fast (to get as fast as cycles), medium (a compromise between speed and high quality) and High (with the maximum quality standard of luxcore). That way users of cycles would lose the speed argument and could test Luxcore further discovering over time that it is a great renderer. I think it would be an interesting marketing strategy.

Best Regards,

Juliano
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Some general questions about the terminology

Post by Dade »

The scope is a bit larger than only render settings, for instance Cycles "default" is to have glass always with shadow transparency, glossy material is filtered and clamp reflected light sources, etc.
Support LuxCoreRender project with salts and bounties
JulianoLisboa
Posts: 146
Joined: Sat Feb 22, 2020 3:29 am

Re: Some general questions about the terminology

Post by JulianoLisboa »

I totally understand, but it would be nice to have some speed presets from luxcore itself.
Post Reply