Transformation Matrices Consider the following problem and its answer:

  Given 3 points in 3D: $A=(A_x,A_y,A_z);   B=(B_x,B_y,B_z)  ;    C=(C_x,C_y,C_z)$

  Find the transformation matrix (in homogeneous coordinates) that performs a reflection around the plane spanned by the given 3 points.

  Answer:

Can anyone explain why this answer is correct?
Shouldn't normalization be performed by dividing by $|C-A|$ and $|B-A|$ instead of $|AC|$ and $|AB|$?
Wouldn't we want to reflect on $uv$ plane (and then the -1 would be one row below)?
I saw a similar question where you had to rotate around a vector and not a surface, and then we created $v$ with $v=u\times(0,0,1)^T$ (the vector was $P_1-P_0$ and $u=\dfrac{P_1-P_0}{|P_1-P_0|}$. What's the difference?
In general, what is the rule of thumb when finding the $u,v,z$ cartesian system of a given object (plane, line, point etc)?

The answer in the screenshot is wrong on two counts. First, you're correct that in the middle matrix the −1 should be on the third row, not the second. The other error is that the $u, v$ basis vectors are normalized, but not orthogonalized, so $M$ is not in general a rotation matrix; therefore its inverse is not simply its transpose. (The reflection doesn't actually need an orthonormal basis, so you could fix the answer either way: by using the full inverse for $M$, or by fully orthonormalizing $u$ and $v$.)

The rule of thumb for setting up a local coordinate system (I assume orthonormal) for a given object is to set some of the axes to be lined up with the object, then choose arbitrary perpendicular vectors for any remaining axes.

For a point, there's nothing to line up with, so you can use any arbitrary axes.
For a line, you line up the $u$ axis with the line, then there's nothing to constrain the $v$ axis, so you can choose any arbitrary vector perpendicular to $u$. That's what the $v=u\times(0,0,1)^T$ thing was getting at: it's a convenient formula to get some vector perpendicular to $u$ if you don't otherwise care what direction it is. Except that this won't work if $u$ happens to be parallel to the z-axis (the cross product returns zero then), so you actually need to detect that and switch to a different formula, such as $v=u\times(1,0,0)^T$, in that case.
For a plane, you line up the $u$ and $v$ axes with the plane. So, you can pick any arbitrary $u$ that lies in the plane, then find a $v$ that lies in the plane and is perpendicular to $u$.

Addendum on orthonormalization

Suppose you have a couple of 3D vectors $u, v$ that are non-parallel (linearly independent) but otherwise arbitrary, and you want to generate a 3D orthonormal basis $u', v', w'$ from them. There are two equivalent ways to do it.

Use the Gram–Schmidt process. This works as follows: first, normalize $u$. Then, for each additional vector, subtract off its projection onto the previous vectors, and normalize what's left over. For the 3D case this looks like:
$$ \begin{aligned}
u' &= \text{normalize}(u) = \frac{u}{|u|} \\
v' &= \text{normalize} \bigl( v - (u' \cdot v)u' \bigr) \\
w' &= u' \times v'
\end{aligned} $$
Note that the notation $(u' \cdot v)u'$ means take the dot product of $u'$ with $v$ (giving a scalar), then multiply that scalar by $u'$. This gives the vector component of $v$ that is parallel to $u'$. When this is subtracted from $v$, the remaining component is perpendicular to $u'$.

Finally, $w'$ is set to the cross product of $u'$ and $v'$ to ensure the basis is right-handed. Since $u', v'$ are already orthonormal, we don't need to normalize $w'$—it comes out already normalized. (This isn't strictly part of the Gram–Schmidt process.)

By the way, the Gram–Schmidt process works for making an orthonormal basis in any number of dimensions, not just two or three.
The other way, which only works in 3D, is to use cross products.
$$ \begin{aligned}
u' &= \text{normalize}(u) \\
w' &= \text{normalize}(u' \times v) \\
v' &= w' \times u'
\end{aligned} $$
Here, $w'$ has to be normalized because $u'$ and $v$ are not orthonormal. But then $u'$ and $w'$ are orthonormal, so we can calculate $v'$ from them without a normalize. This gives the same results as the previous process, so it's up to you which you prefer to use.


Why is the image from the CUDA version not as sharp as the CPU version? I am extending Roger Allen's Ray Tracing in One Weekend in CUDA (and also here) by following Peter Shirley's Ray Tracing: The Next Week; specifically Image Texture Mapping.
The image I obtain from CUDA is not as sharp as the CPU version. Shirley's book uses double and Allen restricts to float but could that be the only reason?
The texture source for both is a 24 bit depth jpeg file.
In both cases 100x sampling per pixel used for antialiasing.
Is there anything to be done in the kernel to improve the image quality?
    class imageTextureX :public textureX {
public:
    __device__ imageTextureX(uint32_t width, uint32_t height, cudaTextureObject_t textureObject) :_width(width), _height(height), _textureObj(textureObject) {}
    __forceinline__ __device__  vec3 value(float u, float v, const vec3& p) const override {
        //Flip Y-Coordinate;
        v = 1.0f - v;
        //De-normalize coordinate(s)
        uint32_t X = u * _width;
        //Re-normalize
        constexpr float pixelOffset{ 0.5f };
        const float denominator = 1.0f / (float)(3 * _width);
        u = (float)(3 * X + pixelOffset);

        vec3 colorVal;
        colorVal.e[0] = (float)tex2D<uint8_t>(_textureObj, u++ * denominator, v);
        colorVal.e[1] = (float)tex2D<uint8_t>(_textureObj, u++ * denominator, v);
        colorVal.e[2] = (float)tex2D<uint8_t>(_textureObj, u * denominator, v);
        return colorVal / 255.0f;
    }
private:
    cudaTextureObject_t _textureObj;
    uint32_t _width;
    uint32_t _height;
};

Texture definition code
//Load Texture Image from Disk
    cudaArray* cuArray;
    cudaTextureObject_t textureObject;
    int32_t textureWidth, textureHeight;
    {
        Timer tim("Prepare Image Texture");
        const static uint32_t bytesPerPixel{ 3u };
        uint8_t* pHostData;
        uint32_t bytesPerScanline;
        cudaChannelFormatDesc channelFormatDesc;
        cudaResourceDesc  resourceDesc{};
        cudaTextureDesc textureDesc{};
        int32_t componentsPerPixel = bytesPerPixel;
        pHostData = stbi_load(textureFilename.c_str(), &textureWidth, &textureHeight, &componentsPerPixel, componentsPerPixel);
        if (nullptr == pHostData) {
            std::cerr << "ERROR: Could not load texture image file '" << textureFilename << std::endl;
            return;
        }
        bytesPerScanline = bytesPerPixel * textureWidth;

        channelFormatDesc = cudaCreateChannelDesc(8, 0, 0, 0, cudaChannelFormatKindUnsigned);
        checkCudaErrors(cudaMallocArray(&cuArray, &channelFormatDesc, bytesPerScanline, textureHeight));
        checkCudaErrors(cudaMemcpyToArray(cuArray, 0, 0, pHostData, bytesPerScanline * textureHeight * sizeof(uint8_t), cudaMemcpyHostToDevice));

        resourceDesc.resType = cudaResourceTypeArray;
        resourceDesc.res.array.array = cuArray;

        textureDesc.normalizedCoords = true;
        textureDesc.filterMode = cudaFilterModePoint;
        textureDesc.addressMode[0] = cudaAddressModeWrap;
        textureDesc.addressMode[1] = cudaAddressModeWrap;
        textureDesc.readMode = cudaReadModeElementType;
        checkCudaErrors(cudaCreateTextureObject(&textureObject, &resourceDesc, &textureDesc, nullptr));
        STBI_FREE(pHostData);
    }

The output images were ppm and converted to pgm for upload purposes

If you look closely at the edge of the sphere, in the first image it is sharp, and in the second image it's blurry, blending into the background color. This suggests to me that it's not the texture, but the ray distribution on the image plane that's the issue. The second image might be distributing rays over a larger area per pixel, for instance by using a wider AA filter, or a wider lens aperture (defocus blur).


How is an ICC profile embedded or built into an image? If I were to analyze or change an ICC profile embedded in an image, how should I proceed?

I'd also be glad to understand how an "end-user" is able to create these with a tristimulus colorimeter or a spectrophotometer and if/how this new profile can be added to a color capturing device (i.e. a camera).

My curiosity comes from images that were taken by a professional photographer. When I open them in GIMP, there's a pop-up referring "there is an embedded ICC profile" and if I "would like to convert the image to RGB (sRGB built-in)". I always convert all of them before using them, since the colors are slightly improved.

This is the image as it was provided by the photographer:

And this is after the embedded ICC profile was applied:

I realized that littlecms, suggested by joojaa in a comment above is very complete in dealing with the ICC profiles.

I did a few tests in their color translator program with different destination color spaces and the differences are great as you can see:

Original

sRGB-like

adobeRGB1998 (it seems it's the original color space)

appleRGB

And the most desirable results in my case are within the ProPhotoRGB color space:

linearProPhotoRGB

All of the above were following an automatic rendering intent but other intents bring slight variations (samples applied together with linearProPhotoRGB destination color space):

Absolute Colorimetric

Legacy Unadapted Absolute Colorimetric

I also realized that GIMP was actually restoring the original profile (not the opposite as I thought, i.e. instead of applying an embedded ICC profile, it was taking it off) and with this littlecms, now it does seem much simpler to "translate" color spaces than I thought.


What is ambient occlusion? Ambient occlusion "is a shading and rendering technique used to calculate how exposed each point in a scene is to ambient lighting.

Ambient lighting is regarding to What is ambient lighting?:

  ... lighting to be constant and independent from position: that's ambient
  lighting.

If ambient lighting has no fixed position, how can points then be more or less exposed to it? Ambient lighting is "shining by a constant amount in all directions." So if the light is coming from all directions, every point should be exposed by the same factor to the ambient lighting.

Your point is correct when applied to ambient lighting as an approximation technique. This crude approach does indeed give the same lighting level to all surfaces regardless of their surroundings.

However, ambient occlusion is a different (less crude) approach, that models how the light levels in a real scene vary depending on how much reflected light can reach a surface. The confusion is due to two very different approaches having similar names.

Ambient occlusion is a much better approximation of what in real life is described as ambient light - light that arrives from the background rather than directly from a light source.

  If ambient lighting has no fixed position, how can points then be more or less exposed to it?

When used in the context of ambient occlusion, the term "ambient lighting" still means background light approximated as being the same in all directions, but the surface is lit based on how many of those directions are not occluded by objects in the scene.

This gives subtly varying light levels that give much more realistic images than with a single level of ambient lighting. This gives the effects seen in real life such as the corners of a room being slightly darker than elsewhere.


What subdivision algorithm advances have occurred since Catmull-Clark? In 1978 Edwin Catmull and Jim Clark defined the recursive subdivision process that bears their names, and although those principles are applicable still today, what advances have occurred as far as optimization and accuracy?

More of an extended comment than an answer:

What do you mean by "optimization and accuracy"? Do you mean computational efficiency for some particular application, like ray tracing, physical simulation, CAD modeling, ....?

Note that the idea of "accuracy" for a subdivision scheme is not well-posed. Different schemes will have different limit surfaces, but there is no canonical way of declaring one limit surface to be "more accurate" than any another. One can pose some constraints on the type of limit surface one desires, but these constraints are again very application-dependent: one person might ask for $G^n$ everywhere, the next will complain because this precludes preserving sharp creases.

Catmull-Clark (and Loop, for triangle meshes) remains popular because of its simplicity, which in many cases outweigh its weaknesses (no handling of sharp features; loss of regularity at extraordinary vertices). Countless alternative schemes (which may or may not be improvements over Catmull-Clark, depending on the specific application) have been proposed -- if you have a specific application in mind, with specific requirements, we may be better able to help you navigate your options.


An algorithms for covering a 2d polygon with a predetermined number of rectangles? I am looking for an algorithm that is able to cover with non-overlapping rectangles in a pre-defined number and minimum area a generic 2d-polygon.

Polygons are usually free-hand draws, so they can be of really any shape and number of vertexes and having holes.

I found different articles like: https://en.wikipedia.org/wiki/Polygon_covering

but I am not sure if it is what I am looking for. Can you point me to some source code or something readable for a non-graphic guy?

(Not an answer but my comments are too large for a "comment")

This is more computational geometry than graphics. First of all, it would help if you could give an example (a drawing) which describes your input and your expected output. Are you working with low count polygons, or precise coastal maps? Do you want a real-time solution or is it off-line? It could be a big help if you would describe what you want to obtain with these rectangles covering your polygon. Also, what are your needs concerning the solution(s), for instance do you want the area of the rectangles to be as least as possible?

Intrinsically this is NP-hard, this means there is a vast amount of possible solutions when the size of input data rises. Think of a circle covered by a square divided in two not necessarily equally sized rectangles. There is an infinite set of solutions already there concerning where they are split. Then just think of the amount of possible solutions for optimally packing a star shape into five or so rectangles, it's simply "not possible" if you want it done on a computer, in finite time.

So, you will be looking for a heuristic, that gives you a solution but not necessarily an optimal one. This means that you need to figure out what you want to accept being a solution.

Edit: One variant of the problem at hand, that I didn't think of, could be that you already have N rectangles (size is given up front, they might be of the same size) that you wish to cover a polygon with. It's not simpler, also it could be impossible, for instance if the total area of the rectangles is less than the area of the polygon. So: Please describe your problem at bit more :)


Can I get numeric data from a color map? In my class I often need to work with color map images. I would show the image and try to make inferences/observations about different subjects. Often times I need to actually quantify some aspects, but it is always very approximate and somehow vague because the images are provided "as is" and I do not necessarily know their content a priori.

Let's imagine I'm working with two images (*). Is it possible to indicate the computer "learn" the color scale bar so I can click at any point in the map and get the value of altitude at that point? Image 1 is a discrete color scale bar, while Image 2 has a continuous color mapping. I included both examples because maybe there are differences in the approach of how to do this.

So, is there a software/way to do this? Preferably open source. I tried ImageJ and couldn't come up with a decent solution.

Image 1:

Image 2:

As you can see, the color scale is part of the image in all cases.

(*) I do not own any of these images, just examples I found online to illustrate my point.

I don't know of any software that could do this for you. However, it should be possible to reverse engineer the colour map to create a kind of look-up table structure.

First, take a one pixel wide column (or row) of the colour map and store this as an array of colour values. Then, create a secondary array, for the data/altitude values, of the same length. Try to mark to the best of you ability the marked values of the colour map on this second array. A simple solution would be to also take a pixel wide column (or row) featuring the markings of the colour map to get the exact one-to-one pixel correspondence. Now you have a secondary array containing the marked off values and the rest of the values can be filled in by figuring out the step size of the colour map. The step size would be the difference in absolute value between subsequent markings divided by the number of pixels between these same markings.

Now when you read a colour from the mapped figure you can look up the colour in the colour array and use the index of this value to look up the altitude in the secondary array.


Understanding the near clipping plane I don't understand something about the near clipping plane. It's there to avoid the division by $0$ but when we compute the pixel coordinates, we just need to multiply by the clipping plane to clip the object?

For example in this code, from https://www.scratchapixel.com/lessons/3d-basic-rendering/3d-viewing-pinhole-camera/implementing-virtual-pinhole-camera

pScreen.x = pCamera.x / -pCamera.z * near;
pScreen.y = pCamera.y / -pCamera.z * near;

Vec2f pNDC;
pNDC.x = (pScreen.x + r) / (2 * r);
pNDC.y = (pScreen.y + t) / (2 * t);
pRaster.x = (int)(pNDC.x * imageWidth);
pRaster.y = (int)((1 - pNDC.y) * imageHeight);

bool visible = true;
if (pScreen.x < l || pScreen.x > r || pScreen.y < b || pScreen.y > t)
    visible = false;

return visible;

When do they actually discard points that have a z component smaller than the near clipping plane? They just discard those which have a x and y coordinate not visible to the screen.

When do they actually discard points that have a z component smaller than the near clipping plane?

For actual rendering hardware, they don't. Clipping happens in clip space, before the NDC transform. "Points" outside of the clipping volume are never seen by the rasterizer (in theory, at least. In practice, guard-band clipping is often used to minimize the need for clipping against the sizes).

The renderer presented at that site doesn't appear to do clipping at all. It has an approximation of what would be clipped, but it doesn't actually do the clipping.


Vector Math for Raytracer So i am working through the book "Raytracing in one weekend".
At the point where i am at we want to check if a ray hits a sphere.
For that we have the equation:

dot((A + t*B - C),(A + t*B - C)) = R*R

Where A + t*B is a point on the ray, with A the start, B the direction and t how far along we went on the ray.

To solve this the author transformed the equation to:

t*t*dot(B,B) + 2*t*dot(A-C,A-C) + dot(C,C) - R*R = 0

Now i just can not understand how this transformation comes about.
Simply multiplying this out seems to give a way different result.

Is there some kind of vector math i'm missing here?

I think there might be a misprinting in the book. I am getting this

$((A-C) + tB)\cdot((A-C) + tB) = R\cdot R$

Let  A-C = Y

$(Y + tB)\cdot(Y + tB) = R\cdot R$

$Y\cdot Y + Y\cdot tB + tB\cdot Y + t^2B\cdot B = R\cdot R$

Substituting back

$(A-C)\cdot(A-C) + 2t * B\cdot(A-C) + t^2B\cdot B = R\cdot R$


Changing sin frequency smoothly in shader In my vertex shader I am using a sin function to offset vertices. But as I change the frequency of my sin function I notice some "flickering" or "jumps". I guess that this comes from the fact that the phase is not synchronised any more.

float s = sin(frequency * _Time);

Is there a way to avoid those flickering effect while changing the frequency ?

You could go the calculus way and have an explicit rate of change that is outside your shader

float frequency = getFrequency();
sineTime += frequency * deltaTime;

(sineTime could be a float that is scoped right outside of your render loop, so that it retains its value)

And if you pass sineTime into your shader you can just do

float s = sin(sineTime);


What's wrong with my computation of the intersection of a ray with a sphere I am learning GLSL and trying to raytrace a sphere.

Here is a fragment shader. It correctly discards fragments which are not on the sphere, but when I try to calculate the point of intersection (and hence, the normal), I get nonsense.

Here's the fragment shader.

#version 300 es
precision mediump float;
out mediump vec4 out_colour;

in  mediump vec3 X;      // intersection of ray with polygon

uniform mediump vec3 C;  // camera position
uniform mediump vec3 CS; // sphere position - camera position
uniform         float r; // sphere radius

void main ()
{
    vec3 CX = X - C;

    // |t.CX-CS|=r, CX.CX.t.t - 2.CS.CX.t + CS.CS - r.r = 0

    float a = dot (CX, CX);
    float b = -2.0 * dot (CX, CS);
    float c = dot (CS, CS) - r * r;

    float det = b * b - 4.0 * a * c;

    if (det < 0.0)
        discard;

    float t = (-b - sqrt (det)) / 2.0 * a;

    if (t <= 0.0)
        discard;

    vec3 N = normalize (t * CX - CS);

    out_colour = vec4 (N, 1);
}

Here's an illustration of the variable names

I was expecting the normals to be illustrated with a wide-ranging rgb colour across the sphere, but as you can see...

What went wrong?

This line doesn't look quite right:

float t = (-b - sqrt (det)) / 2.0 * a;

You're missing parentheses around (2.0 * a). Remember that multiplication and division have equal operator precedence, so the expression as it's currently written means ((-b - sqrt (det)) / 2.0) * a, putting the a in the numerator instead of the denominator.

(Oh and this is a nitpick, but the thing you named det is called a “discriminant”, not a determinant.)


How to convert a 3D model into an OpenGL fixed pipeline representation I have a CAD model in Solidworks (which can be converted to STL, OBJ, STEP , VRML etc.) that I need to render in an old application, which still uses fixed pipeline.

Ideally, I would like to convert my model into a series of glMaterialfv, glBegin, glVertex3f, glEnd commands that I can compile directly into a C library so that I can avoid loading data from an external file. If this approach will be too painful, however, perhaps someone could alternatively suggest an open-source lightweight fixed pipeline model renderer that I can embed into my code.

You can compile it into a

Vertex vertices[] = {{posx, posy, posz, texu, texv, ..},
                     {posx, posy, posz, texu, texv, ..},
                     //...
                    }

and then loop over them:

glBegin(GL_TRIANGLES);
for (int i = 0; i < arraycount(vertices); i++){

    glTexCoord2f(vertices[i].texu, vertices[i].texv);
    //...
    glVertex3f(vertices[i].posx, vertices[i].posy, vertices[i].posz);
}
glEnd();

Another solution would be to mimic what the modern vertex buffer based solutions do by creating a VertexAttributeLayout struct and setting it up. Then in the loop you interpret the layout struct and interpret the data as needed.


Ray casting in fan configuration produces point cloud with curvature, how to eliminate curvature? I'm attempting to perform an intersection test using ray casting (not sure if correct term so please forgive me if not) and am outputting the intersections as a point cloud, and the point cloud shows curvature (on the Z-axis only, the point cloud is completely flat on the Y axis, and the horizontal axis in this image is the X axis):

I borrowed concepts from the Scratchapixel site, specifically http://scratchapixel.com/lessons/3d-basic-rendering/minimal-ray-tracer-rendering-simple-shapes/ray-box-intersection.

Essentially, I am generating 16 rays, all with the same origin vector.  The direction vectors start at +15 degrees on the YZ plane, and continue in increments of -2 degrees down to -15.  I have an axis aligned bounding box that I am testing intersection with.  I use a rotation transform to rotate the 16 rays CCW around the Z axis.  I am performing the intersection test for all 16 rays each 0.1 degrees, and if it returns true, I add the point to the point cloud.

Here's my intersection code:

bool test_intersect(Box b, Ray r, Vec3f& intersect_point)
{
    float txmin = 0.0f, txmax = 0.0f, tymin = 0.0f, tymax = 0.0f, tzmin = 0.0f, tzmax = 0.0f;
    float t_min = 0.0f, t_max = 0.0f, t = 0.0f;

    // Determine inverse direction of ray to alleviate 0 = -0 issues
    Vec3f inverse_direction(1 / r.direction.x, 1 / r.direction.y, 1 / r.direction.z);

    // Solving box_min/box_max0 = O + Dt
    txmin = (b.box_min.x - r.origin.x) * inverse_direction.x;
    txmax = (b.box_max.x - r.origin.x) * inverse_direction.x;
    tymin = (b.box_min.y - r.origin.y) * inverse_direction.y;
    tymax = (b.box_max.y - r.origin.y) * inverse_direction.y;
    tzmin = (b.box_min.z - r.origin.z) * inverse_direction.z;
    tzmax = (b.box_max.z - r.origin.z) * inverse_direction.z;

    // Depending on direction of ray tmin may > tmax, so we may need to swap
    if (txmin > txmax) std::swap(txmin, txmax);
    if (tymin > tymax) std::swap(tymin, tymax);
    if (tzmin > tzmax) std::swap(tzmin, tzmax);

    t_min = txmin;
    t_max = txmax;

    // If t-value of a min is greater than t-value of max,
    // we missed the object in that plane.
    if ((t_min > tymax) || (tymin > t_max))
        return false;

    if (tymin > t_min)
        t_min = tymin;
    if (tymax < t_max)
        t_max = tymax;

    if ((t_min > tzmax) || (tzmin > t_max))
        return false;

    if (tzmin > t_min)
        t_min = tzmin;
    if (tzmax < t_max)
        t_max = tzmax;

    if (t_min > 0)
        t = t_min;
    else
        if (t_max > 0)
            t = t_max;
        else
            return false;

    intersect_point.x = r.origin.x + r.direction.x * t;
    intersect_point.y = r.origin.y + r.direction.y * t;
    intersect_point.z = r.origin.z + r.direction.z * t;

    return true;

}

And my rotation:

// Rotation around z axis, for rotating array and checking beam intersections
void transform_rotate_z(Vec3f& in_vector, float angle)
{
    float radians = angle * (M_PI / 180);

    float result_x = cos(radians) * in_vector.x + -sin(radians) * in_vector.y;
    float result_y = sin(radians) * in_vector.x + cos(radians) * in_vector.y;
    in_vector.x = result_x;
    in_vector.y = result_y;

}

I have racked my brain for quite a while but I can't seem to determine how I can prevent this curvature, I'm sure I'm overlooking something simple.  I'd be grateful for any help you can provide.

EDIT 9/18/16:  It turned out that I had incorrectly believed that physical LIDAR units had some algorithmic way of "straightening" out the curves, which is not the case!  The output is supposed to look like the picture above.

The direction vectors start at +15 degrees on the YZ plane, and continue in increments of -2 degrees down to -15.

There's your problem—by generating the rays that way, you're doing something more like a spherical projection or fisheye projection, not a linear perspective projection. The nonlinear projection is the origin of the curvature you see.

To get a perspective projection instead, conceptually the way to think about it is that there's an image rectangle floating in front of the camera, divided into grid squares (pixels), and you fire a ray from the camera position toward the center of each pixel. In code, this looks something like:

p = tan(horizontalFOV / 2)
q = tan(verticalFOV / 2)
for y = 0 to imageHeight - 1
    for x = 0 to imageWidth - 1
        rayDirection = Vec3f(1.0,
                             p * ((x + 0.5) / imageWidth * 2.0 - 1.0)
                             q * ((y + 0.5) / imageHeight * 2.0 - 1.0)).normalize()

Note that the directions generated this way are not equally spaced in angle (they're closer together in angle toward the edges of the image than at the center), but they are equally spaced in distance on the image rectangle.


DirectX / OpenGL(Vulkan) concepts mapping chart Often a similar hardware feature is exposed via DirectX and OpenGL using different terminology.

For example:
Constant Buffer / Uniform Buffer Object
RWBuffer / SSBO

I am looking for an exhaustive chart that describes which DirectX terminology is used to refer to which OpenGL concept, and vice-versa.
Where can I find such a resource?

I haven't been able to find such a chart on the web, so I made one here. (Everyone, feel free to add, elaborate, or correct any mistakes. Some of these are just best guesses based on a partial understanding of the API and hardware internals.)

API Basics

D3D11                          OpenGL 4.x
-----                          ----------
device                         context
immediate context              (implicit; no specific name)
deferred context               (no cross-vendor equivalent, but see
                                GL_NV_command_list)
swap chain                     (implicit; no specific name)
(no cross-vendor equivalent)   extensions
debug layer; info queue        GL_KHR_debug extension

Shaders

D3D11              OpenGL 4.x
-----              ----------
pixel shader       fragment shader
hull shader        tessellation control shader
domain shader      tessellation evaluation shader
(vertex shader, geometry shader, and compute shader
 are called the same in both)

registers          binding points
semantics          interface layouts
SV_Foo semantics   gl_Foo builtin variables

class linkage      subroutines

(no equivalent)    program objects; program linking

(D3D11's normal
 behavior; no      separate shader objects
 specific name)

Geometry and Drawing

D3D11              OpenGL 4.x
-----              ----------
vertex buffer      vertex attribute array buffer; vertex buffer object
index buffer       element array buffer
input layout       vertex array object (sort of)

Draw               glDrawArrays
DrawIndexed        glDrawElements
(instancing and indirect draw are called similarly in both)
(no equivalent)    multi-draw, e.g. glMultiDrawElements

stream-out         transform feedback
DrawAuto           glDrawTransformFeedback

predication        conditional rendering
(no equivalent)    sync objects

Buffers and Textures

D3D11                    OpenGL 4.x
-----                    ----------
constant buffer          uniform buffer object
typed buffer             texture buffer
structured buffer        (no specific name; subset of SSBO features)
UAV buffer; RWBuffer     SSBO (shader storage buffer object)
UAV texture; RWTexture   image load/store

shader resource view     texture view
sampler state            sampler object

interlocked operations   atomic operations
append/consume buffer    SSBO + atomic counter

discard buffer/texture   invalidate buffer/texture
(no equivalent)          persistent mapping
(D3D11's normal
 behavior; no            immutable storage
 specific name)
(implicitly inserted     glMemoryBarrier; glTextureBarrier
 by the API)

Render Targets

D3D11                     OpenGL 4.x
-----                     ----------
(no equivalent)           framebuffer object
render target view        framebuffer color attachment
depth-stencil view        framebuffer depth-stencil attachment
multisample resolve       blit multisampled buffer to non-multisampled one

multiple render targets   multiple color attachments
render target array       layered image

(no equivalent)           renderbuffer

Queries

D3D11                       OpenGL 4.x
-----                       ----------
timestamp query             timer query
timestamp-disjoint query    (no equivalent)
(no equivalent)             time-elapsed query
occlusion query             samples-passed query
occlusion predicate query   any-samples-passed query
pipeline statistics query   (no equivalent in core, but see
                             GL_ARB_pipeline_statistics_query)
SO statistics query         primitives-generated/-written queries
(no equivalent)             query buffer object

Compute Shaders

D3D11                     OpenGL 4.x
-----                     ----------
thread                    invocation
thread group              work group
thread group size         local size
threadgroup variable      shared variable

group sync                "plain" barrier
group memory barrier      shared memory barrier
device memory barrier     atomic+buffer+image memory barriers
all memory barrier        group memory barrier

Other Resources

Porting from DirectX11 to OpenGL 4.2 – not exhaustive, but a quick discussion of common porting issues
MSDN: GLSL-to-HLSL porting guide – lists correspondences and differences between GLSL and HLSL shading languages


Can somebody explain this Ray Tracing Function? I am currently reading through Peter Shirley's Ray Tracing in One Weekend. In the beginning chapters where the author introduces diffuse surfaces we a presented with this function:

vec3 color(const ray& r, hitable *world)
{
hit_record rec;
if(world->hit(r, 0.0, MAXFLOAT,rec))
  {
   vec3 target = rec.p + rec.normal + random_in_unit_sphere();
   return 0.5*color(ray(rec.p, target-rec.p), world);
  }
else
  {
   vec3 unit_direction = unit_vector(r.direction());
   float t = 0.5*(unit_direction.y() + 1.0);
   return (1.0-t)*vec3(1.0, 1.0, 1.0) + t*vec3(0.5, 0.7, 1.0);
  }
}

Can somebody where the actual definition for the function is? Because in the first part of the ifthe return value is 0.5*color(ray(rec.p, target-rec.p), world);. Will it execute the function again except go through the else?

Regarding what the function actually does here is what I have gathered from the book based on my current understanding:

Pick a random point s from the unit radius sphere that is tangent to the hitpoint, and send a
ray from the hitpoint p to the random point s. That sphere has center (p+N)

Which then gives us:

Good answer above.    (I like that the book adds in p then subtracts it.)

This is a hard-coded grey world as a "hello world" kind of ray tracer.   The 0.5 is the hard-coded reflectance.   Keep working through book and the object reflectance and max-recursion will be addressed.   Ray branching I avoid like the plague.   In cost benefit I am always a skeptic on ray trees versus ray paths.


What does the z-buffer look like in memory? I am an amateur game developer, and I've been reading a lot on how computer graphics rendering works lately. I was reading on the Z-buffer recently and I can't quite seem to be able to wrap my head around what exactly the Z-buffer looks like in terms of memory. It's described to contain depth information for each fragment that will be drawn on-screen, and that modern Z-buffers have 32-bits, so would that mean that on a, let's say, 1920x1080 screen it'd be just above 8MB (1920 * 1080 * 32) per frame?
I still don't quite understand what this value would be to a GPU (maybe it can crunch it easily), or if this value is even correct. Most demostrative implementations I found implement the Z-buffer as a simple array with size (height * width), so I'm basing myself off of that.

The Z buffer used to be specialized memory set aside for a single purpose, some web sites still explain it like that, but no longer.
Now the Z buffer is just a chunk of memory you allocate, or an API like OpenGL allocates on your behalf.
The size of that chunk of memory will depend on the type of the Z buffer values, in the example you gave it is a 32bit [floating point] values, but 24 bits is also very common. Always choose the smallest size the program needs as it can have a large effect on the performance of the application. It is indeed multiplied by the size of framebuffer so 8mb is correct for the example you gave.
The values that get stored in it are the depth values for any geometry drawn to the associated framebuffer. It is important to realize that these values are NOT the linear values of the MVP matrix computed in the vertex shader so the Z buffer can not be used for things like shadow maps.
Fragments resulting from each draw call have their depth values tested against existing values in the Z buffer and if the test passes the GPU will write that fragment and update the Z buffer with the new value, if not the fragment gets discarded and the Z buffer is left untouched.
A few other little details:
The Z buffer is generally cleared at the beginning of each frame with a clear value that can be set (or must be set) via the API. This becomes the default value that writes to the Z buffer are tested against.
GPU's have specialized hardware for writing the Z buffer, this hardware can speed up writing to memory by a factor of 2 or more and can be leveraged when creating things like shadow maps, so it is not limited for use with just the Z buffer.
Depth testing can be turned off/on for each draw call, which can be useful.


What is Ray Marching? Is Sphere Tracing the same thing? A lot of ShaderToy demos share the Ray Marching algorithm to render the scene, but they are often written with a very compact style and i can't find any straightforward examples or explanation.

So what is Ray Marching? Some comments suggests that it is a variation of Sphere Tracing. What are the computational advantages of a such approach?

TL;DR
They belong to the same family of solvers, where sphere tracing is one method of ray marching, which is the family name.
Raymarching a definition
Raymarching is a technique a bit like traditional raytracing where the surface function is not easy to solve (or impossible without numeric iterative methods). In raytracing you just look up the ray intersection, whereas in ray marching you march forward (or back and forth) until you find the intersection, have enough samples or whatever it is your trying to solve. Try to think of it like a newton-raphson method for surface finding, or summing for integrating a varying function.
This can be useful if you:

Need to render volumetrics that arenot uniform
Rendering implicit functions, fractals
Rendering other kinds of parametric surfaces where intersection is not known ahead of time, like paralax mapping
Etc

Image 1: Traditional ray marching for surface finding
Related posts:

how-do-raymarch-shaders-work (GameDev.SE)

Sphere tracing
Sphere tracing is one possible Ray marching algorithm. Not all raymarching uses benefit form this method, as they can not be converted into this kind of scheme.
Sphere tracing is used for rendering implicit surfaces. Implicit surfaces are formed at some level of a continuous function. In essence solving the equation
F(X,Y,Z) = 0

Because of how this function can be solved at each point, one can go ahead and estimate the biggest possible sphere that can fit the current march step (or if not exactly reasonably safely). You then know that next march distance is at least this big. This way you can have adaptive ray marching steps speeding up the process.

Image 2: Sphere tracing* in action note how the step size is adaptive
For more info see:

Sphere tracing: a geometric method for the antialiased ray tracing of implicit surfaces

* Perhaps in 2d it's should be called circle tracing :)


Is the demoscene a source of advancements in computer graphics? I'm interested to know whether the demoscene has historically introduced new techniques that would have otherwise taken longer to discover, contributing to the progress of computer graphics. Has it become more or less relevant over the years?

I know that some of the early demos took advantage of known hardware errors and went beyond what was considered possible at the time, but what I'm interested in is whether any of the new techniques introduced were then taken up by researchers or professional programmers to become part of the mainstream accepted way of doing things.

The demo scene has been doing Ray marching for a long time, but only recently have main stream AAA games started using it.  The main use I've seen it for is for screenspace reflections, raymarching against the zbuffer (killzone, call of duty).  Also, shadertoy was made by inigo quillez, who is from the demo scene.  People are now using shadertoy to prototype and share graphics technique research.  So I'd say the answer is yes, but I'd like to hear more examples if other people have any (:


DX12 compute signature Can i have a root signature with 3 root parameters all being of the UAV type? Because what I am trying to do is, add two buffers and put the output of that in a output buffer.

In the following snippet I am trying to do the afroementioned. However, I get an error at the line calling D3DX12SerializeVersionedRootSignature()

Is it because I am not allowed to have 3 uav ranges?

CD3DX12_DESCRIPTOR_RANGE1 ranges_madhu[3];
ranges_madhu[0].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0, D3D12_DESCRIPTOR_RANGE_FLAG_DATA_VOLATILE);
ranges_madhu[1].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0, D3D12_DESCRIPTOR_RANGE_FLAG_DATA_VOLATILE);
ranges_madhu[2].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0, D3D12_DESCRIPTOR_RANGE_FLAG_DATA_VOLATILE);

CD3DX12_ROOT_PARAMETER1 rootParameters_madhu[ComputeRootParametersCount_madhu]; // this is 3   (thus all 3 ranges have been initialized as UAVs)
rootParameters_madhu[ComputeRootUAVTable_in1].InitAsDescriptorTable(1, &ranges_madhu[0], D3D12_SHADER_VISIBILITY_ALL);
rootParameters_madhu[ComputeRootUAVTable_in2].InitAsDescriptorTable(1, &ranges_madhu[1], D3D12_SHADER_VISIBILITY_ALL);
rootParameters_madhu[ComputeRootUAVTable_outp1].InitAsDescriptorTable(1, &ranges_madhu[2], D3D12_SHADER_VISIBILITY_ALL);

CD3DX12_VERSIONED_ROOT_SIGNATURE_DESC computeRootSignatureDesc_madhu;
computeRootSignatureDesc_madhu.Init_1_1(_countof(rootParameters_madhu), rootParameters_madhu, 0, nullptr);

ComPtr<ID3DBlob> signature1;
ComPtr<ID3DBlob> error1;

ThrowIfFailed(D3DX12SerializeVersionedRootSignature(&computeRootSignatureDesc_madhu, featureData_madhu.HighestVersion, &signature1, &error1));
ThrowIfFailed(m_device->CreateRootSignature(0, signature1->GetBufferPointer(), signature1->GetBufferSize(), IID_PPV_ARGS(&m_computeRootSignature1)));
NAME_D3D12_OBJECT(m_computeRootSignature1);

You're trying to map all three UAVs to the same descriptor slot (slot 0).

ranges_madhu[0].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0, D3D12_DESCRIPTOR_RANGE_FLAG_DATA_VOLATILE);
ranges_madhu[1].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0, D3D12_DESCRIPTOR_RANGE_FLAG_DATA_VOLATILE);
ranges_madhu[2].Init(D3D12_DESCRIPTOR_RANGE_TYPE_UAV, 1, 0, 0, D3D12_DESCRIPTOR_RANGE_FLAG_DATA_VOLATILE);

The baseShaderRegister value (the third parameter to these calls) indicates which descriptor slot to use. You have all of them set to 0, which won't work. They need to be distinct. For example, they could be 0, 1, and 2.


Why is eye-based ray tracing preferred over light-based ray tracing? It seems that virtually all path tracers use eye-based or view-based path tracing. That is, the light rays originate from the camera rather than the light source. The reason given for this everywhere I have seen online is that if one begins from the light source, then it is quite unlikely that the ray will ever hit the camera. For instance, the documentation for Blender's cycles says " we do not waste light rays that will not end up in the camera".
This seems intuitive at first, but this seems only to reverse the problem because one will just trace a ray until it hits the light source now, and this ray may never hit a light source before the maximum number of bounces, so we will just waste that ray as well. I can see how this is an improvement though, because if we originate at the camera, the first bounce will tend to have a large weight associated with it, but if we flipped the path to start from the light, then this last bounce would tend to have a small weight because many bounces have preceded it. That seems like the answer, except for one thing.
Most path tracers use next even estimation, which just means that at each bounce, the light path is connected directly to a light source as long as nothing occludes that path. This is always a valid path and greatly speeds up convergence. However, if one is going to use next event estimation, then I really can't understand how tracing rays from the camera is advantageous over tracing rays from the light source? In next event estimation, one should almost always get a complete light path either way. Is it related to the ambiguity about which pixel on the camera to connect to? There is a similar ambiguity about which point of an area light to connect to.
I am sure there must be a reason for tracing from the camera because everybody seems to be doing it, so if someone could explain this for me, and/or point to recent papers which compare the approaches, that would be greatly appreciated.

As you point out there is problems about which pixel on the camera to connect to. You probably wouldn't notice where you took the sample on an area light because generally the light is pretty uniform throughout, and even if it is textured you can just take a few samples and it will average to look ~correct. However if you connect to a random pixel, you would very easily notice that some pixels are black or have aliasing problems. By starting at the camera it's easier to ensure that all pixels are being sampled enough.
You are also only considered the light from one bounce. If you also want to get indirect lighting then your statement about weights comes into play again, and you are more likely to get a good path by starting at the camera.
Finally there are many techniques which start from the light! And techniques which start at both ends and try and connect. Try searching for photon mapping and bi-directional path tracing. It just turns out that forward path tracers generally work the best in most situations. Renderman has an integrator which combines all these techniques  which you can read about here https://rmanwiki.pixar.com/display/REN/PxrVCM .


Bicubic bezier surface from 4 bezier curves In the program I need to create, the user should specify the hull geometry of an aircraft wing and fuselage using cubic bezier polycurves.
But to get to m bezier patch surfaces the user would need to introduce 4 * m additional control points. It's not as simple a task as outlining sections in Inkscape.

So the question is whether there is a way to create a bicubic bezier surface having only its edge curves (or maybe any additional curves the user could draw)?

If it isn't possible with bezier curves, is there any way to create a 3d model by specifying only section curves?

If the answer is no, what way would you suggest to create hull geometry (maybe a bit rough) from another 3D model?

Yes, its pretty standard stuff. Most 3D applications our there can do this. Since the nomenclature of 3d applications is not standardized, the tool has different names in different applications: Loft (Maya, 3DSMax), Blend (Creo, Catia...) and so on.

Image 1: Blend between 3 curves, not closed but same principle applies. Open curves are easier as they clearly define the boundary conditions. (software used is Creo because that's what I had open)
You usually want the first edge be from a surface edge because otherwise you will lose the tangency info. But nothing prevents you from using a natural tangent direction, you just lose control. Also you need to pay attention to how you intend the curves to connect (what point connects to what point).
Personally I prefer drawing the hull or using some of the network based tools. This way allow you to specify control curves in 2 directions, thus giving control of what to connect where and how it should work mid run.

Image 2: Curve network.
There are many ways to do this, infinite ways in fact. Also if you want to be compatible with other mainstream CAD apps use NURBS instead of beziers than its easier for you to write a exporter/importer if your data set is rich enough. Beziers are just special cases of NURBS after all so your code itself should not need to change all that much (fitting also gets easier).
What you do is simply fit a curve trough your points in the second direction this will then give you the corresponding hull in the other direction. In your case you could just make a Bezier patch for each segment and then try to deduce a natural tangent direction.
One way
Like I said theres a infinite ways of constructing these, you have an artistic freedom of doing whatever you see fit it's a over constrained problem. One way of constructing this would be to have a patch for each consecutive cross section. This is nice and tidy as it generalizes works well with an arbitrary number of cross sections.

Image 3: Example of deriving one row for 2 consecutive bezier spans.
First recognize there are 3 cases (ill cover 2):

Free edges,
Internal edges,
External constraint.

I'll cover 1 and 2. First the Internal edge as its simple you want it to be smooth so the tangent length and direction in both patches must match. If that's not true then its not sufficiently continuous. You could simply take that this is the furthest point from the surrounding patches control points and due to mean value theorem it should have a tangent direction perpendicular to these (Line A-C is parallel with D-E). The tangent length should be about 1/3 of the length of the distance to the adjoining vertices (A-B or A-C, in this case the shorter of the spans. It could be longer or average. though that could pose problems). Obviously if you have more spans just repeat for one span forward and after for more internal spans if needed.
For free edges find the point on the perpendicular line that is as far from the point as half distance between the points (length B-D is equal to length (A-B)/2 and length B-E is equal to length (B-D)/2). The free tangent points towards this point. The length of the tangent is as long as one third of corresponding point difference (length (A-B)/3 and (B-C)/3). Obviously the distances and points could be arbitrary but these are somewhat natural.
Repeat for next point sequence in line and next and next. You end up with 2 spans that means 2 times 16 points.  There are other ways but this is relatively easy to convert into a visual form without going into deeper maths. But this is pretty well known math you can find many ways to form these by searching in literature.


Changing the projection reference point in Open GL By default, the eye an the projection reference point PRP are in (0,0,0). I can change the eye position with gluLookAt(), but how can I change the PRP (i.e., the  convergence position for a set of parallel lines) for a perspective projection in OpenGL?

Eye position, projection reference point PRP, camera center, or projection center are all just different words for the same thing.

gluLookAt() applied to the GL_MODELVIEW matrix works for both, parallel and perspective projection.

You can choose between parallel and perspective projection by setting up the GL_PROJECTION matrix. For perspective projection this can be done using the gluPerspective() function.

Creating a perspective projection matrix in OpenGL

Edit: (after revised question)

If the PRP is not at the eye position, you can not use gluPerspective(). Instead you have to create your own GL_PROJECTION matrix. Following the formula that you have now provided, this results in the 4 x 4 matrix:

$$\mathtt{A} =\begin{bmatrix} z_c-z_{pp} & 0 & -x_c &  x_c \cdot z_{pp}\\ 0  & z_c-z_{pp}  & -y_c & y_c \cdot z_{pp} \\ 0 & 0 & \frac{\mathrm{far}+\mathrm{near}}{\mathrm{near}-\mathrm{far}} & \frac{2 \cdot \mathrm{far} \cdot \mathrm{near}}{\mathrm{near}-\mathrm{far}} \\ 0 & 0 & -1 & z_c \end{bmatrix}
$$

I have done a quick OpenGL/WebGL rendering test with the GSN Composer. Follow the link and move the mouse over the render output to change $x_c$ and $y_c$ of the projection reference point $(x_c, y_c, z_c)$:

Example: ProjectionReferencePoint | GSN Composer


PBRT path tracing: negation of ray direction before next event estimation I am very new to computer graphics, so I am sorry if this results in a stupid question.

For educational purposes I am looking through the pbrt code and I have noticed that before computing the direction for the next path for the subsequent bounce, they flip the direction of the incoming ray. Specifically:

    Vector3f wo = -ray.d, wi;
    Float pdf;
    BxDFType flags;
    Spectrum f = isect.bsdf->Sample_f(wo, &wi, sampler.Get2D(), &pdf,
                                      BSDF_ALL, &flags);

Now my rationale to justify that (also hinted by the name of the variable), is that we are tracing the rays from the camera, but really the phenomenon we are simulating is light coming from light into the camera, so even if the algorithm does:

a) Eye --> Object --> Light

What we are simulating is more like

b) Eye <-- Object <-- Light

So my assumption here is that the direction is flipped because of this reason. But if this is the case, should the resulting wi be flipped again before giving it to the next ray as direction? In the next bounce we'll find ourselves in the same process as in the option a) , but if we don't flip wi, don't we have

PrevObject <-- Object --> Light  instead of

PrevObject --> Object --> Light

?

Is Sample_f returning an already flipped wi (i.e. ready for the next step)? Is my reasoning all wrong?

Note that I don't have the book yet, I am just trying to guess from code what's happening.

The incoming direction $\omega_o$ (coming from eye) is flipped in pbrt:

"Another convention we will follow is that the incident light direction $\omega_i$ and the outgoing viewing direction $\omega_o$ will both be normalized and outward facing after being transformed into the local coordinate system at the surface. By convention, the surface normal always points to the "outside" of the object...".


In the rendering pipeline, in what coordinate space are vertices when they arrive at the primitive assembly stage? Full disclaimer, this was a test question, but I couldn't find any information online.

In my opinion, this depends on if the primitive assembly stage happens before or after perspective division. If before, then it must be in homogeneous clip space. If after, NDC space.

Which of the two is it? Or am I completely wrong and its neither?

As pointed out by Simon F, the clipping stage needs to clip against edges (and thus triangles/primitives). Thus the primitive assembly stage cannot happen after clipping, even though the Pipeline is described such that primitive assembly happens after clipping.

Slide 16 of Ohio university's Han-Wei Shen's 2010 course The OpenGL Rendering Pipeline suggests that vertices are transformed to Clip Space, then the primitive assembly happens and only afterwards is clipping actually done.

According to Khronos' wiki the primitive assembly happens after clipping, which includes the following:

  The vertex positions are transformed from clip-space to window space via the Perspective Divide and the Viewport Transform.

Window Space is described as the space after the viewport transform and that means after NDC space:

  The viewport transform defines the transformation of vertex positions from NDC space to window space. These are the coordinates that are rasterized to the output image.

Since the viewport transform includes a scaling for the width and height of the viewport, as well as a translation with the viewports position on screen, you should end up with pixel coordiantes of your screen.


scan line algorithm is too slow? This is my code of the algorithm for making triangles :-

private void sort(){
    int temp = Math.round(m_Vertex1.getPosition().getX());
    int temp2 = Math.round(m_Vertex2.getPosition().getX());
    int temp3 = Math.round(m_Vertex3.getPosition().getX());

    m_minX = Math.min(temp3, Math.min(temp, temp2));    //Sorting the X values
    m_maxX = Math.max(temp3, Math.max(temp, temp2));

    temp = Math.round(m_Vertex1.getPosition().getY());
    temp2 = Math.round(m_Vertex2.getPosition().getY());
    temp3 = Math.round(m_Vertex3.getPosition().getY());

    m_minY = Math.min(temp3, Math.min(temp, temp2));    // Sorting the Y values
    m_maxY = Math.max(temp3, Math.max(temp, temp2));
}

public void DrawTriangle(){
    new Line(m_Vertex1, m_Vertex2, m_display).DrawLine(Optional.of(EdgeOnePoints));     //Getting all the points on the boundary of the triangle
    new Line(m_Vertex2, m_Vertex3, m_display).DrawLine(Optional.of(EdgeTwoPoints));
    new Line(m_Vertex1, m_Vertex3, m_display).DrawLine(Optional.of(EdgeThreePoints));

    Vector2D start = Vector2D.zero();
    Vector2D end = Vector2D.zero();

    for(float i = m_minY; i <= m_maxY ;i++){        //Iterating from top to bottom of the triangle

        for(float j = m_minX; j <= m_maxX; j++){    //Iterating left to right of the triangle
            Vector2D temp = new Vector2D(j,i);

            if(EdgeOnePoints.contains(temp) || EdgeTwoPoints.contains(temp) || EdgeThreePoints.contains(temp)){
                if(start.equals(Vector2D.zero())){      // Getting the first point of intersection between the triangle and the scanline
                    start = temp;
                }else{
                    if(EdgeOnePoints.contains(start) && !EdgeOnePoints.contains(temp)){     // Checking if start point and end point are on the same edge or not, if not then it is a valid point else not.
                        end = temp;
                        break;
                    }else if(EdgeTwoPoints.contains(start) && !EdgeTwoPoints.contains(temp)){
                        end = temp;
                        break;
                    }else if(EdgeThreePoints.contains(start) && !EdgeThreePoints.contains(temp)){
                        end = temp;
                        break;
                    }
                }
            }
        }

        if(!start.equals(Vector2D.zero()) && !end.equals(Vector2D.zero())){ //if both start and end points are available then draw then fill all the points in between them.
            for(float j = start.getX(); j <= end.getX(); j++){
                new Point(new Vector2D(j, i), PixelData.white(), m_display).DrawPoint();
            }
        }

        start = Vector2D.zero();
        end = Vector2D.zero();
    }
}

Now i have couple of problems with it :-

It is a tortoise, i have tested it on a old machine and just with 2 rotating triangles, the frame rate is below 30.
i get this weird line in between the triangle at some specific position when rotating the triangle.

I don't care much about the second problem but can anyone help me making this algorithm fast. should i use something like flood fill or boundary fill algorithm ?

One red flag is the use of new several times within the loop. Memory allocation doesn't belong in a rasterizer! :) Certainly you should not need to allocate a Point object (which is used once and then immediately discarded) and do a method call on it, just in order to fill a single pixel! The pixels are hopefully stored as a flat array of bytes, so just write directly to the appropriate address in it. Similarly, don't allocate a Vector2D every time through, just create one (ideally on the stack, if the language you're using allows for it), and re-use it.

Secondly, the algorithm you're using doesn't seem to be a true scanline rasterizer. It iterates over the pixels in each line from left to right, performing edge tests on every single pixel to determine whether it's inside or outside, and recording when that state changes in the start and end variables.

The way a scanline rasterizer is supposed to work (which is much faster) is to calculate the intersection points of each edge with the scanline (using good old school algebra line-line intersection math). Ideally you would have already categorized and sorted the three edges as left, right, or horizontal and therefore once you have the intersection points, it's easy to figure out the interval that the triangle covers on the scanline. Then you can iterate over that and shade or fill each pixel.

Finally, I'm not sure if this is a real issue or not, but there are a lot of method calls for relatively trivial things like checking whether vectors are equal, or doing an edge-vs-point test. Hopefully the compiler is inlining all those, but you might want to check the generated code to see. If it's not, you could see a fair speedup by manually inlining that stuff, and possibly manually "destructuring" the vectors (i.e. replace a Vector2D variable by two explicit x and y variables).


Non real-time rendering on Unity3D I made an audio visualizer using Unity3D (you can see it here) but I am not satisfied on the video quality, as the compression destroys the graphics. I recorded the screen during a real-time rendering. I tried many screen recorders, but always the same disappointment.

I want to try another approach, using non real-time rendering. I know Unity is made for real time rendering, but do you know if such a thing is possible ?

Yes, there's a better approach than using a screen recorder. You can capture frames directly inside Unity, using ScreenCapture.CaptureScreenshot. There's a choice of formats to save as, and you can use PNG so that, when you later assemble the frames into a video (using ffmpeg or another tool), you have full control over how much compression to use.

This function is very slow, because it reads back the framebuffer, encodes the image, and writes it to disk, all in the main thread. You may want to use it in combination with setting the Time.captureFramerate value. This setting lets you slow down Unity by completely disconnecting the in-game frame rate from real time. That is, if you set it to 30, the game will run at 30 fps as measured by Time.deltaTime and the calls to Update on your components, regardless of whether a frame takes a millisecond or a minute as measured by wall-clock time.


My perspective projection is messed up? So I've been messing with perspective projection matrices recently. I used numpy and GTK/Cairo to make a very small Python renderer. I'm very confused with the results I'm getting though.

I took this Homogeneous Coordinates technique from an online lecture. If I understood correctly, the objective is to transform every point inside a "Viewing Pyramid" that's frustum shaped so they fit in a cube. (Image from of songho.ca)

You need a Field of View angle ($\alpha$), the Near and Far plane distances ($n$ and $f$ respectively), and the aspect ratio ($r$). Firstly you turn every 3D Point into a Homogeneous Point by adding  a 1 like so:

\begin{align*}
\begin{pmatrix}
  x & y & z
\end{pmatrix}
\xrightarrow{\text{4D}}
\begin{bmatrix}
  x & y & z & 1
\end{bmatrix}
\end{align*}

Then you multiply your point matrix by a perspective projection matrix:

\begin{align*}
\begin{bmatrix}x & y &z & 1 \end{bmatrix}
\begin{bmatrix}
  1\over\tan(\alpha/2) & 0 & 0 & 0\\
  0 & r\over\tan(\alpha/2) & 0 & 0\\
  0 & 0 & (f+n)\over(f-n) & -1 \\
  0 & 0 & (2nf)\over(f-n) & 0
\end{bmatrix}
=
\begin{bmatrix}
x' & y' & z' & w
\end{bmatrix}
\end{align*}

And to go back to a 3D point in space you divide by the fourth dimension:

\begin{align*}
\begin{bmatrix}
  x' & y' & z' & w
\end{bmatrix}
\xrightarrow{\text{3D}}
\begin{pmatrix}
  x' \over w & y' \over w & z' \over w
\end{pmatrix}
\end{align*}

This is exactly what I've done with numpy:

def projection_matrix(fov, aspect, near, far):
    t = 1/math.tan(math.radians(fov)/2)
    a = (far + near)/(far - near)
    b = (2*near*far)/(far-near)
    r = aspect

    return numpy.matrix([[t,   0,   0,   0],
                         [0, r*t,   0,   0],
                         [0,   0,   a,  -1],
                         [0,   0,   b,   0]])

But for some reason the renderer is totally messed up. This is supposed to be a spinning cube... What am I missing here?

The math for the projection matrix is (with fov as $\alpha$):

$q \leftarrow \frac{1}{tan(\frac{\alpha}{2})}$

$a \leftarrow \frac{q}{aspect}$

$b \leftarrow \frac{(far + near)}{(near - far)}$

$c \leftarrow \frac{(2 * far * near)}{(near - far)}$

Notice that there're some things you're doing that are differently, such as the order of your subtractions between near and far, how you organize the matrix values, and your multiplication between your r * t.

Using the variables above, the column-major matrix below would be the resulting perspective projection matrix:

\begin{bmatrix}
  a & 0 &  0 & 0 \\
  0 & q &  0 & 0 \\
  0 & 0 &  b & c \\
  0 & 0 & -1 & 0
\end{bmatrix}

From the above, we get:

def perspective_projection_matrix(fov, aspect, near, far):
    q = 1 / tan(radians(fov * 0.5))
    a = q / aspect
    b = (far + near) / (near - far)
    c = (2*near*far) / (near - far)

    # construct column-major matrix here...

NOTE: I left the last part out because I'm not familiar enough with numpy to know whether it expects row-major or column-major order.

Also, you should validate all your arguments (e.g. both near > 0 and far > 0, far > near, etc.) if you want to avoid future headaches.


Older Api documentation I am currently using a older IntelHd Gpu which supports Opengl3.1 (Glsl #version140).

While trying to locate the relevant Api for this version ,the Khronos site only provides  documentation for Opengl2.1 and Opengl4.5.

On their Github page documentation for Opengl2.1 and Opengl4 is available.

How to locate the Api for Opengl 3.1?

Older Opengl Api documentation can be found at this  Official Khronos Registry


How to encode/decode buffer data in glTF? I'm playing around with base64 embedded data URI's and tried to analyze the buffer data of the gltf box sample model, as defined in this example here (line 76).

 "uri": "data:application/octet-stream;base64,AAABAAIAAwACAAEABAAFAAYABwAGAAUACAAJAAoACwAKAAkADAANAA4ADwAOAA0AEAARABIAEwASABEAFAAVABYAFwAWABUAAAAAvwAAAL8AAAA/AAAAPwAAAL8AAAA/AAAAvwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAL8AAAA/AAAAvwAAAL8AAAA/AAAAPwAAAL8AAAC/AAAAvwAAAL8AAAC/AAAAPwAAAD8AAAA/AAAAPwAAAL8AAAA/AAAAPwAAAD8AAAC/AAAAPwAAAL8AAAC/AAAAvwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAvwAAAD8AAAC/AAAAPwAAAD8AAAC/AAAAvwAAAL8AAAA/AAAAvwAAAD8AAAA/AAAAvwAAAL8AAAC/AAAAvwAAAD8AAAC/AAAAvwAAAL8AAAC/AAAAvwAAAD8AAAC/AAAAPwAAAL8AAAC/AAAAPwAAAD8AAAC/AAAAAAAAAAAAAIA/AAAAAAAAAAAAAIA/AAAAAAAAAAAAAIA/AAAAAAAAAAAAAIA/AAAAAAAAgL8AAAAAAAAAAAAAgL8AAAAAAAAAAAAAgL8AAAAAAAAAAAAAgL8AAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAAAAAAAAAAgD8AAAAAAAAAAAAAgD8AAAAAAAAAAAAAgD8AAAAAAAAAAAAAgD8AAAAAAACAvwAAAAAAAAAAAACAvwAAAAAAAAAAAACAvwAAAAAAAAAAAACAvwAAAAAAAAAAAAAAAAAAAAAAAIC/AAAAAAAAAAAAAIC/AAAAAAAAAAAAAIC/AAAAAAAAAAAAAIC/"

This is the buffer data for a simple cube, here's screenshot:

But it's giving me a hard time to understand what's exactly in this buffer. As far as I know, it should contain the vertices, and maybe indices.

I tried to decode the base64 and the output is binary. I'm lost since I have no clue how this binary is encoded or decoded. Can anyone point me how to write such buffers or at least how to read them?

How do I generate my own buffers?

The information you're looking for is defined in the 'accessors' and 'bufferViews' near the top of the source file you linked.

Bufferviews simply divide the buffer up into sub ranges and define broadly what kind of data lives there using some obscure shortcodes. In this case, target 34963 means index data and 34962 means vertex data. So from the other parameters in the bufferviews you can see that the first 72 bytes are indices and the remaining 576 bytes are vertex data.

The accessors are what actually define the format of the data and again use weird codes for "componentType" - 5123 is an unsigned short (2 bytes) and 5126 is single precision float (4 bytes). They also define whether they should be read singly ("SCALAR") or in vector groups (e.g. "VEC3"), and also a starting offset into the bufferview and "stride" between the start of data points like regular OpenGL vertex buffer bindings.

Putting it all together, the first 72 bytes are 36 shorts representing the indices (3 * 12 triangles). The next 576 bytes are two consecutive sets of 24 vec3 (4 per square face, 12 bytes per vec3) representing vertex data. Since the first set are clamped to + or - 1/2 and the second set to + or - 1, I'm guessing first set are positions, second set are normals.

The base 64 encoding just takes the raw bit stream, splits it into groups of 6 rather than 8, and maps each unique 6-bit combination onto a character. You can see this is quite wasteful as each character takes at least 8 bits to store, quite possibly 16 or more depending on the encoding used.


Why does graphics speak of "dielectrics" rather than insulators? For example, Filament's documentation at https://google.github.io/filament/Filament.md.html uses the term "dielectrics" when contrasting nonconductors to conductors, which it calls "metallics". And here on stackexchange, https://computergraphics.stackexchange.com/search?page=2&tab=Relevance&q=dielectric also produces many hits for "dielectric". I would have normally expected the word "insulator" in these instances. Does "dielectric" stem from some historical source, or is it the accurate term to use?

Strictly speaking, dielectrics are not necessarily insulators. For example, salt water is a reasonable conductor but also a dielectric.

The term "dielectric" tends to show up in discussion of the Fresnel effect—how reflectance and transmittance vary with angle. Dielectric materials (i.e. nonmetals) are contrasted with metallic materials as they have different Fresnel behavior, which can be traced back to how the materials react on a microscopic scale to the electromagnetic field of an incident light wave.

So, for computer graphics purposes, the axis "dielectric/metallic" is more relevant than that of "insulator/conductor", since the former directly affects the appearance of materials.


Issues with Multi-threaded Raytracing I'm having some issues with my multi-threaded ray tracing implementation. It seems to only render about half of the image. Here is the picture:

Here is the code:

int max = (nx * ny); //width * height
volatile std::atomic<int> count(0);

int cores = std::thread::hardware_concurrency();
cores -= 1;
vector<future<vector<rgbpacket>>> future_vector;
cout << "Threads supported: " << cores << "\n";
while (cores--) {
    future_vector.emplace_back(
        std::async([=, &world, &cam, &dim, &orth, &count] {
            vector<rgbpacket> stack;
            while (true) {

                int index = count++;

                if (index >= max) {

                    return stack;
                } else {
                    int k = (index % nx); //mod width to get column
                    int j = (index / nx); //divide width to get row

                    rgbpacket curpx = render(j, k, dim, world, cam, orth);
                    curpx.k = (unsigned int)k;
                    curpx.j = (unsigned int)j;
                    stack.push_back(curpx);

                }
            }
        })
    );
}

//parse the image buffer
for (unsigned int i = 0; i < future_vector.size(); i++) {
    vector<rgbpacket> stack = future_vector[i].get();
    for (unsigned int k = 0; k < stack.size(); k++) {
        rgbpacket rgb_comp = stack.back();

        //Using the new compressed packet
        rgbaColor conv;
        conv.r = rgb_comp.r;
        conv.g = rgb_comp.g;
        conv.b = rgb_comp.b;

        hslaColor pix = rgb2hsl(conv);
        HSLAPixel newpixel(pix.h, pix.s, pix.l);

        HSLAPixel &imgpx = img.getPixel(rgb_comp.k, rgb_comp.j);
        imgpx = newpixel;

        stack.pop_back();
    }
}

For some preface, I am calculating the pixel with respect to the position with the index variable. Once I calculate it, I store it (along with the position) in the vector. After I calculate all of the pixel values, I parse them into an image buffer and later print that image.

I've narrowed the issue (I think) to where I am calculating the rendered pixel and storing it in the vector. For some reason, it does not store all of the pixels in the vector and I am not sure why? Any help is appreciated. Thanks!

I fixed it, It was just a coding mistake, there was nothing wrong with the implementation. So the error was in fact in the 2nd for-loop when I was parsing the image buffer. I was reaching for the last pixel in the vector and then popping it off from the back of the stack.

This means that in the for loop condition, the vector size will be changing but k will still be incrementing the same, so it will effectively only do half of the elements per vector. Because as K is incrementing stack.size() is decrementing so they meet in the middle and the loop is done.

To fix this, I just used index notation, so:

rgbpacket &rgbpixel = stack[index];

and then I deleted the line where I was popping off from the stack.

Even though this is a stupid bug,
I hope this helps other people.


Optix: Rendering time-variant data I have a Optix Raycasting renderer which loads and renders VTK files.
For a single static model this works fine.

But now my dataset consists of multiple timesteps which I want to display in a animated fashion.

Each couple of frames or seconds the displayed model has to be switched out with the next one.
If possible I want to refrain from rebuilding the acceleration structure each time this happens.

So my question: Can I just load all models at once, place them in the global acceleration structure and then just switch all off except the one currently displayed.
My hope is that this would be more efficient.

Edit 1:
I have now build a variant in which I create optix::Acceleration and optix::Group for each of the timesteps separate and each time the active timestep changes I just

_context["top_object"]->set(mesh_group[timestep]);

But each this call takes nearly half a second. I think optix does quite some work in the background when I switch this object out.
This delay is not acceptable for me as it makes the playback of my "animation" stutter.

Has anyone a idea how to do this more efficient?

With help from the Nvidia Forum and two very helpful and friendly Nvidia employees I found the perfect solution.

In OptiX there is a so called selector node. This is a special scene-graph node that utilizes a user specified program to select which child a ray should traverse and which not.

#include <optix.h>

rtDeclareVariable(unsigned int, timestep, , );

RT_PROGRAM void animation_selector()
{
    rtIntersectChild(timestep);
}

This is a simple version of such a selection program. From the CPP-API side the current timestep will be set and can be used to make the animation. And then when the scene graph is traversed the program just says "Traverse only the child with index 'timestep'". This does not trigger a recompile or refit and therefore is nearly instant.

The selector node is simply created in following way:

optix::Selector selector = context_->createSelector();

std::string path_to_ptx = VRTPtxFinder::GetPtxPath("VistaRayTracing_generated_animation_selector.cu.ptx");

optix::Program selection_program = context_->createProgramFromPTXFile(path_to_ptx, "animation_selector");
selector["timestep"]->setUint(0u);
selector->setVisitProgram(selection_program);

for(auto group : groups)
{
  selector->addChild(group);
}

The only cost is one additional method call for each traversal and thereby also a slightly bigger stack which caused me some problems with a stack overflow so when using this, keep an eye on the stack size.


Workflow of the Naive Surface Nets algorithm This question is comming from ComputerScience after suggestion

I'm trying to understand the Naive Surface Nets algorithm which is related to surface generation out of Voxels. I've learned of it here

So far I understood that the naive surface nets algorithm calculates the "optimal" edge crossings for a given input. Problem is that I don't understand how it's supposed to calculate the edge crossings compared to the marching cubes algorithm. If the input data is represented in binary values (only one and zero) like for marching cubes algorithm shouldn't the computation of the edge crossings have the same results?

I suppose a step by step showcase of what the algorithm does for aquiring the surface of 2D sample voxels data would help me a lot understanding it. Sample code is fine too but is not a must have.

For example for this data the marching cubes algorithm gives as result the image show below (the lines). Would the naive surface nets algorithm return the same result?

Where red stands for binary 1 and blue for binary 0 asuming each voxel has the same space between each other (as always I think).

I think the basic idea, as explained in the article to which you linked, is to associate a vertex (shown in light blue) to each square that intersects the surface, with the vertex positioned at the average of the adjacent edge crossings (shown in gray). Then connect up with dual edges (shown also in light blue).


Why can I see the diffuse lighting effect on a perfect mirror? Currently I am learning PBR by Unity3D. I find that even I turn the smoothness to 1, I can still see the diffuse lighting effect, which does not make any sense to me.

Imagine I trace a ray from my eye to the mirror, and I do importance sampling based on the material's brdf, there are only two options,  hit the light source or not. However, I find that if I set the metallic to be 0 and smoothness to 1, there will have large amount of area illuminated.

Dielectric materials (which is what you get when metalness is 0) don't exhibit a mirror-like effect. Think of a sheet of smooth, non-transparent plastic. Real-life mirrors are panes of glass or transparent plastic covered with a thin layer of metal. Try a white base colour (1,1,1) and full metalness (1) instead.

As Hubble pointed out in his comment, Unity won't do full ray tracing for you out of the box, but it should be able to do some approximation with screen-space reflections and local reflection probes.


What is the name of this moving color pixels effect, for animating a painting? https://superrare.co/artwork-v2/spring-22267
The artwork in the link seems to be based on a painting of a woman, but effects have been added that assign a pixel to each block of the painting that shift in color and contrast across a certain number of frames as part of a gif animation, although the original painting itself doesn't move underneath.

is there a name for this effect?
and could someone breifly outline the steps of how it can be achieved
in software?
any popular examples where this effect is used or first introduced?

This effect is called Color Cycling (or Palette Shifting). Mark Ferrari has a great GDC talk where he demonstrates and explains the entire technique. You can view a bunch of his artwork based on this technique here.
The main idea is that each pixel is painted not with a single color, but as values of a look-up table to a palette of colors. The entire image then cycles through the palettes frame by frame. Assigning colors to each palette to create the illusion of movement requires a fair bit of artistry. Mark Ferrari does this in a software called Pro Motion, but this can be coded in a shader pretty easily.


Perspective projection near plane not in world coordinates I have a camera I have placed zunits away from a billboarded rect. My goal is to discard all other geometry that is closer to the camera/in front of this rect.
With perspective projection I have always set the near plane to 0.1 and called it a day however here I tried to set it to z thinking it would clip anything in front of this rect.
No such luck. This ended up clipping that rect and seemingly even more. Z-1 also did not have the desired result.
This leads me to think the near clipping plane might not be in the same coordinate space as the world? If not what space is it in?

The perspective projection matrix transforms from camera space to clip space. The near-plane value is the position of the near plane in camera space. So in case that your world space to camera space transformation does not use any scaling, only rotations and translations, then if you place the camera $z$ units away from the billboard surface and look directly onto it, a near plane value of $z$ will cause the billboard plane to lie on the near plane. Due to rounding errors, it might get clipped away, so your idea of setting it to $z-offset$ should solve the problem.
Why it doesn't work is hard to tell without any code. Maybe your implementation of the perspective matrix is wrong. Maybe you have a hidden scaling when you transform between world and camera space. To debug this you can try to multiply $z$ with values between 0 and 1 until you get the desired result. The resulting factor might be a clue. For example if you get $0.5$ we know that there is either a 2 missing or too much in your transformation matrices. Also, make sure that your far plane value is larger than your near plane value (even though I think from your description that this isn't the problem - but who knows)
In case you are using OpenGL, here is a link to how the perspective projection matrix has to look like. Maybe you have to transpose the matrix. That depends on your vector layout - column vectors or row vectors.
Here is a link to an answer of mine to another question. It has a Python script at the end that you can use to visualize how the different values affect the view frustum in the different spaces. Some pictures are also included in the answer. Maybe that is already enough to help you out.


How do I interpret the format of the .flame files used by apophysis? I pulled a .zip file from https://www.deviantart.com/clairejones/art/Apophysis-Starter-Flames-V-67029474 and the file I was interested was the .flame file which contains parameters for several different Fractal Flames.

One of them looks like this:

<flame name="CJ_Starter_Flame_1" version="Apophysis 2.06c beta" size="640 512" center="0.536884822382779 -0.626382357937026" scale="764.167485097157" angle="1.82997772071605" rotate="-104.85" oversample="2" filter="1" quality="5" background="0 0 0" brightness="2" gamma="5" >
   <xform weight="0.5" color="0" linear="0.98505982500501" spherical="0.0149401749949902" coefs="0.047466 -0.574133 0.524841 0.137706 0.620555 -0.116118" />
   <xform weight="0.5" color="1" spherical="0.17593513103202" bubble="0.82406486896798" coefs="0.268823 -0.261644 0.261644 0.268823 0.204257 0.083402" />
   <palette count="256" format="RGB">
      253625384A3348593D5C664C6E685B7A7260827363938169
...
   </palette>
</flame>

Having read the original Draves & Reckase paper some of this is obvious.  The coefs= probably contains the parameters of the affine transform.  The thing that really confuses me is how a single xform clause mentions two variants, e.g. linear and spherical.  It appears that the values on each attribute sum to 1 so they are probably weights/probabilities.  But why are there two xform clauses?  Are they alternating weighted transform sets?

There is some information about the XML file format used for .flame files. There are a number of forks of this program written in different languages, the original site is by definition the place to go for answers; unless you are using a fork - the original  seems to have been abandoned years ago.

Coefs is 6 floats which defines the coefficients for the affine part of the function, in row order (a d b e c f). Xform has an interpolation_type which is a string describing the method for interpolation of xform positions: options are "log", "linear", "old", etc. (a list of a few dozen options is here). There can be multiple xforms, each applies a transformation to the previous state.

The spherical transform is complex, there's a 19 page .docx tutorial with 9 pages of examples at: "Understanding Spherical Transforms: Apophysis Tut" by UniversalKinase (direct link to .ZIP file). Another tutorial is "Apo-Tuto Sphericals" by Fiery-Fire.


Generation of stratified cosine weighted samples on hemisphere I have had luck with cosine weighted hemisphere samples, and I know how to generate stratified uniform samples, but I wanted to experiment with combining the two. However, how do I correctly stratify the hemisphere when performing the cosine weighted sampling? Do I cosine-weight the stratification? How many rays do I cast in each stratum?

My application is the collection of indirect samples in a lightmapper.

The classic method is to uniformly sample the disc at the base of your hemisphere and to project your samples upwards on the hemisphere (eg. compute z from x and y). This yields a cosine weighted distribution.

As the projection preserves stratification, you need only use stratified sampling of the disc to get a stratified cosine distribution.


Fading an object in add mode with correct color math I have a scene rendered entirely with objects with additive blend mode.  I have a value that is oscillating from 0, to 1.  When it is 1 the object is supposed to be invisible, 0 should be entirely visible.

However I have noticed that something seems off about it, specifically it stays dark for too long.  It is not my oscillating function, I suspect it having something to do with light using a logarithmic scale.

How would I convert my linear 0->1 value into a properly scaled value between 0->1

Fragment:

precision highp float;

uniform sampler2D s_texture;

varying vec2 v_texcoord;
varying float alpha;

void main()
{
    vec4 col = texture2D(s_texture, v_texcoord);
    gl_FragColor = vec4( col.rgba  - alpha);

    if (col.a < 0.001)
    {
        discard; //11.7->12.2
    }
    //gl_FragColor = vec4(0.4);

}

Vertex:

precision highp float;

attribute vec2 pos;
attribute vec2 tc;

uniform mat4 matrix;
uniform float time;
uniform float maxLeafs;
uniform vec2 position;
uniform float instance;
uniform vec2 anchorPoint;

varying vec2 v_texcoord;
varying float alpha;

vec4 finalTranslate(vec3 pos)
{
    return vec4(pos + vec3(position, 0.0), 1.0);
}
vec3 rotate(vec3 pos, float angle)
{
    float s = sin(-angle);
    float c = cos(-angle);
    return vec3(c * pos.x - s * pos.y, s * pos.x + c * pos.y, 0.0);
}
vec3 translate(vec2 pos)
{
    return vec3(pos - anchorPoint, 0.0);
}
vec3 scale(vec3 pos, float amm)
{
    return pos * amm;
}
void main()
{

    float v = log((time * 0.9) + 0.1);
    alpha = 0.0;

    float leafCoverage = (3.14149 * 2.0);
    float goal = ((instance) / (maxLeafs + 1.0)) * leafCoverage;
    float timeFactor = smoothstep(0.0, 1.0, time);
    float calculation1 = goal * timeFactor;
    float calculation2 = clamp(timeFactor * leafCoverage, 0.0, goal);

    float scaleFactor = clamp(smoothstep(0.0, 1.0, time * 1.2), 0.0, 1.0);

    gl_Position = matrix * finalTranslate(rotate( scale(translate(pos) ,scaleFactor) ,  calculation1));
    v_texcoord = tc;
}

Right now I am just taking the oscillating float time and passing it in directly, but eventually I will put it on a function so it fades in, temporarily is extra bright, then goes to the source texture.

Edit: I solved my problem, to my surprise the GLSL log function is in base e rather then 10.

Turns this was not an issue with the scale of the values passed in, just that the log function in glsl is base e.  The solution was merely to do log(stuff)/log(10) and that got the result of a base 10 log.


Blur with alpha transparency I'm writing a simple box blur for a graphics library.
The formula makes the average of a range of pixels by adding the ARGB amounts and then dividing by the blur range

For example, with a blur range of 3;

pixel1 FF FF 00 00 +
pixel2 FF 00 FF 00 +
pixel3 FF 00 00 FF
/ 3 =
result FF 55 55 55

Which is correct.
A typical result shows as;

However, I am having difficulty with coming up with a formula to blur an image with alpha transparency.
The formula above gives this result for a yellow box on a transparent background;

You can see that the yellow is surrounded by black colour - because the red and green are being diminished to 0. The result should actually look like so;

So; the formula of (pixel + pixel + pixel) / range is not working for alpha-blended images.

Can anyone please give a correct formula?

Thanks!

Two suggestions:

If your data is from an image you are displaying on a standard monitor, the chances are it is (or you are implicitly assuming that it's) in sRGB format. This means that the colour components are not linear. Ideally, you should first map into a linear colour space, do your filtering (e.g. blurring) operations, and then map back.
*(If you just want to try a cheap and cheerful approach, squaring each of the R G B components is not a terrible approach to "linearise" the values

obviously, use sqrt() to map back)*.
The alpha channel can be assumed to be linear.

Once in linear colour space, the next thing you want to do before filtering is to convert the pixels to a pre-multiplied-alpha format (AKA "associated colour").
Basically, given 8bpc {A,R,G,B} pixel input, produce  {A, A*R/255, A*G/255, A*B/255}.  You then do your averaging on this premultiplied data as above on all four channels, and then map back by dividing through by the resulting alpha (if A=0 then, choose, RGB=0).

This should produce a better result.
For more info I suggest reading through Jim Blinn's "Compositing, Part1: Theory".
Particularly, note the line "Additionally, we must use associated colors for any filtering or interpolation operations"

Update: Seems I've posted a similar answer before


Directly use Transform Feedback primitive count as instance count for drawing When using Transform Feedback to capture the vertices generated by the primtive generation stage, we can use glDrawTransformFeedback to directly draw the generated data without the need for querying the number of generated primitives and thus without CPU-GPU synchronization, which is especially useful with geometry shaders generating a possibly unknown number of primitives.

However, in my case I'm not using the generated primitive data per-vertex, but per-instance (it's basically a classic GPU-based instance culling scenario). So I need to supply the number of generated primitives into the instance count parameter of glDraw...Instanced. But the various Transform Feedback rendering functions only ever use the primitive count as vertex count and never as instance count. Now this does require me to wait for the transform feedback to finish and get the result of the corresponding query object, thus instroducing a synchronization point.

I considered that I could also use the quite powerful Indirect Rendering functionality and together with a Query Buffer Object route the result of the transform feedback query directly into the instance count field of the draw indirect buffer. But this has the problem that I'm not only issuing a single glDraw...Instanced call, but multiple different ones (each with their own state, per-vertex attributes and draw parameters, but all with the same instance count and per-instance attributes). So I would actually have to scatter the query result into multiple drawing parameter sets (though, possibly in the same buffer), probably by use of a compute shader. But this just seems like overkill to me.

So my question is, is there any other less involved way to just use the number of primitives/vertices generated from transform feedback directly as the instance count in (preferably multiple different) instanced rendering commands without the need to explicitly query that count onto the CPU? In light of GPU-based scene culling techniques I can't imagine this to be a rare use-case (but maybe in that case you just have to go the way over indirect drawing commands anyway). I'm not afraid of using extensions if available, so maybe there's some obscure little extension that does exactly that? Or I'm just missing something else obvious here.

The complexity of this makes it seem like you don't really want to use transform feedback; you want to use a compute shader. Then, through indirect rendering and SSBOs, you can write whatever vertex commands data you want.

The idea is that you have some number of indirect rendering commands (one command per set of instances). And for each instance you create, the CS invocation needs to bump the instance count of each of those commands (atomically, of course).

Now, because there are state changes between the commands, you wouldn't be able to use a multi-draw indirect command. But by using indirect commands and a CS, you can at least keep all of the data on the GPU, without having to do things like buffer copies to multiple locations.

Transform feedback is merely an ad-hoc mechanism for something that modern OpenGL allows you to just do directly. If you need to broadcast the "primitive" count to multiple locations (or really, if you're doing anything besides rendering the feedbacked data), then you should be using a compute shader, not TF.


Is it possible to directly generate mipmap levels of perlin noise? Say I'm generating some texture using perlin noise (or simplex noise, or any similar noise). Then I generate mipmaps to obtain minified versions of that texture...

My question is if it is possible to directly (and quickly) calculate lower LOD version of said noise at given position, without going through steps of generating high frequency noise first, and then generating mipmaps.

What about sums of noises at different frequencies and amplitudes that are often used?

I would say yes with a small asterisk.

When generating a perlin noise texture, using multiple of octaves of noise like you are talking about, the point of adding higher octaves (higher frequency lower amplitude) is to add high frequency details to the noise.

When making mipmaps of a texture, the point is to remove high frequency content that would cause aliasing at the resolution of that mip map level.

So, when making a specific mip level of a multiple octave perlin noise texture, you could find out which frequency would cause aliasing, and just use all the octaves up to (but not including) that point.

The result would be that you would have reasonable mips.

But, there are some reasons for that small asterisk:

The result you get would not be the same as if you mipped the image that has the highest frequency content.  This might not necessarily be a bad thing, because the usual way to make mips causes some bluring (a blur is a low pass filter) so you wouldn't have the bluring that comes with mips.  However, it's possible that a higher octave happens to add some lower frequency content than you'd expect.  Your lower mips, which could handle this frequency, would have that data missing unfortunately.
It might be that your octaves don't perfectly line up with the frequencies that your various mip levels can handle.  For instance, if an octave is just barely higher than nyquist frequency, you are going to miss out on some of the frequency components that the octave gave you.

Because of these two points, it might be more correct to process all octaves for each mip level, but to low pass filter the data for the octaves that are above nyquist.

That would be a lot more expensive than just omiting octaves at a cutoff point though (:


What if we don't mention Modelview and projection matrix? So I've been learning opengl for some weeks now and managed to understand all the viewing pipelines. As far my understanding goes we need to bring the object to world space and then the world space to view space. After that the clipping is done by any of the two projections as we want. The clipping volume is then sent to the viewport which is mapped to the screen coordinates.

Now when I write this simple basic code below I don't use any of the matrixmode
(GL_MODElVIEW or  GL_PROJECTION) but still the primitive is displayed on the screen. So what am I missing here?

and also an extension to this question I would also like to know what exactly means to bring the object to world coordinates in theory. Does it means overlapping the axes of the object coordinates with the world coordinates.

With lot of opengl discussions out there I don't know where to look. Would be extra nice if someone refer me to some good articles.

void Di()
{
    glClear(GL_COLOR_BUFFER_BIT);

    glBegin(GL_QUADS) ;
       glColor3f ( 1.0, 0.3, 0.2);
        glVertex2f( -0.1, -0.1 );
        glVertex2f(  0.1, -0.1 );
        glVertex2f(  0.1,  0.1 );
        glVertex2f( -0.1,  0.1 );
       glEnd();
    glFlush();
}

int main( int argc, char** argv)
{
    glutInit( &argc, argv);

    glutInitDisplayMode(GLUT_RGB|GLUT_SINGLE);

    glutInitWindowSize(500,500);

    glutInitWindowPosition(0,0);

    glutCreateWindow("First Program");

    glutDisplayFunc(Di);
    glutMainLoop();
}

Your screen isn't 3D, so how do you display 3D objects on it? You need to map 3D coordinates into 2D space. This also explains why your OpenGL code is not behaving how you're expecting it to. Sorry if parts of this answer are things you already know (just trying to be comprehensive).

What do the model view and projection matrices do?

The model view matrix is actually two matrices (multiplied together): the model matrix and the view matrix. This is important to understanding because these are two transformations into different spaces.

The model matrix transforms model space into world space. This means that say you have a vertex is at an offset from the center of a model. If you want that vertex to be in world space, it must use the scale, rotation, and position of the model to determine this. The model matrix accomplishes this.

The view matrix transforms the world space into the camera space. Does world move or does the camera move in a 3D application? Well, actually the world moves around the camera. The camera is always at the origin, so the view matrix moves the world to this point.

The projection matrix might be the trickiest to visualize. Screens are 2D (technicalities aside), so how do we show 3D objects here? A projection matrix converts 3D coordinates into 2D coordinates (with depth, so still technically 3D). You end up with Normalized Device Coordinates (NDCs). Each vertex on screen is represented by three values:
* x (horizontal) ranging from [-1, 1]
* y (vertical) ranging from [-1, 1]
* z (depth) ranging from [-1, 1]

Why don't you need model-view and projection matrices?

It's not that you don't need them, it's just that you are using as explained in the last step above. Otherwise, you are effectively just rendering 2D graphics. Right now you are drawing a quad.

Look at the coordinates that you are providing. You are basically treating the vertices as 2D vertices for 2D graphics since you are directly specifying their coordinates in NDC space. Remember, the coordinates you picked are between -1 and 1 for x and y, so you are effectively treating them as NDCs. You directly send them to the rasterizer in your example.

Further Reading

Tutorial 3 : Matrices | opengl-tutorial.org
Coordinate Systems | LearnOpenGL.com
OpenGL Projection Matrix | songho.ca