Computer graphics, my journey to understanding

Hello everyone,

I've started a few classes on computer graphics and animation, from a scientific point of view. Since most people are either hobbyists or artists on this forum, I figured some of you might be interested in learning a few things (or rediscovering some things as I'm learning them as well. I can't post most of my learning materials since I'd get expelled otherwise, but I'll do my best anyway. One class will be about photorealistic rendering and the other one about physically based animations and effects.

On the first one we'll program various effects starting from basic illumination to subsurface scattering, going through reflections and procedural generation of effects, geometry etc. Animation will go over rigid body then soft body simulation, with overviews of hair simulation and maybe machine learning techniques to have fast soft body simulation.

If those subjects interests anyone, welcome here, I'll update this thread with new posts when I'll learn new things during my courses.

Quote from Sigma

43 minutes ago, Sigma said: This is great @laminutederire! If you can, you should suggest to your professor that they invite someone from Allegorithmic to come speak to you (they have an office in Paris) as they are doing a lot of R&D at the moment on materials, lighting, etc . . . in efforts to simplify workflows using automation and/or AI.

Nice! Would they be willing to come to Zurich? I'm doing a double degree at ETHZ there. Our professor is at the head of Disney Research (director or vice director I don't remember)(Markus Gross). If you have an email adress I could give him to contact Allegorithmic, that would be super helpful!

I have a computer vision class as well where they could talk about the techniques they can use to extract normal maps from 2d image for instance.

Alternatively it could be awesome for them to come at forums both at ETHZ and French engineering schools (I can put the company in contact with CentraleSupelec where I was studying before going into an exchange degree)

Quote from FMPONE

14 minutes ago, FMPONE said: Would love to learn more. Images are great.

I have an assignment due October in which I'm suppose to code the retracing algorithm, using different way to sample rays and to determine the color displayed. One is a bust I have to render with normal map style and with global illumination. We compute .exr files, you can open that with Photoshop, right?

Quote from Klems

2 hours ago, Klems said: Do you have any GPU programming classes? In any case you should definitely learn some GLSL/HLSL, shader programming is by far the most useful skill you can learn as a graphics programmer. Where are you located, which university? I'm curious.

Best of luck with your classes, just let me know if you need some help!

The computer graphics course is meant to be for ultra photorealism so they haven't put a strain on doing the compute on gpu as for them it would only be about doing the raytracing routine more in parallel. At least thats what I understood but as soon as I'll have advanced I'll try to move to gpu compute if I have the time. I'll probably ask for help then, that's kind of you

I'm in Zurich right now at ETH Zurich in the computer science master degree. Nice city but hellishly expensive!

I've started writing everything down, with a narrative of why we are doing those things. It doesn't seem readable as is, you'd have to tell me!

Follow up

And the end!

Next up later implicit curves and why they are not used as much in some scenarios

Quote from Sigma

6 hours ago, Sigma said: I don't know. I don't work for them or with them. I'm sure Wes's email is probably available (he does a lot of the tutorial videos) and he could probably help in hooking you up.

I called them then sent an e-mail. One guy was pretty excited with the idea and passed on the e-mail to his colleague, so I'm waiting on their answer

My first render which half failed:

The content cannot be displayed because it is no longer available.

I finally finished all my renders. Here they are.

This first one is similar to what ambient occlusion is all about (or so I have heard!). It is a computation of average occlusion on the model. It is rendered by sending a ray, checking if it intersects geometry. If it does, you send another ray in a random direction, and you return the color black if the new ray hits something, whit otherwise. The new ray has a specified length, to determine, how far occlusion is calculated. If you put a longer length, more rays will intersect geometry and it’ll get darker. Then you average it out to get that render.

Afterwards, I computed direct lightning with a single light point. The light point class was implemented with power and position arguments which sufficed to render images with it. The power is distributed uniformly on a sphere, therefore we have:

Power (point) = P_lightpoint/ (4*pi*r^2) where r is the distance between thepoint and the pointlight.

The BSDF model was started to be used here, to determine how light interacts with a given material. This model described the ratio of energy transmitted and reflected from the energy which is incident.

From there you get that a simple diffuse model by sending a ray to the scene, look at where it intersects, and then look if it receives light from emitters. If it does, you calculate the incident power, then you compute how much of this power is transmitted to the camera ray direction.

You then end up with such a render:

From there the textures can change the value of the color and power which is redistributed and so can specularities and so on.

The issue with this method is that it requires to send many rays and compute a lot of intersections. We have to optimize the data structures to reduce the render time. There are three main techniques. We can try to send fewer rays, send more generalized rays which will diminish the number of rays required or we can try to compute fewer intersections. We can of course mix a few of those techniques. Sending fewer rays can be done by terminating rays earlier, and by using adaptive sampling. The first method helps not having too many ray bounces, while the second helps not sending rays to specific pixels where there are few changes at each ray tracing there. The area where there are the most significant optimizations that can be done rapidly are the ones related to intersections. It is believed they account for a significant part of the computation time. The complexity for brute force is in O(N_pixel*N_objects).

They all rely on using the geometric properties to simplify visibility and intersection computations. Some techniques are also related to compression of scene file size. As you might already know, when mapping in counter strike, you create bsp files, which are the result of a discretization of the space (hence the need to have clear boundaries of said space (leaks provenance). Using uniform grids built in the space, and by incrementally rasterizing, we can reduce greatly the render time. However, while it is easy to implement, it isn’t suited for non-uniform scenes. We can have different hierarchy of grids (grids into grids to help with that), or different ways of building grids (octrees, kd-trees or bsp-trees).

they can be explained like this:

and trees are built like this:

If something is unclear or incomplete do let me know, I'm still trying to tweak my content for it to be as enjoyable and worthy of reading time! (And I try to give something useful knowledge wise, I'm not sure if I'm doing something too technical or too high level overview-ish, eo let me know what you'd prefer)

Quote from 0kelvin

11 hours ago, 0kelvin said: Does that course include discussing details about APIs or the hardware itself? I mean, the computing power of GPUs is ever increasing, exponentially in some aspects, but it seems that it's never enough. Toy Story, Finding Nemo or Ice Age, at every new incarnation the graphics evolve, but they still require a lot of processing power and hours to render each frame.

It includes details about how to complexify renders, and which data structures to apply to help Having reasonable complexity. Not that much hardware though. Im thinking about how to implement what I have done in openCL to use my GPU to render, so I'll explain if I succed at that goal

Graphics complexity evolves with the computing power as well. Like sure, we have found ways to render things faster with acceleration data structure, importance sampling etc, but what we gain in time can be used to render more complicated scenes. Just changing the camera model can slow down renders significantly for instance. Because more realistic lens models ask for more ray paths to converge to a good solution.

Been quite busy, hence the late follow up. Spent some time learning how to sample randomly directions and everything. The goal of that was simply to lay ground for direct and global illumination algorithms for more complex effects. Basically, in direct illumination, the complexity will be added by what you do when your camera ray hits the scene. There are a few approach then. The two easiest are the following:

- You can sample the directions in which the reflected ray will be sent, and look if it hits a light. You then assign it a probability corresponding to the surface material, and finally you'll divide the corrected color value by this probability. the color value will be a product of the value of the light, the effect of the surface material, and geometric correction terms.

You get a result like this on a test scene with limited sample number (here it was 64). As you can see, it doesn't perform well on the right. It is this way, because when you shoot the ray, then choose a random point on the larger emitter, you will more easily find a point where the contribution will be negligible, because of geometry properties. It therefore wastes computation resources on useless contribution, and isn't optimal in that type of case.

- You can also sample points on your emitter surfaces, and add the contribution of a ray going from this point to the intersection of the scene and the camera ray. Here you will do the same computation, but with fixed directions. The probability will have to be computed in a different measure to be coherent.

In this method you end up with a lot of noise, and bad results for the smaller emitter. This comes from the fact that the probability to hit it is smaller, and therefore you will waste samples in this opposite case.

The idea behind this and the division by a probability is that you want to integrate over all possibilities the contribution of lights for each directions using the Monte Carlo method. This method approximate the integral of f(x)p(x) by a mean of f(xi) where xi are distributed according to the probability p (I can explain the mathematical details further if that interest you). As this method is a bit slow in terms of converge (O(sqrt(N)) where N is the number of samples), dividing by relevant probability density functions can help convergence if this function approximate well the integrand. That's why we divided by the probabilities in the two method explained.

An interesting thing you can do is to combine those methods by a linear combination of them to get the best of both worlds. This is called multiple importance sampling.

As you can see, here you get the best of both worlds in the same computation time as the other two.

Next will come indirect illumination and why and how photon mapping can be useful, and how it relates in a way to other techniques like normal maps, or ambient occlusion maps.

(PS, what is the best place to link pictures from? (It's very picture heavy and I'm hitting the limit, but I don't want to put those pictures on imgur either ) ).