Ray Tracing, why does the GGX make my rendering result darker and darker for each frame? I am trying to add GGX and PBR textures to my GPU ray tracer. The result is very strange, it's getting darker for each frame.

        float ao = texAO.sample(textureSampler, hitRecord.uv).r;

        float3 albedo = texAlbedo.sample(textureSampler, hitRecord.uv).rgb;
        albedo = pow(albedo, 2.2); //albedo = float3(1.0);

        float metallic = texMetallic.sample(textureSampler, hitRecord.uv).r;
        float3 tNormal = texNormal.sample(textureSampler, hitRecord.uv).xyz;
        tNormal = normalize(tNormal * 2 - 1);

        float roughness = texRoughness.sample(textureSampler, hitRecord.uv).r;
        roughness = max(roughness, 0.001);

        float3 nx, ny;
        CoordinateSystem(normal, nx, ny);
        float3x3 stw = { nx, ny, normal };

        normal = stw * tNormal;
        CoordinateSystem(normal, nx, ny);
        stw = { nx, ny, normal };

        float3 wi, wh;
        float3 wo = transpose(stw) * (ray.direction);

        auto pSpecular = 1/(2-metallic);

        auto r0 = randomF(seed);
        auto r1 = randomF(seed);

        if (randomF(seed) > pSpecular) {

            float sinTheta = sqrt(r0);
            float cosTheta = sqrt(1-r0);

            float phi = 2.0 * M_PI_F * r1;

            float x = sinTheta * cos(phi);
            float y = sinTheta * sin(phi);
            float z = cosTheta;

            wi = { x, y, z };
            wh = normalize(wo + wi); // not specular

        } else {

            auto a1 = roughness;
            auto a2 = a1 * a1;

            auto theta = acos(sqrt((1-r0) / ((a2-1)*r0+1)));
            auto phi = 2 * M_PI_F * r1;

            auto x = sin(theta) * cos(phi);
            auto y = sin(theta) * sin(phi);
            auto z = cos(theta) * 1;

            //wo = transpose(stw) * (ray.direction);
            wh = normalize( {x, y, z} );
            wi = reflect(wo, wh);
        }

        if (wi.z <= 0 || dot(wh, wi) <= 0) { return false; }

        auto D = NDF(wh, roughness);
        auto G = GX(wo, wi, roughness);
        auto F = FX(wi, wh, albedo, metallic);

        float denominator = 4.0f * abs(wo.z * wi.z);

        auto specular = D * G * F / max(FLT_MIN, denominator);

        auto diffuse = albedo / M_PI_F;

        auto kS = F;
        auto kD = (1 - metallic) * (1.0f - kS);

        ray = Ray(hitRecord.p, stw * wi);
        scatRecord.attenuation = (kD * diffuse + specular) * ao;

        //auto pdf = PDF(wh, roughness);
        //scatRecord.attenuation /= abs(pdf);

        return true;

// Normal Distribution Function
float NDF(const thread float3& h, float roughness) {
  //  GGX / Trowbridge-Reitz

  float a1 = roughness;
  float a2 = a1 * a1;
  float NoH = abs(h.z);

  float d = (NoH * a2 - NoH) * NoH + 1;
  return a2 / (d * d * M_PI_F);
}

// Geometry Function
float GX(const thread float3& wo, const thread float3& wi, float roughness) {
  // Schlick, remap roughness and k

  if (wo.z >= 0 || wi.z <= 0)
      return 0;

  float k = pow(roughness + 1, 2) / 8.f;

  k = pow(roughness, 4);

  float G1_wo = wo.z / (wo.z*(1 - k) + k);
  float G1_wi = wi.z / (wi.z*(1 - k) + k);
  return G1_wo * G1_wi;
}

// Fresnel
float3 FX(const thread float3& wi, const thread float3& h, const thread float3 albedo, float metallic) {
  // Schlick’s approximation
  // use a Spherical Gaussian approximation to replace the power.
  // slightly more efficient to calculate and the difference is imperceptible

  float3 F0 = mix(float3(0.04f), albedo, metallic);
  float HoWi = dot(h, wi);
  return F0 + (float3(1.0f) - F0) * pow(2.0f, (-5.55473f * HoWi - 6.98316f) * HoWi);
}

http://graphicrants.blogspot.com/2013/08/specular-brdf-reference.htm - here is reference with different geometry shading equations
http://jcgt.org/published/0003/02/03/paper.pdf - paper explaining how G term works and on what assumptions it is build.

Looking again at your code, I'm not sure (based on first link to Karis blog) if your G term is calculated correctly.
  float k = pow(roughness + 1, 2) / 8.f;
  k = pow(roughness, 4);

You're overwritting k with roughness^4, which doesn't fall into any Schlick equation that can be seen in Karis blog and if I recall correctly, I haven't seen that in any papers. Another note is, that you're passing ωo and ωi to your geometry function, but based on your comment that this is Schlick G and overall context, I think that you should use NoL and NoV (dot first pointToLight direction and then viewDir).
I was trying to do my own image, but I found [Blinn 1977] paper which sums up how Smith G model works (take a look at figure 1) - https://www.microsoft.com/en-us/research/wp-content/uploads/1977/01/p192-blinn.pdf#page=2&zoom=auto,-264,459
Some time ago, I was playing a little with different D, F, G equations - https://github.com/komilll/dxFramework/blob/master/dxFramework/Shaders/PS_BRDF.hlsl - take a look at PS_BRDF.hlsl and PS_BRDF_Helper.hlsl for further reference. I was basing my equations on Karis blog, some are modified base on other papers e.g. Frostbite and Disney diffuse are based on respective papers if I recall correctly.

I'm not sure if that's causing a problem, but it's worth fixing for sure. Also I don't think that you're using for summing frames
(previous_average * frame_count + current_color) / (frame_count + 1)

is correct, neither for uniform or importance GGX sampling. You should derive pdf in that case, it can be found in link that I've sent you before - http://cwyman.org/code/dxrTutors/tutors/Tutor14/tutorial14.md.html - it's generally nice tutorial, with good step by step introduction to DXR.


What is Tessellation in computer graphics In recent games I have noticed something called Tessellation, Turning the thing ON destroys my frame rate.

I have noticed that it when turned on it looks like Anti - Aliasing.

Can someone give me further information on what exactly the GPU does.

Tesselation is a technique that allows you to generate primitives (triangles, lines, points and such) on the graphics-card. Specifically, it lets you repeatedly subdivide the current geometry into a finer mesh.

This allows you to load a relatively coarse mesh on your graphics card, generate more vertices and triangles dynamically and then have a mesh on the screen that looks much smoother.

Most of the time this tesselation is done anew in each single frame and this could be the reason that your frame-rate drops once you enable this.

Tesselation is done in multiple stages, and it is done AFTER the vertex shader.

The terms for each stage varies based on the API. In DirectX, it is the Hull Shader, Hardware Tessellation, and the Domain Shader. In OpenGL, they are called the Tessellation Control Shader, Tesselation Primitive Generation, and the Tessellation Evaluation Shader.

The first and the last stage is programmable, the actual tesselation is done by the hardware in a fixed function stage.

In the Tesselation Control shader you set the type and number of subdivisions.

Then the hardware tessellator divides the geometry according to the Control Shader.

Lastly, the Tessellation Evaluation Shader is called for each newly generated vertex. In this shader, you set the type of primitive you want to generate and how the vertices are spaced and many other things. This shader can also be used to do all sorts of per-vertex calculations just like a vertex shader. It is guaranteed to be called at least once for each generated vertex.

If you want to do any further work on the primitives, you can add a Geometry shader.


What are the use cases for multiple render passes? From what I understand of Vulkan, we have a render pass with its associated image resources and subpasses, and each subpass accesses those resources and may synchronise with previous subpasses to process the scene. In a 3D scene, we will have some geometry and lighting and shaders etc. we can do depth pass, deferred shading and so on - and that can all be encapsulated in a single render pass, by chaining multiple subpasses and their results together.
Excluding the scenario of tiled rendering, or when we are rendering to multiple final render targets, when would we ever need multiple render passes in a 3d scene? I understand that something like post processing or UI compositing could be implemented in a second render pass, as they need the result from the first 3d pass to present the final image. I am at a loss as to a situation whereby a game engine, let's say, would need multiple render passes, as all of its geometry and lighting and shading etc. can be drawn with the same render pass, and that render pass will contain all the final necessary buffers, like the final image.
Other than using multiple render passes as you might use subpasses (each render pass relying on the previous one in some way and each render pass having only one subpass) - what is the point?
I am very much a beginner to Vulkan and to all of these concepts so please forgive any errors in the question itself or naive notions.

Instead of listing specific use cases, I will explain the technical limitations of a render pass structure which would prevent someone from putting all of their rendering within it. The use cases naturally fall out from those limitations.
The most important being this: you cannot arbitrarily access any of the images attached to the render pass throughout the entire render pass. It doesn't matter if a particular subpass doesn't use the image as a render target throughout that subpass; you cannot bind it as a texture/image and read from/write to it in a shader. This covers the entirety of the render pass from start to end.
Now, there are input attachments. These are uses of attachments that allow you to read from them in the shader. However, they aren't textures (though they are descriptors); they have more limitations than textures. The most important limitation being that you can only read from a pixel that corresponds to the current fragment's location (and also, you can only read them from a fragment shader). You can't fetch data arbitrarily from the image. A particular FS invocation can only read the specific pixel that was written previously at this FS invocation's location.
Now, you can do some things within that limitation. You can do programmatic blending, for example. You can do deferred lighting passes, since any particular FS invocation only needs to read gbuffer data from the specific pixel for that invocation's location.
But the main point is this: any effect which requires arbitrarily reading from an image that was rendered to must be in a different render pass from the render pass that rendered that image.


How much should I rely on Geometry shaders in WebGL? Geometry shaders appear to have been introduced in 3.2, which makes me wonder how common 3.2-enabled cards are, including support for Geometry shaders within WebGL contexts.

Will I be cutting out a large portion of viewers by requiring the use of a geometry shader?

WebGL doesn't even currently support geometry shaders, so to directly answer the question: 100% of all users.


Composition of decomposed transformations Say I have a scene graph, and each node has a scale, rotation, and translation. Can I combine these into a single scale, rotation, and translation?

Yes you can, provided that all the nodes' scales are only uniform scaling—the same scaling factor along all three axes. If there is nonuniform scaling (different factors along different axes) then things get more complicated, and the composed transformation generally can't be decomposed cleanly into scale, rotation, and translation.

One way to accomplish this is to convert all the individual nodes' transforms into 4×4 matrix form, multiply the matrices down the tree from root to leaf, then decompose the resulting matrix (see this answer for how to do the decomposition).

However, if you have all the transforms in TRS form (translate, rotate, scale—assuming column vector convention) and you want the final transform in TRS form, you can also combine them directly.

The final scale is just the product of all the individual nodes' scales
The final rotation is just the composition of all the individual nodes' rotations (in quaternion form for example)
The final translation is made by summing the translation vectors, but transforming each vector by the composite scale and rotation of all the nodes above it in the tree. For example if you have a transformation $T_1 R_1 S_1 T_2 R_2 S_2 T_3 R_3 S_3$ (numbering from the root down to the leaf), then the final translation is $t_1 + (R_1 S_1) t_2 + (R_1 S_1 R_2 S_2) t_3$.


How to decide which child of BVH to visit based on sign of ray's direction vector? I'm reading about BVH from PBRT. According to the book, in the linear bvh part using morton encoding:

  An efficient way to perform a front-to-back traversal without incurring the expense of intersecting the ray with both child nodes and comparing the distances is to use the sign of the ray’s direction vector for the coordinate axis along which primitives were partitioned for the current node: if the sign is negative, we should visit the second child before the first child, since the primitives that went into the second child’s subtree were on the upper side of the partition point. (And conversely for a positive-signed direction.)

I'm unable to understand how the sign of the ray's direction vector helps in deciding which child to visit. If the partitioning axis is x, doesn't the point with a lower x come in the 1st child? Or have I understood something wrong?

In your example of a BVH cell partitioned along the x axis, if the ray is going left to right (increasing x), then the cell with the lower x comes first; but if it's going right to left (decreasing x), then the cell with the higher x comes first. So, you can look at the sign of the x component of the direction vector to determine which cell to test first.


Feeding acceleration structure to the GPU then raytracing it in a compute shader? I want to use Vulkan's rasterization to solve for the visibility problem, but once that is done I want to do shading, reflection and transmission through a raytracer which also runs on the GPU. With a lot of geometry however it's pretty much a need to have some sort of binary partition tree. How can I have C++ and the vulkan shader language communicate this tree? I thought about pushing the tree into GPU memory wrapped in a buffer, but then of course pointers to the left and right bounding box node (it's a binary tree) wouldn't translate.

It seems my only option is to pass an array of bounding boxes, then pass a tree which just keeps indexes of this array instead of absolute pointers, but that really seems like a botch, because I'll need to traverse the entire tree to assemble the linear array and convert the pointers to indexes of that array.

I would also need to keep in mind how the compiler packs structs (and thus how I read them in the shader). For now I won't even consider that certain datatypes of certain sizes may not even exist on some gpus to keep my head from exploding.

Since generating a bsp tree is badly parallelizable I'm not considering doing it on the gpu.

Edit: the objects will also be interacting physically so I need to have a tree available for the CPU as well. I can't just keep all of the geometry on the GPU from the get go.

If using the new real-time ray tracing functionality is an option for you, it would be worth a try! It might be that getting it to run is less work than porting your CPU data structure into a GPU-compatible format. Furthermore, using the hardware functionality would result in much better performance since BVH traversal (and triangle intersection, if that is relevant to you) are accelerated in hardware.

Official real-time ray tracing support has been announced by Khronos (in the form of an KHR extension) lately, see Ray Tracing In Vulkan. With the Vulkan API version 1.2, the option for "Ray Queries" has been added. It could be relevant for your use case since it allows to trace rays against the BVH from arbitrary shaders (i.e., e.g., also from compute shaders or fragment shaders).

Using VK_KHR_ray_tracing (or NVIDIA's precursor VK_NV_ray_tracing), you would have to update the acceleration structure on the GPU every time after you have updated your CPU data structure. The API supports updating acceleration structures every frame. In NVIDIA's extension this is done via the VkBool32 update flag in vkCmdBuildAccelerationStructureNV. In the KHR-extension it is handled a bit differently, but in a very similar fashion: The update-flags are contained in the VkAccelerationStructureBuildGeometryInfoKHR structures.


What is the name of toroidal 2D space I have a 2D space of dimensions (X,Y) with toroidal properties :
In this space, when a point A(x,y) change it's position such as x is getting > X or < 0, then x becomes (x % X).
So when the point reach the bottom of the space, it get back to the top.
And the same for y coordinate.

What is the name of such a space ?

I supposed it was toroidal space, but I can't find any resources with such terms.

As I said in the comments, this is indeed called torus or toroidal space when it comes to the topology. Even if the images suggest something 3 dimensional, this is just a visualization of the embedding of such a space in $\mathbb R^3$.

Regarding the distance between two points, I think you mean following:
Just consider the coordinates $p=(x_1,y_1)$ and $q=(x_2,y_2)$ in the $[0,X)\times [0,Y) \simeq (\mathbb R / X\mathbb Z)\times (\mathbb R / Y\mathbb Z)$ square. Then define all the translations $q_i$ of $q$ :

$$
\begin{align*}
q_0 &= (x_2\hphantom{+X\,\,\,},y_2\hphantom{+X\,\,\,})\\
q_1 &= (x_2+X,y_2+Y)\\
q_2 &= (x_2\hphantom{+X\,\,\,},y_2+Y)\\
q_3 &= (x_2-X,y_2+Y)\\
q_4 &= (x_2-X,y_2\hphantom{+X\,\,\,})\\
q_5 &= (x_2-X,y_2-Y)\\
q_6 &= (x_2\hphantom{+X\,\,\,},y_2-Y)\\
q_7 &= (x_2+X,y_2-Y)\\
q_8 &= (x_2+X,y_2\hphantom{+X\,\,\,})
\end{align*}$$

Then I think the distance you're looking for is

$$d(p,q) = \min_{i=0}^8 \Vert p-q_i \Vert$$


Can I use my phone's gpu as an external gpu for my laptop? My phone is Sony Xperia XZ1 Compact which has Adreno 540 as gpu. My laptop's gpu is NVIDIA GeForce 940MX 4GB which seems to be much worse than my phone's gpu. My PC's OS is Ubuntu 16.04.

No. Your phone's GPU is in one chip with the CPU, some of the memory, and its display controller, and they're all tightly integrated together. Also, there'd be no way to connect it efficiently to the laptop. Only the latest generation of USB and Thunderbolt have enough bandwidth to be even worth considering for external GPUs, and even then, they're only used with dedicated hardware at the GPU end of the link - not a general-purpose processor. Apart from the fundamental problems, there's the very practical issue that your PC doesn't have any drivers for the GPU on the phone.

I know mobile GPUs are pretty effective, but if your phone's GPU seems faster than the Nvidia chip in your laptop, there's something wrong with your laptop. If you can give more information on the problem to the people at Ask Ubuntu, they can probably help with that.


YUV to HSV to RGB issues As per this resource, there is an easy way to convert from YCbCr to HSV. Saturation is sqrt(Cb^2 + Cr^2). Now here is my issue. If I take pure red (1,0,0), green(0,1,0), and blue(0,0,1) colors, convert them to YCrCb, and then compute saturation, I do not get 1. Infact, all the saturations are different no matter which matrix I use for RGB to YCrCb conversion. Am I missing something?

Think about it this way. To calculate YCbCr of (1, 0, 0), you'll end up with Y = 0.299, Cb = -0.16873, Cr = 0.5. If you take the magnitude of the chroma channels (sqrt(Cb*Cb + Cr*Cr)), you get ~0.53 for the "saturation". The YCbCr color space has a different shape than RGB, so it may represent values differently enough that you don't get the exact same answer in both cases. Furthermore, our perception of luminance and saturation is not consistent among colors.

If all you want is to calculate the saturation of an RGB component, it can be calculated by:

float saturation = max(r, g, b) - min(r, g, b);

Note that if you attempt to calculate perceptually uniform amounts of color saturation you end up with systems like the Munsell Color System where the shape of the color space is highly irregular compared with the cubes and cylinders of other color spaces.

If you tell us what you're trying to achieve, we might be able to offer an actual solution to whatever the problem is.


Zero-copy texture reading from CPU memory The Intel 740 AGP graphics card read textures directly from system RAM, using VRAM exclusively for depth buffers and the framebuffer. This has the effect of saving video RAM, and it could be implemented with AGP transfer speeds far lower than PCIe transfer speeds of today.

Is such a method of zero-copy texture loading possible/optimal on modern discrete graphics hardware? Is there a specific hardware feature that was present on the i740 requisite for this technique that is not present on modern graphics cards? Furthermore, could zero-copy texture access functionality be exposed by using mapped buffers in OpenGL?

Is such a method of zero-copy texture loading possible/optimal on modern discrete graphics hardware?

You say that as though it were optimal back then. The Intel 740 was not exactly warmly embraced by the market, as noted by the Wikipedia article in question:

  The AGP Texture concept soon proved to be a tremendous error in design, because the card had to constantly access the textures over a channel that was upwards of eight times slower than RAM placed on the graphics card itself.

The disparity between available memory bandwidth/performance and available compute resources has only increased in the last 20 years. So, will it be "optimal" to have a discrete GPU read from main memory?

No.

Could it be "possible"? Not in terms of marketability. Even $50 and below discrete GPUs carry their own on-board RAM. Anything much slower/smaller than that isn't worthwhile, because pretty much everyone already has Intel or AMD's on-die GPUs for when performance isn't of importance. If you have a discrete board, it will always be better to put some RAM on the board with its own bus than to have the board try to read most of its data directly from main memory.

  Furthermore, could zero-copy texture access functionality be exposed by using mapped buffers in OpenGL?

No. Mapped buffers would be buffers, not textures. They're different kinds of storage objects with (hypothetically) distinct allocations behind them. PBO is a means of asynchronously transferring data from a buffer to a texture. That is a transfer of data, not an adoption of a memory allocation.

Intel has an extension for mapping a texture's storage, but that requires that the texture be in a linear format. It's not widely supported, and likely never will be.

Vulkan provides for the possibility of something similar, but using linear texture as sources in sampler read operations from a shader is not required to be supported. You'd have to ask each implementation whether it allows it and in which formats, and for which usages are allowed.


Is there a material that contributes to GI, but isn't directly visible? I am doing renders of the inside of a room. I would like to show a "bird's eye" view of the room, from above the ceiling (outside the room), but still see the interior of the room.

An easy way of doing this is to simply hide or remove the ceiling surfaces. However, this has the side effect of reducing the amount of lighting in the scene, because the ceiling no longer reflects light into the room. The top corners and edges of the walls also are no longer lit accurately.

I would like to render the scene as if the ceiling was there, but without the ceiling actually being (directly) visible.

Is there a name for this problem, a technique, or material?

You can use single sided triangles for the ceiling so that they are pointing towards the room. This way the ceiling influences the GI in the room but you can see through it when observing from outside


What is a nonrigid motion? Can you explain me what a nonrigid motion is?
In German it would be a "unbewegliche Bewegung" but I think it has to be translated in a different way.
I could imagine that it means something like the scene window is moving but the elements in the scene are staying in the same position.

I read it in the context of a paper about quantitative optic flow comparison.

Generally a non-rigid transformation is motion that doesn't preserve the shape of objects. If you look at a typical transformation matrix, rigid transformations would include translation, rotation, and reflection. Things like shear, uniform or non-uniform scale, and perspective would be non-rigid. Shear and scale would fall into the category of affine transformations, and perspective is of course perspective transformation. So there's a hierarchy of types of transformations:

Rigid transforms - translation, reflection, and rotation. These perserve the distances between every pair of points on objects.
Affine transforms - rigid + shear and (possibly non-uniform) scale
Perspective transforms - Affine plus perspective transforms (think of a rectangle rotated around the upward pointing axis - the part closer to the camera/viewer may be larger than the pre-transformed object, and the part farther away may be smaller)

I haven't done a lot with optical flow, but I would guess that as you figure out the path of motion of various points on an object, you would be able to classify them into one of the above categories. If all the points in an object move in tandem, then you probably have rotation and/or translation only (rigid transforms), but if they don't then you may have an affine or perspective transform between the points.


How to create static alpha masks of an image I have an image of following type-

I want to create mask of the following type where the inside area is white and rest of it is black. How to do it?

You can either use a threshold, or, since you know the location and size of the 2 circles, simply generate one programatically. In this case, you have a circle that's centered at (279, 283.5) and has a radius of 265. (I haven't calculated the center and radius of the smaller circle, but you should be able to do that fairly easily by looking at the image in any image editor that shows you mouse coordinates.)

Once you have the smaller circle radius, for each pixel in the mask find the distance to the large circle center and if it's less than the large radius, color it white. Otherwise take the distance to the smaller circle and if it's less than the smaller radius, color it white. Otherwise, color it black.


What is fwidth and how does it work? The OpenGL documentation states that fwidth returns the sum of the absolute value of derivatives in x and y.

What does this mean in less mathematical terms, and is there a way to visualize it?

Based on my understanding of the function, fwidth(p) has access to the value of p in neighboring pixels. How does this work on the GPU without drastically impacting performance, and does it work reliably and uniformly across all pixels?

Pixel screen-space derivatives do drastically impact performance, but they impact performance whether you use them or not, so from a certain point of view they're free!

Every GPU in recent history packs a quad of four pixels together and puts them in the same warp/wavefront, which essentially means that they're running right next to each other on the GPU, so accessing values from them is very cheap. Because warps/wavefronts are run in lockstep, the other pixels will also be at exactly the same place in the shader as you are, so the value of p for those pixels will just be sitting in a register waiting for you. These other three pixels will always be executed, even if their results will be thrown away. So a triangle that covers a single pixel will always shade four pixels and throw away the results of three of them, just so that these derivative features work!

This is considered an acceptable cost (for current hardware) because it isn't just functions like fwidth that use these derivatives: every single texture sample does as well, in order to pick what mipmap of your texture to read from. Consider: if you are very close to a surface, the UV coordinate you are using to sample the texture will have a very small derivative in screen space, meaning you need to use a larger mipmap, and if you are farther the UV coordinate will have a larger derivative in screen space, meaning you need to use a smaller mipmap.

As far as what it means in less mathematical terms: fwidth is equivalent to abs(dFdx(p)) + abs(dFdy(p)). dFdx(p) is simply the difference between the value of p at pixel x+1 and the value of p at pixel x, and similarly for dFdy(p).


Human Readable/Writable 3D Representation Formats/Languages? My goal is to create 3D meshes without the use of a 3D editor.  So I want to know what representation languages and formats there are that are designed for this or otherwise that would be good for this.  I would prefer one that is open and widely supported.  Something like a 3D version of SVG or Postscript would be ideal.

There are a number of formats that might fit the bill. Depends on what you want to achieve.

Most likely your looking for a scene description language for renderers. Many of them are for that one renderer but at least one is a standard. So you might be looking for something like:

RIB, Renderman Bytestream although it comes with as a programming api as well. This is a based on a standard set by Pixar and is used by a number of render engines some of which are open source.
Most other rendering solutions also have textual formats I'm somewhat familiar with the mi (mental ray text or binary stream) formats and the now archaic Povray formats. But many others exist.

It is a bit debatable whether these really are human readable but given that you specify SVG then I guess they are at least and readable as that. Just more complex. Note like SVG these describe scenes.

Then we have dae also known as collada. Which is sort of human readable has a similar niche as RIB but is aimed for game assets. A number of other somewhat similar formats exist like the mostly deprecated VRML format, and its successors.

Then we have a bunch of polygon formats, many of them are binary. But atleast obj and ply are human readable and widely accepted. Obj is a very simple format. Although polygon meshes are seldom really easy to understand or craft manually if they are more complex.

Then we have a bunch of application specific formats. For example the ma, Maya ascii, format which is human readable if you understand how maya node hierarchy works. Cant say much of the others.

Then we have the CAD transport formats IGES and STEP. I wouldn't go and claim either to be human readable. But I have hand crafted both on a occasion. Both of these are ISO standards, although STEP is insanely big and was in fact the biggest of ISO standards in page count last time I checked.

There are quite many of these formats because 3D is not as uniform as 2D is. But, yes, I have hand crafted all of these at one point or another. Does not mean i would consider doing so as a productivity tool. Unlike EPS or SVG, which I craft bi weekly by hand.

If I would have to guess your motives then i would say RIB is probably what you want. Or then your looking to use obj.


fastest way to "read only" from buffer First of all I have a struct which looks like the following:
struct structName
{
    vec3 position;
    float radius;
    float type;
    ...some more information which are definitely needed! Not sure how many, but most probably less than 10
};

there are like 200 of these struct elements within my scene. When rendering the scene these objects are fixed. That mean, that they don't change during rendering the scene. They only change after rendering the scene.
Right now I am using a SSBO to store the elements.
Inside my vertex shader (of another geometry) I am reading out all 200 struct elements, iterate over them and make a calculation. This is slowing down my shader...
I am trying to improve the speed of the shader. So I am looking for a better way to read the data.
Lets talk about the limitations:

Within the shader I NEVER change any value of any element within the struct (read only).
All vertices within my other geometry need all 200 of these struct elements.
The iterated calculation result for each vertex is different (has something to do with the vertex position) So the calculation can not be outsourced.
The 200 elements will not be rendered at all. They are only information which is needed for other geometry
Each of the 200 struct elements will be changed after each render call (60 FPS => 60 times each of the elements have been changed).
The new values of the elements are calculated within another shader program (shader2). So they are "read only" during the render call, and "read/write" during the calculation in shader2.
The elements need some atomic operation functions during the calculation in shader2 (atomic add).

I think to store it as a SSBO slows down my shader, because shaders are able to read/write to SSBOs so the elements are lying down on some global memory which is slow. Maybe some other buffer type is the correct one... but which one? uniform buffer objects sounds good, because uniforms are const. So maybe when using it as uniform buffer a copy will be put to a local GPU memory so that each shader instruction can access these memory faster.
Which buffer type is needed to increase the FPS of my program under these circumstances?
An alternative may be to read the whole buffer within the vertex shader at once? (not sure if this is possible) The size is already known (200 * sizeof(structName)). For me it is also okay, if the data is stored in an float array each value next to each other.
Thanks a lot!

I think you may be focusing on the wrong thing here. Moving the data from an SSBO to a uniform buffer might give some speedup, sure, but that is a micro-optimization.
I would search for algorithmic optimizations first. As noted in the comments, processing all 200 records for every vertex is both a lot of data to read, and a lot of computation to do if there's a lot of vertices. Also note that in the course of rendering, vertices will sometimes be processed more than once as they are used by multiple triangles (the vertex cache helps with this, but it can't eliminate all duplicate processing). So you will be re-doing this expensive computation multiple times for the same vertex, sometimes.
Does every vertex really need to process every data element? I see that your data elements have a position and radius. If they represent some kind of mesh deformation that happens within a localized volume of space, then it might be beneficial to store those in an acceleration structure. This would allow each vertex to efficiently narrow down its processing to only those elements that affect it. For example, you could create a regular grid spanning the bounding box of your mesh, and in each grid cell store a list of indices into the main data array for the elements that intersect that grid cell. The creation of this grid could be done in a compute shader earlier in the frame, and should be quite fast. Then, when drawing the mesh, the vertex shader would look up which grid cell the vertex is in, and process those data elements. This is very similar to how we do tiled/clustered shading for light sources in many game engines.
If spatial subdivision like that doesn't get the job done (for example if many of the elements are of large radius, so that most/all of the vertices really do need to process most/all of the elements), then are the elements' influences on the vertices parallelizable in any way? For instance, are you summing a perturbation generated by each element, to arrive at a total displacement for the vertex, or something along those lines? If so, you could run compute shader passes to pre-calculate the displacements and store them into a buffer to be read later by the vertex shader. The compute passes could be set up with work groups that distribute jointly over the vertices and the work elements (the exact distribution and mapping of compute threads would have to be experimented with). Each work group might, for instance, load a small chunk of vertices and a chunk of displacement elements into shared memory, calculate the displacements, then store them out to the per-vertex displacement buffer using atomic adds. Or, they might store out to various intermediate buffers (to avoid atomic contention) and have another set of compute shaders that sum up the intermediate values to obtain the final values. It would take some experimentation to see how to do it most efficiently, but you could likely get some big speedups here.


What exactly is the orthographic projection used by Matlab I would like to imitate the orthographic projection that Matlab uses by default:

Matlab View Projections

and

Matlab camproj

It seems similar to the "Trimetric" projection described here:

Wikipedia on Orthographic Projection

see the picture here:

Wikipedia picture - Comparison of projections

but I don't know whether they are definitely the same. Does anyone know the exact details of the Matlab projection ?

Thank you !

All of the above. If you look on matlabs page a little further down, it becomes apparent that matlab initializes a canvas (the screen), then looks for each pixel what is directly behind that screen. This gets rid of perspective. When you set the camera angle to 45 degrees down and 45 degrees left/right, you will get an implicit isometric projection. So really the "projection" just depends on your camera angle.

Sidenote: if you would want to keep a 3d perspective, you would need to draw the ray from the camera origin to the position on the canvas. That gives the ray the direction it needs to create perspective.


Radiosity normal map light baking I'm trying to implement radiosity normal maps from the old Valve paper:

Half-Life® 2 /
Valve Source™ Shading.pdf | valvesoftware.com

I've tried generating the light maps using Vray and 3dStudio max, by overriding the normals to point in these three directions:

It works to an extent, applying normal maps over walls and such makes them appear like they are light mapped and bumpy. It's when I set the normal map to (128,128,255) that i can't get the same result as if it were a regular light map and i see artifacts.

I'm not sure if understand at all how the basis is used to capture light, so i omitted the GI part and tried to bake just a directional light.

If i set a directional light at (-1,0,0) in the basis from the picture above, the first dot product (red arrow) will be less than 0, however both the green and the blue will get some value from that light.

Same way if i set it at (1,0,0) there will be some value greater than 0, and two less than.

This doesn't make sense, the directional light at this angle shouldn't contribute any light to this surface?

The white arrow represents the light dir to be baked. The red one is pretty affected by it, but then scaling it by 1/3 doesn't really help much.
It feels like it's missing some negative light (?).

Here it is with (1,1,1) normalized ^

The lightmap representation used in Valve's stuff, like any finite-storage representation of the surfaces response to light, is only approximate, and the error in the approximation is higher or lower in different scenarios.

Since it doesn't store the light in a direction tangent to the surface (where it would be exactly zero), you don't get an exact zero for this case. However, this isn't that important:

Normal maps generated from height maps will never yield a normal vector exactly perpendicular to the geometry, and tend not to be not that steep anyway.
The 3 generated lightmaps are normalized so that their sum is equal to the light for the "straight up" direction. This reduces directional contrast, but also eliminates light from the tangent direction.


What is the point of having integer-based draw routines in software rasterizer? I wonder why all the well known algorithms of drawing for example circles (bresenham, mid-point, etc) all use integer arithmetics? For example, here is a simple circle drawn with bresenham algorithm:

And this is what I get with a circle drawn using naive algorithm (with real numbers):

The bresenham's version just look terrible and feels laggy while the floating point version is much smoother. So why do we read everywhere that "integer" versions are preferred? The integer version is maybe faster but horrible when it comes to animating a moving shape. So the question is: should I use floating point version or bresenham's version in my little toy rasterizer?

Here's a more real world example:

Bresenham:

Floating point:

So what which version is the correct one? The floating point looks wobbly but smoother than Bresenham. Should I stick with Bresenham integer or use a floating point version smoother (or even a fixed point version)?

The following is really an assorted set of comments:

Why integer? Floating-point hardware is (in general) far more complex than integer and so on many (old) CPUs it (a) might not have been available (because of silicon budget) and/or (b) took considerably more clock cycles to execute than integer operations.

Re "Bresenham's" algorithm: IIRC there is a branch/decision per pixel. On old CPUs (with relatively little or no pipelining) this would have not been a penalty, but with modern, highly pipelined/superscalar  CPUs, each mispredicted branch will be detrimental.
Presumably (as I can't see your code) using floating-point removes that decision from the loop but, then again, you could use fixed-point (i.e. integer) to get the same effect.

Having said this, hardware rasterisation is probably using fixed-point (i.e. integer) maths when filling polygons as this (a) makes conforming to the OpenGL fill rules easier and (b) prevents some very nasty problems occuring with long/thin triangles.


MSAA performance with forward shading I have done some tests in OpenGL with multisampling, by specifying a multisample buffer as the default framebuffer. I used forward shading for rendering. From what I've observed the more primitives I have on the screen the higher the performance hit by multisampling. Is this because the built-in MSAA does multisampling in the fragment shader for each primitive we specify, even if its fragments are discarded because of depth testing? In order to fix this problem we could use deferred shading, but then we would have do multisampling ourselves.
Does this mean then that in practice for scenes with overlapping objects the built-in MSAA is pretty much never going to be used?

There is nothing surprising about this.
The biggest cost of multisampling is that you're rendering to larger buffers and therefore require more bandwidth to cover the same pixel-space area. This is especially true for doing depth tests, as the fragment's depth has to be computed and compared per-sample, not per-fragment. The more primitives you send, the more depth tests you're going to have, and therefore the more bandwidth you're going to use.
So if your shaders aren't doing much, your performance is going to be governed by framebuffer bandwidth.
Early depth tests are generally orthogonal to multisampling. But since multisampling typically executes the fragment shader at a lower frequency than the depth test, all of the depth samples that represent a fragment have to fail in order to cull the fragment itself. So I could imagine that some implementations turn off early tests for multisampling, but I rather doubt that this is the case.


Saving a mesh and textures into a single file I'm looking for a format where I could store a triangle mesh and multiple textures into a single file. Most formats only reference an external file for textures. I found that the FBX format should support this, but I need something with an open-source C++ library. And by single file I don't mean putting it into a single archive, I don't want users to have to deal with that.

I don't need anything fancy, no animation, no shading, nothing. Just triangles + textures. Ideally this would be a binary format (or at least the textures would be stored in binary inside the file). This should be some well supported format, so that tools exist to open it. I'm currently looking at X3D but I can't figure out if it can include the textures directly.

glTF is capable if embedding both geometry and texture data in a single file. It also has binary version (*.glb). There are several open-source savers/loaders, one of them being header-only tinygltf by Syoyo Fujita.


Unbound descriptor tables and descriptors for fat root signatures Unbound descriptor tables
If a D3D12_VERSIONED_ROOT_SIGNATURE_DESC defines N D3D12_ROOT_PARAMETERs (with ParameterType set to D3D12_ROOT_PARAMETER_TYPE_DESCRIPTOR_TABLE) that are each visible to a single (non-compute) shader stage, does each of these require a corresponding ID3D12GraphicsCommandList::SetGraphicsRootDescriptorTable invocation (with an allocated shader visible descriptor range) after binding the ID3D12RootSignature and ID3D12PipelineState, even if the latter does only use a subset of the (non-compute) shader stages (e.g., no geometry shader, etc.)? Stated differently, does ID3D12GraphicsCommandList::SetGraphicsRootDescriptorTable need to be invoked for root parameters associated with shader stages that are not defined for the ID3D12PipelineState but are part of the ID3D12RootSignature?
Unbound descriptors
If a shader uses say 2 SRVs, but up to 64 SRVs could be potentially bound for the ID3D12RootSignature, is it necessary that the 62 unused SRVs, which are part of the same shader visible descriptor range(s), are actually associated with an existing SRV of a resource that is still alive (which is not automatically guaranteed if the shader visible descriptor heaps are used in a ring buffer fashion, as initially the descriptors are unused and later on could be reused)? Or does one for example need to use an SRV of a dummy resource that is kept alive?

Everything is allowed to be left unbound / invalid / uninitialized as long as the shader doesn't try to look at it. However, if the shader does try to look at it, it could trigger a GPU crash / TDR.
In practice, it may be a good idea to explicitly clear out descriptors that you know aren't going to be valid: either setting them to a null descriptor, or pointing to a dummy resource. Loading/sampling from a null SRV/UAV descriptor in a descriptor table is defined to just return 0 and not crash. Likewise, stores to a null UAV descriptor are dropped on the floor without crashing.
However, this guarantee doesn't apply to descriptors directly in the root signature; trying to load/sample from a null root descriptor can crash the GPU. Likewise trying to read from a null descriptor table can crash. See the D3D12 functional spec for more.


How to implement Constructive Solid Geometry in ray tracing with implicit surfaces (spheres)? What I'm trying to do is to simulate refraction through biconcave lens described by spheres A, B, C where C is a sphere in between A and B. So far I've gathered that a good approach would be to use CSG when it comes to modeling such object. I'm failing to understand how to implement this though. There are mentions of using Interval Arithmetics but I don't understand how exactly are they supposed to help me.

I'm not sure what exactly you are asking but, IIRC, to do CSG with ray tracing, you maintain not just the closest intersection with an object, but a list of ordered pairs of [Inpoint, OutPoint] 'interval' distances. With a single sphere test (or any solid convex primitive for that matter), this list would have at most one [Inpoint, OutPoint] entry or is empty if there is a miss.

To implement CSG you then apply the binary operator to a pair of lists, which in turn means applying them to the entries in the lists in a manner akin to merge-sorting two lists.

For example, for intersection, if you had  [a,b] in one list and [c,d] in the other, compute  e=Max(a,c) f=Min(b,d).  If e > f there's no intersection else return the intersection, [e,f].

Does that help?


Project vertex onto plane What I have:

a plane given by its normal$\ n $ and a point on the plane$\ p $.
a 3D-point$\ v $.
a direction$\ d$.

What I need:

the projection of$\ v$ along$\ d$ onto the plane.

How can I calculate this? Thank you!

P.S.: I need to implement that in GLSL, in case this is of any information. I would be fine with the formula so that I can work out the implementation myself, anyways. :-)

To answer your question we just need to write it as linear algebra equations and solve them. Although your question doesn't state it, I assume that $v$ and $d$ are unit vectors. Let's call the projected point $x$.

First, because the projected point is in the direction $d$, we can write:
$$\vec{vx} = \lVert\vec{vx}\rVert d $$

Second, because $p$ and $x$ are on the plane and $n$ is the plane normal, we can write:
$$\vec{vx}\cdot n = \vec{vp}\cdot n$$

We can now work on the equation until we get a definition for $\vec{vx}$:
$$\begin{align}
\vec{vx}\cdot n & = \vec{vp}\cdot n \\
\lVert\vec{vx}\rVert d\cdot n & = \vec{vp}\cdot n \\
\lVert\vec{vx}\rVert & = \frac{\vec{vp}\cdot n}{d\cdot n} \\
\vec{vx} & = \frac{\vec{vp}\cdot n}{d\cdot n}d \\
\end{align}$$

Or written differently:
$$x = v + \frac{(p-v)\cdot n}{d\cdot n}d$$

The result is undefined when the scalar product $d \cdot v$ is $0$, which happens when $d$ and $n$ are orthogonal, when $d=0$, or when $n=0$. The first case means $d$ is parallel to the plane and the projection doesn't have a point solution, and the two other cases mean that either the plane or the projection are not defined.


How do you load multiple textures into an array texture with OpenGL? I have been reading the OpenGL documentation but it is not clear to me how to achieve the following.

Say we have an array of strings. Each string in the array is a valid relative path to an image file (.png, .jpeg...)

We have a method that can read and store into a GLubyte array the image information of each file.

We want to allocate the needed memory for the textures, and save said information into a texture array. However there's no guarantee that the textures are the same dimensions.

The memory layout of a (2D) array texture is pretty similar to a 3D texture, with the individual image layers stored one after the other in a big 3D-array of pixels. So that's also how you set them. You either load each individual image into a big GLubyte array one after the other and set it with glTex(Sub)Image3D or you load each image into its own GLubyte array and transmit that to the texture with glTexSubImage3D one after the other (or any other more complex process involving buffers or whatever, but you get the idea).
So much to the theory. The problem here is the part where you say

However there's no guarantee that the textures are the same dimensions.

This contradicts with how array textures work. As the corresponding documentation you link to says:

An Array Texture is a Texture where each mipmap level contains an array of images of the same size.

So the individual layers of an array texture have to be the same size. Simplifyingly said, an array texture is really just a 3D texture without filtering along the z-axis. So you can't get different-sized textures into such a regular box of pixels.
There's a few options you have here, though:

You could scale every image to a common size, depending on how different they really are and what rescaling means to your quality and/or memory demands.

You could just drop using array textures and implement whatever you want to do with normal 2D textures and a likely more complicated process on the CPU side.

You could use Bindless Textures. This is a rather modern non-core feature (only usable through extensions yet) that is really flexible and allows you to access textures in a shader by using a unique GPU handle (a 64-bit ID, so to say). This allows you to use whatever and how many textures you want in a shader, depending on some arbitrarily input value (even a vertex attribute).
In this case you wouldn't just a have access to a continuous array of N textures, rather than the wealth of all the textures you have allocated. You would just use normal independent 2D textures and use their respective texture handles rather than an array index. Of course this comes with a few limitations and intricacies, too. But more about that in the corresponding documentation.


How to generate a 360 degre video Using my raytracing engine, I'd like to generate a 360 degree video which could then be uploaded on Youtube.
By looking on the internet, I couldn't find any specific details about how to do so. I am using FFMPEG to generate short movies.
I saw something about stitching but that didn't really help me that much.

Could you provide me some hints, please ?

YouTube Help: Upload 360-degree videos

  We recommend uploading  360 videos (equirectangular format with a 2:1 aspect ratio) at a resolution of 7168x3584 or higher, up to 8192x4096.

That means the format uses Equirectangular projection for capturing the view from all directions to a normal video format with a 2:1 aspect ratio. The projection should translate nicely to a raytracing engine with a simple mapping from pixel coordinates to the ray direction using the formula in the wiki article.


Could some give an explanation or hint about this kind of equation? $\left(- \sqrt{X^{2} + Y^{2}} + 1\right) \cos{\left (2 \pi X + \phi \right )}$ This is a screen shot from an animation generated by a matplotlib example

the key part in the code is

    R = 1 - np.sqrt(X**2 + Y**2)
    Z = np.cos(2 * np.pi * X + phi) * R

corresponding equation is

$\left(- \sqrt{X^{2} + Y^{2}} + 1\right) \cos{\left (2 \pi X + \phi \right )}$

Could some give an explanation or hint about this kind of equation?

Is there a name of this type of graphics?

usually cosine/sine could generate something like a (half) circle, what does R part do?

The R part generates a cone where the point is at (0, 0, 1) and it spreads out below that. It meets the x-y plane at the unit circle:

The cos component defines an extruded cosine wave along the X-axis:

So the final equation takes the cosine wave and multiplies its amplitude by the cone. It will have full amplitude at the origin, and decrease to 0 at the unit circle on the x-y plane. Past that it becomes negative:

The phi component shifts the sine wave forward or backward along the x axis.


Subdivide a triangle along its UVs I'm looking into a problem that first occured very trivial to me, but i got stuck and it's becoming a major issue right now. I'd like to subdivide a triangle by its given UVs, e.g. if the UVs are going from -n...+m or if they are greater than 1. So for example if i have a U coordinate from -1.5 ... 4 i'd like to subdivide at -1.0, 0.0, 1.0, 2.0, 3.0. Here's a visualization of the polygons that can be generated. Triangulation is trivial of course.

My idea was to subdivide each edge separately for U and V and then find intersections and use these intersections to spawn triangles. However, i can't even find the rule how each line is constructed. Maybe someone can shed some light?

Thanks!

You can use barycentric coordinates to calculate points inside the triangle with a determinate value for uv.

The process is easy =>

Let's say that the UV coordinates of each vertex of the triangle are:

vertex 0 => u0,v0

vertex 1 => u1,v1

vertex 2 => u2,v2

A point inside the triangle has UV coordinates value expressed in function of its barycentric coordinates:

u coord = p0 * u0 + p1 * u1 + p2 * u2

v coord = p0 * v0 + p1 * v1 + p2 * v2

where p0,p1,p2 are the barycentric coordinates of this point.

As barycentric coordinates has the property:

p0 + p1 + p2 = 1

you can calculate the barycentric coordinates of a point with a specific value for UV just by solving these equations. I mean, for example, you want to know which point inside the triangle has

UV = (1,2)

To calculate such a point just do:

1 = p0 * u0 + p1 * u1 + p2 * u2

2 = p0 * v0 + p1 * v1 + p2 * v2

p0 + p1 + p2 = 1

as you know the values for (u0,v0), (u1,v1) and (u2,v2),  you can easily calculate the barycentric coordinates of this point, (p0, p1, p2).

Once you have the barycentric coordinates, you can calculate the coordinates (px,py,pz) of the point:

(px,py,pz) = p0 * vertex0 coordinates + p1 * vertex 1 coordinates + p2 * vertex 2 coordinates


Errors on Compiling my first program on OpenGL on Ubuntu I am trying to run the following program on ubuntu 15.04. However on typing "g++ pgm1.cpp -lglut"
I am getting following errors

/usr/bin/ld: /tmp/cc9aXqhZ.o: undefined reference to symbol 'glClear'

/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command line

Though I am familiar with C programming in Codeblocks and DevC++, this is the first time I am working on Ubuntu and OpenGL. I installed ubuntu and files related to OpenGL based on information available on the net. The sample program too is from the internet. I would request help in getting the program run. Thanks.

# include "GL/freeglut.h"
# include "GL/gl.h"
# include <GL/glut.h>

void init(void)
{
glClearColor(0.0f,0.0f,1.0f,1.0f);
}
void display (void)
{
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}
int main (int argc, char** argv)
{
glutInit(&argc,argv);
glutInitDisplayMode(GLUT_SINGLE|GLUT_RGB);
glutCreateWindow("A Blank Window");
init();
glutDisplayFunc(display);
glutMainLoop();
return 0;
}

You need to link with the OpenGL library. Try adding -lgl to the compilation command.


Why are BRDF and the lighting uncorrelated? In relation to this question, in the accepted answer I have a trivial question probably.

W.r.t. the following integral

$$
L_o(x\rightarrow \Theta) = \int_{\Omega_x} f_r(x,\Psi\rightarrow\Theta)L_i(x\leftarrow \Psi) cos(N_x,\Psi)d\omega_{\Psi}
$$

in the accepted answer, one of the comments it is stated that $f_r(l,v) = f_r(x,\Psi\rightarrow\Theta)$ and $L_i(l) = L(x\leftarrow \Psi)$ are not correlated. As usual... I wanna understand why... My reference on this subject is this book. In such book the brdf $f_r(l,v)$ is defined as

$$
f_r(x,\Psi \rightarrow \Theta) = \frac{dL(x \rightarrow \Theta)}{dE(x \leftarrow \Psi)} = \frac{dL(x \rightarrow \Theta)}{L(x\leftarrow\Psi)cos(N_x,\Psi) d\omega_\Psi},
$$

From the last equation I can see that the two are actually related, unless there's something I'm missing. Why are they not correlated?

A note about the notation used.

$L(x\rightarrow\Theta)$ : this is the radiance from $x$ toward direction $\Theta$
$f_r(x,\Psi\rightarrow\Theta)$ is the BRDF coming from direction $\Psi$ in $x$ and exiting in direction $\Theta$
$L(x\leftarrow\Psi)$ : radiance from direction $\Psi$ toward $x$

When rendering an image you are trying to find the outgoing light from a point into the camera $L(x \rightarrow \Theta$).

To do this you solve "The rendering equation", which means you integrate the product of the brdf and the incoming light for every incoming direction.

$$L(x\rightarrow\Theta )=\int_\Omega f_r(x, \omega\rightarrow\Theta)\cdot L(x\leftarrow\omega)d\omega$$

Since you don't have the outgoing light you cannot use the definition of the brdf to calculate it.

$$f_r(x,\omega\rightarrow\Theta )=\frac{L(x\rightarrow\Theta)}{E(x\leftarrow\omega)}$$

Instead, you use a formula to compute $f_r(x,\omega\rightarrow\Theta )$ and some operation to find the incoming light $L(x\leftarrow\omega)$ (a raytrace, a env map sample, etc.), and use those to compute the outgoing light $L(x\rightarrow\Theta)$.

These two calculations are usually done in a completely separate way. So there is no way the incoming light can effect the brdf in any way.


At which stage of the pipeline is the projection transform applied? I've found a site that provides an overview of the OpenGL pipeline:

Rendering pipeline overview

Now in the 3th phase (vertex processing) it says that after the transform feedback, there is the primitive clipping. If I am not mistaken, the primitive clipping must occur after that the vertices are multiplied by the projection matrix, otherwise it's impossible to determine if the primitives are inside or outside the view volume defined with glFrustum().

I know that in a typical GLSL shader you need to apply the modelview matrix to the vertices, so that you obtain a vertex in eye coordinates. So if I am not mistaken, at the end of the vertex shader you don't have vertices defined in clip coordinates yet. But this makes me think: where is the projection matrix applied? it seems like it's missing in this pipeline overview.

I know that in a typical GLSL shader you need to apply the modelview matrix to the vertices, so that you obtain a vertex in eye coordinates.

This is not quite correct, you need to apply the modelviewprojection matrix and thus transform your vertices into Clip Space Coordinates.
You can apply the ModelView Matrix in certain instances, e.g. if you want to calculate light in Eye Space. However, the gl_Position will then still not use the ModelView but the ModelViewProjection Matrix and your light/whatever- position will use the ModelView Matrix and be transferred to the fragment shader via the out variables.

For a more detailed discussion, you can look into the comments on this question, I had to be corrected about that myself (since not all literature is clear/correct about Normalized Device Space and Clip Space).


Does a sphere projected into 2D space always result in an ellipse? My intuition has always been that when any sphere is projected into 2D space that the result will always mathematically be an ellipse (or a circle in degenerate cases).

In the past when I was actively doing my own graphics programming and brought this up with other people they were adamant that I was wrong. If I recall correctly they believed the result could be something vaguely "egg shaped".

Who was correct?

Since there is already one answer submitted, I don't wish to totally change my question but I realize I left out important details due to losing familiarity with the field over the years.

I intended to ask specifically about perspective projection where the projection is a linear application.

The other projections are of course interesting for many uses so I wouldn't want them removed at this point. But it would be great if answers could have perspective projection as their most prominent section.

Assuming a perspective projection and a view point external to the sphere, then the 'boundary' formed by the view point and the circle on the sphere which forms the horizon WRT the view point, will be a cone.

Doing a perspective projection (onto a plane) is then equivalent to intersecting this cone with the plane which thus produces a conic section. FYI the four, non-degenerate, cases are shown in this image from Wikipedia

An ellipse/circle is thus a possibility, but not the only one - unbounded parabolas or hyperbolas (and I guess if the plane passes through the eye, even degenerate cases ) are possible.


Real time image based lighting for arbitrary BRDFs coordinate alignment I was trying to understand how real-time illumination happens with image-based lighting.

I understood that importance of representing the Environment Map and BRDF in spherical harmonics. Because both of them orthonormal basis function so that the illumination integral becomes a matter of dot product of coefficients.

But before that,

Why is environment map in the global frame and BRDF in  the local frame?

Edit 1: To help more this is the paper Fast, Arbitrary BRDF Shading

The surface reflectance of a BRDF function doesn't depend on orientation or position of the surface in the world space (except for the view vector) but is defined relatively to the surface normal (or tangent space in case of anisotropic BRDF) so it should be defined in local space. Think of it as a hemispherical 2D function fixed to a point on the surface of an object that moves and rotates with the object.

Environment map on the other hand defines luminance from given direction in the world space so it is defined in that space.

To perform the convolution of these two functions you then have to either transform BRDF to world space or environment map to local space.

It's common to transform surface normal/tangent space to the world space and perform lighting calculations in that space. However, if you plan to do define BRDF with spherical harmonics, you might want to consider hemispherical harmonics for better frequency response and transform lighting from world space to the local space. Overall with SH/HSH you can only reproduce fairly low-frequency lighting (i.e. rough surfaces), so they may not be able to render as versatile surfaces as you wish.


Why are texture coordinates often called UVs? Is there some historical reason texture coordinates are often called UVs? I get that vertex positions are x, y, z but even OpenGL has TEXTURE_WRAP_S and TEXTURE_WRAP_T and GLSL has aliases so if texture coord is in a vec you can access it with

someVec.st

but not

someVec.uv  (these would be the 3rd and 4th elements of the vector)

And yet pretty much every modeling package calls them UVs Maya, Blender, Unity, Unreal, 3dsmax

Where does the term UVs come from? Is this a known part of computer graphics history or is the reason they are called UVs lost in pixels of cg time?

This is not a definitive answer, but it is generally accepted that Ed Catmull introduced Texture Mapping in his 1974 thesis, "A SUBDIVISION ALGORITHM FOR COMPUTER DISPLAY OF CURVED SURFACES"
In that, he uses (U,V) to access the image data (see the page labeled 36 in the above)

MAPPING
Photographs, drawings, or any picture can be mapped onto bivariate patches. This
is one of the most interesting consequences of the patch splitting algorithm. It
gives a method for putting texture, drawings, or photographs onto surfaces....
...If a photograph is scanned in at a resolution of x times y then every
element can be referenced by u·x and v·y where 0<=u,v<=1. In general, one could think of the intensity as a function l(u,v) where I references a picture.

I believe this thesis also introduced the concept of the Z-Buffer (Page 32)


Rotating an Object Around an Axis I have a circular shape object, which I want to rotate like a fan along it's own axis.

I can change the rotation in any direction i.e. dx, dy, dz using my transformation matrix.

The following it's the code:

 Matrix4f matrix = new Matrix4f();
 matrix.setIdentity();
 Matrix4f.translate(translation, matrix, matrix);
 Matrix4f.rotate((float) Math.toRadians(rx), new Vector3f(1,0,0), matrix, matrix);
 Matrix4f.rotate((float) Math.toRadians(ry), new Vector3f(0,1,0), matrix, matrix);
 Matrix4f.rotate((float) Math.toRadians(rz), new Vector3f(0,0,1), matrix, matrix);
 Matrix4f.scale(new Vector3f(scale,scale,scale), matrix, matrix);

My vertex code:

 vec4 worldPosition = transformationMatrix * vec4(position,1.0);
 vec4 positionRelativeToCam = viewMatrix*worldPosition;
 gl_Position = projectionMatrix *positionRelativeToCam;

Main Game Loop:

 Object.increaseRotation(dxf,dyf,dzf);

But, it's not rotating along it's own axis. What am I missing here? I want something like this. Please Help

Instead of "stacking" or overwriting these transformations on one matrix You may try doing that using matrix multiplication:

Matrix4f translate = translate(translation,  new Matrix4F() /*identity*/);
Matrix4f rotateX = rotate((float) Math.toRadians(rx), new Vector3f(1,0,0), new Matrix4F());
Matrix4f scale = scale(new Vector3f(scale,scale,scale), new Matrix4F());

Matrix4f transformation = translate*rotateX*scale;


constant pixel width for any scale I have a standard 3d camera/projection/model setup that renders rectangles with a WebGL shader.

Users can zoom out and fly anywhere.

I want to make sure that regardless of the scale, width of the rendered rectangles is a constant value (e.g. 2 pixels).

What is the most efficient way to do so?

This is very similar to SVG's non-scaling-stroke vector effect: https://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke

Found a solution.

In the vertex shader I project position from model to the clip-space, then from clip-space to screen space, adjust the width in screen pixels, and the project back to clip-space, which ultimately becomes gl_Position value.


What wavelengths(dominant) the primary RGB colors are supposed to be in sRGB color space in nanometers? The Context
I am exploring the idea of making a DIY spectrometer(and colorimeter) for testing various material samples for interior visualization. It's sort of a hobby project for my curiosity and pleasure that might end up useful for my actual work with CG.
The Question
I am struggling to find a trustworthy information source for light wavelengths sRGB color space primaries are supposed to be. They are supposed to be the same as in REC.709 as far as I understand. Are the actual wavelengths of sRGB RGB primaries defined and if so what are they in nanometers?

The primaries of sRGB are not pure wavelengths, they are color mixtures. Their true definition is in terms of CIE chromaticity coordinates. That said, for sRGB, the red primary is close-ish to 610nm, green is very roughly 555nm, and blue is close-ish to 465nm.
The Rec. 2020 RGB space, by the way, is actually defined using pure wavelengths for the primaries: R=630nm, G=532nm, and B=467nm.