Hi,
I have had a little bit of difficulty trying to understand how exactly a renderer works.
I do know that renderers translate numbers into pictures, and each renderer is designed to solve the rendering equation. Raytracing, REYES and Monte-Carlo (etc…): are those ways to solve the rendering equations, or ways to shade the models in the rendered scene? How exactly does this whole process work?
I am sorry if this is a stupid question, I am having quite a hard time trying to grasp the whole "rendering’ concept.
Raytracing is the use of rays to simulate a lighting system inside of a render engine, many newer render engines are mostly to purely ray-based to to calculate both the shading and lighting producing a physically accurate result, the downside is that it can take a long time because it takes millions of samples to get each pixel to the correct value.
Reyes is a rendering method designed around an algorithm that subdivides each mesh to a sub-pixel level and thus a polygon just has a single color value instead of traditional shading calculated for each pixel within the polygons of an object, the advantage is that is excels at displacement using little memory and low render times while it falters in raytracing and usually works best with legacy shading methods.
Monte-Carlo is a method to distribute rays shot by a raytracer, differing methods may be designed to sample based on accuracy or sample based on speed, in newer engines, this sampling may be largely replaced by the more sophisticated metropolis sampling algorithm which overcomes a great weakness in which the former cannot do rapid rendering of clear and accurate caustic effects (the highlights you might see around glass objects in a well lit room)
Raytracing is a method to gather information from surrounding objects. It is used for lighting simulations (photon mapping/pathtracing, etc) but also to compute reflections/refractions/shadows and even to get the final pixels on your image. It basically just takes a point in space and from there on goes along a defined direction and checks for an intersection with an object and then takes information from this intersection point.
Ace Dragon is basically correct with how Reyes works except that the polygons aren’t shaded. In fact they’re shaded just like in any other render engine.
Personally I think one should understand very basic raytracing, shading and shadow casting (like in Jacco´s explainations) before diving into photorealistic physical correct stuff.
@Arexma: Jacco’s introduction is interesting and it the first image is similar to the one on the luxrender page, but then the article dives quickly into coding stuff. If someone asks me “what is gravity” I’d first tell him that’s what makes apples fall from trees, and then suggest him to read Einstein… as a common-sense-based approach
masoug, thank you for introducing this topic. Thank those of you who provided information and links. Before this thread I had a vague idea how renderers worked, now I understand a bit more and what I’ve learned will materially (No pun intended) help my work.
Well you don´t need to use or understand the code, but that´s as easy as it gets - if one can´t understand Biccos stuff, which is very nice, step by step, one might want to stay away from raytracers. And if linear algebra is alien to one too, don´t even think of going there.
You can summarize a raytracer pretty much this way (which is what Bicco does)
Shoot primary ray from the camera through the mapped image pixel.
Check against all objects if it intersects.
If it intersects, check is it diffuse, transparent, reflective or specular and shoot secondary rays.
4a) If diffuse, calculate normal to hitpoint, calculate secondary rays from hitpoint against all lights, calculate diffuse shading
4b) If transparent, use refraction formula to (normal to hitpoint and material settings) to fire a refracted ray iterative until it is terminated
4c) If reflective, use perfect reflection, (angle in = angle out) via normal of the hitpoint to fire a mirror ray and continue iterative until it is terminated
4d) If specular, calculate a mirror of the light, based on the normal and all lights hitting the hitpoint.
Cast shadowray from all lights to the hitpoint checking against all objects, if it hits the point, it´s in light, if it hits another object first it´s in shadow.
Obviously an object can be 4abcd) all at once, you simply calculate shading and shadow for each of them and feed it back into the image pixel. You terminate the transparency and mirror rays after a set number of iterations (bias).
If the object has a texture, you map the intersection point coordinates against the uv coordinates and use the color in the texure and combine it with shading and lighting.
If you have normal maps, you bend the unified normalvector by the normalmap normalvector to change the shading.
This works with pointlights for starters, emmiting uniform light in all directions. Next steps would be softshadows, area lights, directional lights.
Next step : create a spatial hirarchy such as octree or kdtree to speed up intersection by decreasing the number of objects to search.
Next step: create multisampling. Shoot several jittered or grid rays through one pixel to average its shading. Like AntiAliasing but not really. The effect is the same, the theory is a different one. In theory lol
Next step: basic GI, such as Photon mapping: shoot a set number of photons (equivalent to rays) from all light sources and let them bounce to a set number of bounces or until they have no energy anymore. Store the location where they hit, the energy and from where they hit.
Then you do basic raytracing again, but instead of shading against the lightsources, you “gather photons”.
Around an intersection point, with a given spherical radius you collect the photons and calculate an average of their energy (=color) and shade the object.
That´s basically what my raytracer currently does - more less and worse than better ^^
The next step would be pathtracing then. What I described is basic raytracing, often also called Direct Lighting, or Forward Raytracing.
Pathtracing takes you to a whole new level.
To extend what Ace said about reyes:
The important part is separating shading and sampling. Shading happens in 3d, it when lights, materials settings, textures, displacements etc is calculated. In 3d. Then comes sampling, which is coloring the 2d pixels of the image.
What you essentially do is subdividing each object until the faces are smaller than a pixel (can of course be tweaked, things out of focus or with a lot of motion blur can be less precise), then you shade them. Check all lights, shadows, shaders etc and more or less bake it to vertex colors. Then you sample your image, check whats under each pixel. This is fast since you don’t have to do all those calculations again, so sampling is cheap, sampling in time for motion blur and in space for AA and DOF is not a big problem, and also sample from a different camera! rendering 3d in reyes is fast becuase you still shade once.
A raytracer does the opposite and start with sampling to create a ray and then shade what it hits, making motion blur, dof and AA expensive since each new ray might need a lot of shading.
But why don’t they just keep track of which inputs they processed? If you keep randomly selecting inputs you might be computing some points more than once whilst others never get plotted. A scene has a finite number of points which need to be plotted so keeping track would be the right way of doing things. They could still use random inputs to enable preview.
There are papers out there now that have algorithms that add noise-awareness to path-based methods.
Essentially it works like this, if an area is determined to have little to no noise remaining, sampling for that region stops and all new samples are focused on the remaining areas which can really speed up rendering using such algorithms.
And while with these methods you might only have an approximation, eventually the convergence would be such that you would not be able to tell the difference between if you recreated it in real-life and took a photo and then looked at the rendered image, which by then you would simply stop the rendering because there would no longer be any improvement visible to the eye.
As I recall on noise-awareness, the Lux devs. actually looked at implementing this, but their priorities pointed toward various newer algorithms like SPPM and GPU rendering that would. in the long run, end up being faster still.
