3ds max: Z-fighting when working with Large Objects

Unfortunately, I don't know how 3ds max handles its Z-buffer or its near and far planes so I can't give a definite answer. There are many ways the software could handle this.

However, you are on the right track. Z-fighting occurs when there is not enough numerical precision to distinguish two "objects" from the scene rendered at the same pixel. In such cases, the two pixels "fight" one another over which one is closest to the camera and flickering occurs.

These factors influence how a scene is susceptible to Z-fighting:

Number of bits used by the depth buffer (typically 24 or 32).
Whether the depth buffer uses float values or integers.
Whether the Z value 0 is used for the near or far plane (inverted depth buffer).
How close objects are to each other.
The size of the range between the near and far planes.

Of these, you really only have control over the near and far planes from what you say.  It looks like your model is too big for the default way 3ds max handles this so I suggest making the near plane value bigger. An increase of the near plane from 0.1 to 1.0 (*10) will give the same precision increase as dividing the far plane by 10.

For your other question, you usually get less Z-fighting when an object is closer because there is more precision in the depth buffer closer to the near plane.

Also, for your other question: Why do GPUs divide clip space Z by W, for position?

A nice Z precision visualizer: http://dev.theomader.com/depth-precision/


How can I resize a rendered ray traced image?

Since you want to downsample the image by a factor of 2 along each axis, a simple and easy thing to do is just average a 2×2 box of source pixels to generate each destination pixel. In pseudocode this would look like:

for dest_y = 0 to 540
    src_y = dest_y*2
    for dest_x = 0 to 960
        src_x = dest_x*2
        average = 0.25 * (src[src_y][src_x] + src[src_y][src_x+1] +
                          src[src_y+1][src_x] + src[src_y+1][src_x+1])
        dest[dest_y][dest_x] = average

This will do an okay job, but for higher-quality downsampling or resizing images to any size (not just neat integer factors), I suggest looking at the stb_image_resize library. It's quite easy to use, supports either 8-bit or floating-point images with any number of channels, and gives good results.


Why are BRDF and the lighting uncorrelated?

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

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

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

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

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

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

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


What is the mathematics behind inkscape's power stroke path effect interpolator_type and interpolator_beta attributes?

Not a direct answer, but I can shed light on adding and removing pink control points using the GUI:

initially PowerStrok gives you 3 pink control points.
CTRL-Click on one of them duplicates it. Drag it along the path to a new position.
CTRL-ALT-Click removes the clicked one (don't remove all)
ALT-Click on a pink control point opens a text entry for exact coordinates.


Can Frameless rendering reduce latency? And, can FPGA do 3D rendering instead of GPU?

First of all, the "frameless rendering" technique is in the context of raytracing, not rasterization. It's not obvious how it could be made to work effectively with rasterization, given that the basic idea of it is to update an image by a combination of temporal reprojection plus firing rays specifically at areas where the algorithm thinks the image is undersampled.

So this technique is, prima facie, not compatible with rasterization-based graphics applications. But if you're already doing raytracing for other reasons, this technique would be interesting to look at; it certainly appears to improve quality relative to an image raytraced from scratch each frame, with the same number of rays per second.

Raytracing on a GPU is certainly possible; you don't need an FPGA for that. I've only skimmed the second paper, but my reading of it is that the main reason for the FPGA is to get a close coupling between the display scanout and the rendering activity: namely they "race the beam" and evaluate pixels just before they're about to be scanned out, thus obtaining low latency.

The GPU equivalent of this is probably to split the image in thin horizontal strips, and kick off a compute dispatch to render each strip just before it starts to be scanned out. Today, this is difficult to accomplish as it requires either millisecond-precise scheduling that desktop OSes are not currently set up for, or it requires the GPU to be able to dispatch based on an interrupt from the scanout unit—a hardware feature that doesn't currently exist AFAIK (or if it does, it isn't exposed in any graphics APIs). Or you might be able to make it work with a long-running asynchronous compute dispatch, if you can find a way to stay in sync with scanout.

So, there are obstacles, but they aren't insurmountable, and I think if there was sufficient interest in racing-the-beam-style rendering, then OS and GPU vendors could come up with a way to do it in the future. So I don't think an FPGA is required for this kind of technique to work. On the other hand, the fact that it's based on raytracing is a much bigger obstacle to using it in "real-world" apps and games.


getting the outline of an arbitrary set of shape unions

Draw it twice, first time at full size and the color you want for the outline, draw it filled. The second time you draw it scaled down in both the x and y directions. The second time you draw it the color is the same as the background color, and draw it filled again. What will be left is the outline. Is this what you had in mind?
Per your comment, I add more info:
Generating an array of exterior edges can be done in a few ways. The easiest one to implement (but also the slowest) is to count the number polygons that share a given edge. The exterior is all the edges which only have a single polygon using that edge. And the two vertices that make up that edge become part of the array of "lines"( an actual line can be computed from two vertices). Also, this will count "holes" as part of the exterior. For example if a building surrounds a courtyard, then the courtyard would be counted as exterior.
This can be implemented by creating an array of unique vertices, then each polygon is formed by indexing into the list. (just like indexed triangle draw lists). Finally pick a single polygon off the list, takes its first edge, and search all the other polygons for that edge.
Another method using a doubly connected edge list is given here.


Human Readable/Writable 3D Representation Formats/Languages?

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

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

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

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

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

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

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

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

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

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


How do you load multiple textures into an array texture with OpenGL?

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

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

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

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

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

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

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

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


What is the most physically accurate model of surface materials possible in computer graphics?

BRDFs are not accurate for any dielectric surface, as all of them have some degree of subsurface scattering. A BSSRDF is also just an approximation based on the assumption of a semi-infinite slab. Ideally, you'd run a volumetric path trace for all surfaces, which would be much more accurate than BRDFs or BSSRDFs, but significantly more expensive. Although, Disney has already used brute force path tracing over BSSRDFs in production, see the SIGGRAPH 2015 course notes, section 2.5.


Is there a image-format that support an array per pixel?

OpenEXR might be a good fit. You can have an arbitrary number of channels per pixel and the data types for each channel can be integers.

http://www.openexr.com/


The problem is, glVertexAttribPointer(0, 4, GL_DOUBLE... doesn't do what you think it does.

Using actual double-precision vertex attributes and performing double precision computations is a very modern hardware feature (GL4/DX12) and is different from specifying the type GL_DOUBLE in the good old glVertexAttribPointer call. This always worked and does nothing else than specify the input type, i.e. the type of your vertex data in memory. All it does is make the GL convert your doubles into singles and feeding them into a normal single-precision attribute (and failing when there is none), same with other input types like GL_SHORT or GL_UNSIGNED_BYTE.

When specifying data for genuine double-precision attributes, you have to use glVertexAttribLPointer (note the L) instead. The same holds for genuine integer attributes (ivecX/uvecX), which use glVertexAttribIPointer.

Of course the answer isn't complete without some general advise, that you should really make sure you actually need double precision vertex attributes, or even double precision computation. Even on modern hardware that's still significantly slower and not what those GPUs are really made for, not to speak of the doubled memory consumption for the vertex data. More precision is not always better if it isn't actually necessary and you might be surprised what a lousy little float is able to accomplish when used well.


Assuming you use this structure within an actual UBO (which your example code doesn't do), just use an array of ivec4 and two indices.

const ivec3 cluster_max = ivec3(16, 8, 8);
const int cluster_max_lights = 4;

const int plix_count = cluster_max.x * cluster_max.y * cluster_max.z * cluster_max_lights;
const int plix_index_size = pl_count / 4;

const int plpt_count = cluster_max.x * cluster_max.y * cluster_max.z;
const int plpt_index_size = plpt_count / 4;

struct GlobalShaderData
{
    ivec4 pointLightIndices[plix_index_size];
    ivec4 pointLightsPerTile[plpt_index_size];
};

layout(std140) uniform shaderData
{
    GlobalShaderData globalShaderData;
};

To access a value from the arrays, you will have to divide the index by 4 to get the ivec4 index, then take the original index mod 4 and use that to index the ivec4.
To get the


Since you've used the "path tracing" tag, I'm assuming you're thinking mainly about light transport. At SIGGRAPH 2015, there was a course on the topic of path tracing in movie production that may be interesting:
https://sites.google.com/site/pathtracingrevolution/
Some of the presenters point out unsolved challenges towards the end of their presentation, for example see the second to last slides in the presentations from Alexander Keller and Johannes Hanika.

Then there are challenges in rendering that are not necessarily tied to path tracing but also present in game engines. Triangle meshes as an approximation of smooth solid surfaces are one, the use of shading normals or even worse, bumped normals have been pointed out as a source of artifacts a long time ago: "It's not really a rendering bug, you see..."


How to change a picture to fail comparison algorithms?

It's dependent on the algorithm used for comparison, but if you have access to that algorithm, you can add small amounts of noise to pixels randomly until it misclassifies the image.

If you had deeper knowledge of the algorithm used, and it was differentiable, you could use gradient descent (ascent) to modify the image to increase the error of what was detected. This is the reverse of what you do when training image comparisons/classifiers which modify the weights to minimize the error.

But in short, if you dont have much knowledge of how the algorithm used works, I personally would try adding noise to pixels randomly, such that the image was still easily recognizable, but a decent amount of noise was added in.


Existing method to automatically fill in this sort of concavity in meshes?

After a fair bit of reading and skimming through papers, I have yet to find a good definition other than "indent" for what I want to remove, but I have found answers to pretty much everything else.
The concept of a "Visual Hull" is what I was looking for regarding a mesh that doesn't have these indents. While the Wikipedia page, and a bunch of other resources, usually just refer to visual hulls created from a finite set of viewpoints, e.g. a set of real-life cameras, Laurentini, who introduced the term "Visual Hull", also introduces a term "External Visual Hull" to refer to one created using every possible viewpoint outside of the convex hull [1]. This will have the exact same silhouette as the original mesh when viewed from any position outside the convex hull at any angle, so it was exactly what I was looking for.
[1] also contains an algorithm for computing the external visual hull for polyhedra, but it is sorta brute-force and is $O(n^{12})$. In [2], Petitjean introduces a much more efficient algorithm for polyhedra, and Bottino and Laurentini also describe a more efficient algorithm in [3]. In addition to these algorithms for polyhedra, other works by Laurentini also discuss algorithms for doing the same for curved objects, surfaces of revolution, etc. I have yet to come across anyone actually implementing these algorithms, though.
I'd like to describe all of these in more detail, but I still need to finish reading through them, and based on some deadlines coming up, I do not think I will have the time to do so for a little while. I hope to eventually come back to this post and edit it to actually describe at least one of the algorithms. However, if someone reading this wants to look these up for themselves, then in addition to the below citations, I would like to note that even if you don't normally have access to papers, e.g. through a post-secondary institution, all of these seem to be publicly available. You can download [1] from ResearchGate here, download [2] from ResearchGate here (though I have no clue why different authors are listed for it than Petitjean), and [3] can be found in Google Books.
Citations:
[1] Laurentini, Aldo. (1994). The Visual Hull Concept for Silhouette-Based Image Understanding. Pattern Analysis and Machine Intelligence, IEEE Transactions on. 16. 150-162. 10.1109/34.273735.
[2] Petitjean, S. (1998). A computational geometric approach to visual hulls. International Journal of Computational Geometry & Applications, 8(04), 407-436.
[3] Bottino, Andrea & Laurentini, Aldo. (2006). Retrieval of Shape from Silhouette. 10.1016/S1076-5670(05)39001-X.


An Effective way to explain Ray Tracing?

Here's my introduction: http://www.gabrielgambetta.com/computer-graphics-from-scratch/raytracing.html It uses the somewhat contrived analogy of making a painting by putting a grid in front of a real landscape, and painting a square of the colour you see through each hole in the grid. A raytracer is essentially that, but with some linear algebra :)


How does opengl fixed function pipeline determine specular lighting with an orthographic projection

This isn't necessarily due to the orthographic projection per se, but rather the classic two-sided lighting problem together with a little optimization that the old OpenGL did. When the eye space origin is inside the object, you are basically looking at the object from the inside and it's only the peculiarities of orthographic projection and the near/far planes you chose that makes the outsides appear.

It depends on how you actually implement your shader. I assume though, when you compute your viewDir, you just use the vector from the eye space vertex to the origin (or rather the negative normalized eye space vertex position). You are basically trying to light the backfaces of the sphere and if you haven't taken account for that, the angle between the view vector and the normal will thus be larger than 90°, usually resulting in a negative or 0-clamped specular term (or whatever other unexpected results).

A common way to accomodate for that would be to negate the normal vector whenever it is facing away from the camera, or maybe the light, or when dealing with backfacing fragments,... But this depends on your specific use-case.

Now, why doesn't this happen in old deprecated OpenGL when using orthographic projection?

For this we have to look at the specificities of how it did its lighting computations. There was a function glLightModel which controlled some of the global properties of lighting computations. Specifically, the paramter GL_LIGHT_MODEL_LOCAL_VIEWER. This controls an optimization where the specular computation does not use the actual vector from the vertex to the camera, but always just uses the z-axis instead. i.e. as you said it assumes an infinitely far away viewer along the z-axis. This is the reason why even in perspective projection the specular highlight on an object is always at the same position, even if you move it around in the view. If you change this setting from the default of GL_FALSE to GL_TRUE, it should perform an actual view vector computation and you should get the same results as with your own shader.

There was also another option that controls a property related to your general issue, too. GL_LIGHT_MODEL_TWO_SIDE enables two-sided lighting, which means that back-facing polygons will be lit like their front faces (however, possibly using different material settings) by using the inverted normal. If you activate this, this still won't change anything in your orthographic scene, since you are seeing the front faces of the sphere here. But once you change to perspective projection, the lighting should be black, but this time because you're seeing the backfaces, which you can enable lighting for with this option.


How to decide which way to triangulate a quad?

A simple heuristic that many 3D content creation apps use is to split along the shorter of the two diagonals of the quad. This generally seems to work pretty well. It minimizes the appearance of long, skinny triangles, which are generally undesirable both for visual and performance reasons.
See this article: Deformation and Triangulation in Maya for some further discussion. In particular if you have a dynamically deforming mesh, you ideally want to retriangulate the quads based on the deformed geometry each frame, or you can get some pretty wonky artifacts if you stick with a fixed triangulation:

(image from the above linked blog post)


Adding vbos to a vao once it has been created

So after debugging some more, I've found that yes it is possible. You cam add buffers later on but they will need to point to their own attributes.

My issues came from thinking I could have multiple vbos contributing to a single attribute. That doesn't work. You need multiple vaos for that scenario.


Shader compilers are extremely aggressive about unrolling since early HW often didn't have flow control and the cost on more recent HW can vary. If you have a benchmark you are actively testing against and a range of relevant hardware, then try things to see what happens. Your dynamic loop is more amenable to developer intervention than a static loop - but leaving it to the compiler is still good advice unless you have a benchmark available. With a benchmark, exploration is worthwhile (and fun).

BTW, the biggest loss with a dynamic loop on a GPU is that individual "threads" in a wavefront/warp will finish at different times. The threads that stop later force all the ones that finish early to execute NOPs.

Nested loops should be carefully thought through: I implemented a block based entropy decoder that encoded runs of zeros (for JPEG like compression). The natural implementation was to decode the runs in a tight inner loop - which meant often only one thread was making progress; by flattening the loop and explicitly testing in each thread if it was currently decoding a run or not, I kept all threads active through the fixed length loop (the decoded blocks were all the same size). If the threads were like CPU threads, the change would have been terrible, but on the GPU I was running on, I got a 6 fold increase in performance (which was still terrible - there weren't enough blocks to keep the GPU busy - but it was a proof of concept).


Ray Tracing with Cones: coverage, overlapping and abutting triangles

I did implement a ray tracer based on Amantides' work but, as that was  years ago, my memory of the paper is a little rusty.

However, ignoring this particular case, in general when it comes to working with fractional coverage e.g. Alpha compositing, (see "A over B") my understanding is that the usual assumption is that the items being composited are uncorrelated.

Thus if A with X% coverage is on top of B with Y% coverage and C in the background, then it's assumed that one will see
    X%*A + (100-X%)*Y% * B + (100-X%)(100-Y%)*C

Does that make sense? Obviously this will give "leaks" in the case where A and B are strongly correlated.

I think I might have put a small bit mask on the rays to avoid these problems, but it was a very long time ago.


Each channel ranges not from black to white, but from off to full intensity. What colour is meant by full intensity is down to convention and the presentation technology.

For example, a given image file format might say there are three bytes, of which the first is the red channel, the second is the green channel, and the third is the blue channel. There are many different colours, so to be a real standard, it has to say exactly what that "red" means, usually by reference to a particular colour standard such as sRGB or CIELAB. These international standards provide an absolute way to describe colours.

After some processing, your red, green, and blue values find their way to your LCD monitor. There, the electronics uses them to control the intensity of three sub-pixels: one of which is a red filter, one a green filter, and one a blue filter. The 0-255 value in the red channel is turned into some voltage which controls the transparency of the liquid crystal behind the red filter, turning it from completely opaque at 0 to lets all light through at 255. Since this is attached to a red filter, it contributes black or red to the image.

The same idea is everywhere in computers. The only things inside a computer are numbers. They only mean what we say they mean because of conventions (all software interprets them the same way) and/or because they control some values inside some output hardware. e.g. one number means the red channel in a pixel on your screen, another number means a letter of the alphabet in an email, another number is a pressure sample in an audio file which will be sent to your sound card and control the voltage to a speaker, and so on.


CPU load in games - what is the GPU/DirectX doing to make CPU load higher?

The most likely explanation is that the game is GPU-bounded and not running at a fixed frame rate. If reducing the quality in the settings allows the game to reach a higher frame rate, the GPU load will be the same, but the CPU load will increase: the CPU is doing the same amount of work per frame (or possibly less), but there are more frames per second, so the total amount of CPU work per second increases. If the game does some non-graphics work per frame as well (for example, if physics updates are at the same rate, or if input is polled once per frame), the effect will be even greater.

Forcing rendering to a fixed frame-rate would allow a controlled comparison.

Your hypothesis about software emulation of features may apply to some features in some games. A particular hardware feature might be exposed as an option because it's slow on some GPUs, and turning the feature off uses a CPU implementation in the game instead. If you have more specific questions about that, be sure to ask a new question which includes the source code you're working on and the benchmark results.


How should I fill a shape consisting of Bezier curves and straight lines?

If you are in a hurry to get your renderer working and you already have the filled polygonal routine functioning correctly, can I suggest an alternative, possibly easier approach? Though I'm not familiar with Lua, it seems you are solving for the exact intersection of a scan line with the quadratic Bezier which, though admirable, is possibly overkill.

Instead, tessellate your Beziers into line segments and then throw those into the polygon scan converter. I suggest just using (recursive) binary subdivision: i.e. the quadratic Bezier with control points, $(\overline {A} , \overline {B} , \overline {C})$ can be split into two Beziers, $(\overline {A} , \overline {D} , \overline {E})$ and $(\overline {E} , \overline {F} , \overline {C})$
where
$$
\begin{align*} & \overline {D}=\dfrac {\overline {A}+\overline {B}} {2}\\ &
\overline {E} =\dfrac {\overline {A}+2\overline {B}+\overline {C}}{4}\\ &
\overline {F}=\dfrac {\overline {B}+\overline {C}} {2}
\end{align*}
$$
(which is also great if you only have fixed point maths).

IIRC, each time you subdivide, the error between the Bezier and just a straight line segment joining the end points goes down by a factor of ~4x, so it doesn't take many subdivisions before the piecewise linear approximation will be indistinguishable from the true curve. You can also use the bounding box of the control points to decide if you can skip out of the subdivision process early since that will also be a conservative bound on the curve.


How to implement a realtime 2D light renderer with fog/colored light on the GPU?

If your wall geometry is vector graphics you can simply extrude the segment away from the light position. This means 2 triangles per draw call, all the extrusion offsets can  can be handled in the vertex shader.

Image 1: For each wall generate a shadow volume extrusion.

Quick and extremely dirty sample implementation of shadow volumes here:

http://webglplayground.net/saved/AeN6yoNGih (please do not save your own version, fork instead)

Now since your shader can color the triangles as they see fit you can apply a shader on the triangles that is colored. Just like you would render transparent surfaces. To do this proper you may need a offscreen buffer for getting a proper color accumulation mode.

Image 2: Coloring the volumes based on distance to light.

Certainly the coloring algorithm may be whatever you like. for example the color could become darker the nearer you are to the extrude edge etc.

And here is very quickly done extremely dirty live example of colored shadow volumes:

http://webglplayground.net/saved/9xgxDbtY7f (please do not save your own version, fork instead), very bad code style done on the run (and on my phone).

This is just one way hopefully others will elborate. You can also use the exact same methods as you would in 3d. As for nonuniform fog, you could just use a raymarcher.


Origin of blurring and colour distortion in monochrome diagrams

This looks like JPEG artefacts so I guess the image went through a JPEG compression step at one stage and that permanently introduced noise into the image. The red channel is blurred stronger because JPEG additionally applies chroma subsampling.

I suspect the original image was subpixel rendered as you shouldn't really have anything in the chroma channels for a monochrome input image.


is focal length equal to the distance from the optical center to the near clipping plane- openGL

For some reason most sites choose to leave the projection plane out of the visualization of the view frustum. The focal length often labeled "g" is the distance from the camera to the projection plane. The projection plane (which is blue in the attached image) is almost always placed at a distance from the camera such that the distance from the center to the top and bottom is 1. This image from the fged website shows it well:  This choice is a matter of convenience since it makes the math all work out nice and neat. As you can see the near plane can, and often is, behind the projection plane. (the green plane in the image is the near plane)
For your second confusion: One goal of the projection matrix is to force coordinates with a z value less then that of the near plane to fall outside of the near clipping region which is -1 in OpenGL. So any coordinate that has a z value less then near value will result in a z value below -1 after projection.


There does not seem to be a single answer for this question, but I will try to give some directions in possible solutions. First of all I presume that "the scene graph technique" means storing the object data in some kind of data structure (I know what a scenegraph is, but there are many different possibilities for indoor/outdoor scenes etc). There seem to be some Javascript libraries, but they do much more then simply providing the datastructure.

For defining the scenegraph structure you could look at glTF(https://github.com/KhronosGroup/glTF) defined by Khronos themselves. This really depends on what kind of features your scene graph requires.

If the C++ library is required for the processing you can look into providing Javascript bindings for it. You can either try to compile the library to javascript using emscripten (https://github.com/kripken/emscripten). Otherwise provide a C-interface and call it directly using ccall(). This way you can directly share this datastructure via parameters.


Matching an HSV color with a blended color

The opacity acts linearly through the colors, i.e. it affects R G B similarily, so it should affects the value V the same way.
You just want to have an intensity factor decay as $0.95^n$.


Yes, there is a better way!  OpenGL 4.3 and later support the glDebugMessageCallback API, which allows you to specify a function in your app that GL will call to issue a warning or error. In this function you can do whatever you like, such as setting a breakpoint in the debugger, or printing the error to a log file. This way you only need to setup the callback during initialization—much nicer than putting glGetError calls everywhere.

To turn on this functionality your GL context also needs to be a "debug context", which is specified by setting a flag when you create the context. The details will depend on which OS / windowing system / framework you're using. A debug context might be slower (on the CPU) than a regular context, but that's the price you pay for more detailed debugging info, kinda like turning optimizations off in the compiler.

See also this wiki page for more information. There's a bunch of other debugging-related functionality. For instance you can give human-readable names to textures, buffers, framebuffers, etc using glObjectLabel, which will then (I assume) be used in error messages. There are also APIs for turning off certain messages or categories of messages, in case you get spammed by warnings that you don't care about or some such.


2D Line of Sight + Visibility Calculations

In this SIGGRAPH paper is described a similar operation for the visibility calculation from every pixel in the domain (you only need calculate it from actors position), which has been implemented in GPU.

Although it is oriented to fluid dynamics, it may be a starting point to look.

You can see other related shader examples like this one with implicit geometry.


How to rotate an object around any axis if i have just local x and y?

If you know how to make a rotation matrix from X,Y,Z basis vectors (just make them the rows or columns, depending on whether you are using a row or column major matrix), you can do that, using the cross product of X and Y to get the Z vector.

The order of X and Y in the cross product depend on whether you are using a left or right handed coordinate system, but if you are unsure about this, you can check if doing Z=cross(X,Y) looks right and if not, switch to Z=cross(Y,X).

So, it'll be something like this:

// May be Y,X instead, depending on your handedness
Z = Cross(X,Y);

// May need to be transposed based on you using row or column major matrices
RotationMatrix = MatrixFromRows(X,Y,Z);


A literal triangle, as in 3 vertices connected by 3 edges.

They are the basic building block for any other shape, any polygon can be represented with a set of triangles (called triangulation).


Is There an algorithm to remove intersections between two tetrahedrons?

Since you already have convex shapes and started looking at the "Method of separating axis", then the GJK algorithm is probably what you're looking for. This is commonly used in physics simulations to find collisions (for games, I don't know about computational science).
When you say "remove intersections without generating others", then you're asking for collision response. Multiple collision response is actually a tough beast. Here (Reflections on Simultaneous Impact) is a paper that goes into more detail, but a very good introduction to this are course notes from Baraff:
An Introduction to Physically Based Modeling: Rigid Body Simulation I—Unconstrained Rigid Body Dynamics and part 2. Rigid Body Simulation II-Nonpenetration Constraints
Lastly, you can always use a physics engine for this, such as Bullet3d.


What is principal vanishing point in perspective projection?

Basically whenever you project a set of parallel lines in 3D space on a 2D image plane, you'll see that these lines don't remain parallel in 2D space and tend to meet at a certain point which is the so called vanishing point. Picture a long railway, both the rail lines meet at the horizon.
Now one confusion arises that the question doesnt give you a set of parallel lines, But it doesn't matter as long as a single line segment is provided. All you need to do is just picture the line segment extending to infinity. So for example, picture the point $B$ at infinity and imagine drawing a line $BE$. The point at which this line intersects the image plane will be your vanishing point.
There is a simple pattern that applies to every case like this. Just shoot a ray in the direction of the vector $\vec{AB}$ from the point $E$. The point at which this ray intersects the image plane will be your vanishing point which as you can see is $(0,0,0)$.
Now imagine why this works. Picture the point $B$ extending up, and at each instance start drawing segments $BE$. You'll see that this line segment is moving towards the $Z$ axis.
So if you are projecting a point $B$ at infinity then the projecting line or segment $BE$ gonna become parallel to the line $AB$. However, it can't go past the $Z$ axis, as this will start going in the opposite direction.


If silhouette is not important, you could bend the shading normal near edges.

Since it's a cube you can probably compute the normal procedurally in the shader based off of the uv. I.e. if uv is in range [0,0.1] or [0.9,1.0] start bending the normal towards horizontal.

If silhouette is important, drawing a rounded cube model with vertex normals would make the most sense. There are cube models which have the beveling to look like a rounded cube.


Reading from buffer versus calculating on the fly performance

My question is, though i am aware cos() and sin() is fast, how do they compare to simply getting the value precomputed in a buffer instead?

This will depend on your shader code and GPU model.

GPUs utilize latency hiding by executing independent ALU instructions while waiting for data to arrive from memory.
Accessing memory is usually the slowest operation on a GPU.

If your shader code allows for latency hiding, it may be faster.
The best option here is to profile the shader performance.

I don't know how to really bench test shaders properly so i am unsure which is faster.

I think the easiest way would be to download RenderDoc and get a frame capture of your application.
After that, you click on the timing icon (shown red) to get some measurements.

Although these are not super accurate measurements, they're good enough and sort of representative of the application performance.
For precise measurements, you'll need your GPU vendor's graphics profiling tools.

AMD has Radeon Graphics Profiler (RGP)
NVIDIA has NSight
INTEL has Graphics Performance Analyzers

Update: Below are some captures from RGP, showing GPU assembly instructions and instruction timings of various instruction types. You can see latency hiding in action below:

vmem : texture read
smem : constant buffer / descriptor<texture/buffer> read
ALU  : math ops (arithmetic / logic)
sync : waits for vmem/smem instructions to finish loading data from memory

Another capture showing instruction timings while first two texture loads not having latency hiding.


From the GIMP docs:

IIR
IIR stands for “infinite impulse response”. This blur works best for large radius values and for images which are not computer generated.
RLE
RLE stands for “run-length encoding”. RLE Gaussian Blur is best used on computer-generated images or those with large areas of constant intensity.

and also

They both produce the same results, but each one can be faster in some cases.

So the short answer is that IIR is optimised for photographs, and RLE is optimised for images with areas of flat colour.
The claim seems to be that the only difference is the time taken to calculate the blur, and that the end results are identical. I haven't tested this, so if you need to rely on that claim you should test both and check for any differences in the results.


It is not generally useful to try to optimise small parts of a program before you have profiled the program to see where the most benefit can be gained by optimisation. Make sure everything is correct and working first, and then profile to decide where to optimise (if optimisation turns out to be necessary).

Mathematically, your approach is already correct for all lines. It will correctly identify all lines parallel to either axis, and it will not incorrectly identify any lines that are not parallel to an axis. However, for use in a practical setting, it's worth asking yourself about near-parallel cases and any odd exceptions. Consider all this before even thinking about optimisation, otherwise you may have to repeat all the optimisation later if something you have to change for correctness breaks your initial optimisation.

One case to consider is when both the coordinates are identical. That is, the end points have the same x coordinate and the same y coordinate. This is a  degenerate case that doesn't define a line (it could have any direction). Check your implementation with this case and make sure it gives the output that you want it to.

Depending on your purpose, you may want to detect only exactly parallel lines, or you may want to detect lines that are sufficiently near to parallel. In some cases lines near to parallel may satisfy your purpose, and in other cases it may be essential to accept lines near to parallel, if for example there is the possibility of small inaccuracies in the coordinates.


Is there a difference between window and screen in computer graphics?

In this code, the "screen resolution" means the number of pixels in the output image (which happens to be a window in the windowing system), while the "window dimension" means the corresponding size in the 3D scene. Computing s tells you the ratio between one unit of 3D space in your scene and one pixel of output image. You need to do this in order to know how far apart in world-space to cast your primary rays.

These uses of "screen" and "window" aren't standard; they're specific to this code. No wonder you're confused.


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


How can an OpenGL visualization run for weeks?

Opengl doesn't care how long it has been running.

However there are a few other challenges with long running applications in general:

memory leaks, both normal ones and opengl resources.
lack of precision after incrementing a float to a big number. After 4 weeks your millisecond counter will be at 2.4 billion which is well beyond the point where integers cannot be expressed exactly in a single precision floating point number. Make sure that those numbers are wrapped down to a smaller value explicitly.


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


How to interpolate vertices when clipping?

Points in front of the camera have $w > 0$ strictly, by definition. I would say that if clipping is giving you points with $w = 0$ then something is going wrong.
Consider the left/right/top/bottom clip planes. There is no way that a triangle can span from part of the visible frustum, to the $w = 0$ camera plane or behind it, without also crossing outside one of the frustum side planes—or else the near plane, which lies at some positive distance $w_\text{near} > 0$.
You mentioned skyboxes and setting $z = w$ in the vertex shader output. Such geometry must cross the frustum side planes before it can get to the near plane. (How could part of a skybox get close enough to the camera to be clipped by the near plane only?) If you are correctly clipping it against all of the frustum planes, you must end up with $w > 0$ in the final vertex.


Dealing with interpolated normals within a raytracer

Disclaimer: It's been a long time since I looked at this sort of thing but here goes...
Disclaimer2: On re-reading your question(s) I realised I might have misunderstood what you were asking. I'll leave this here just in case you were looking for this sort of reply.

Are you rendering from the original Bezier patch definition (e.g. https://www.cs.utah.edu/gdc/projects/alpha1/help/man/html/model_repo/model_teapot/teapot.pts)  or from a (post tessellation) triangle representation?

If the former, then you should, in the vast majority of cases, be able to 'trivially' generate the normals directly from the Bezier representation, by computing surface partial derivatives at each ray intersection point, to give tangent vectors, and computing the cross product. The cases you do have to watch out for are at very centres of the bottom and top of the teapot where the patches, though geometrically well-defined, have a zero partial derivative because the rectangular patch has been squeezed into a triangle, e.g. control points for U,V = (0,0), (0,1/3), (0,2/3), (0,1) are all identical, so dPos/dv is 0.  All you need do is compute dPos/du at (0,0) and (0,1) to get valid tangents.

If you are rendering from triangles, I assume you already have normals at the triangle vertices. If you use an appropriate ray-triangle intersection test you can get the barycentric coordinates of the intersection point. Use these to blend the vertex normals (and after renormalising) you'll have a 'reasonable' surface normal (though it will only be C0 continuous).


library / tool for implementing algorithms

If you're completely new to graphics programming I would start with Processing. It's based on Java and JOGL but comes with a whole bunch of drawing commands built in, and its own basic IDE. It's very good for prototyping algorithms and getting quick visual feedback without having to write a ton of boilerplate code, and it insulates you from the underlying API (OpenGL in this case). Presumably you're not going for high performance, since the algorithms you mention are efficiently implemented in hardware, and you just want to familiarize yourself with how they work? If so it's a great place to start.

Once you've got the hang of Processing you can move over to OpenFrameworks, which is very similar but in C++, with the option to 'drill down' and call the underlying OpenGL commands directly. From there, the sky's the limit. :-)


Probability density for explicit light sampling

It comes from the relation between the area formulation and the solid angle formulation of the rendering equation: $d\omega = \frac{\cos\theta_L}{r^2}dA$:
https://arxiv.org/abs/1205.4447


transformation from cartesian coordinates to spherical coordinates without calculations

If we take some ring around the sphere such that $\theta=const$, we can see that such a ring transforms into a line on the polar space.

Converting every possible ring to the polar space gives the desired surface. However this would involve computing many different values to get an approximation or doing some algebra, which we don't want. (I'm assuming you want to keep mathematical notation to a minimum here). However we can get a pretty close idea by figuring out just a few easy to compute values.

Now. If we grab the ring that goes around the center of the sphere and transform that one, it is clear that it ends up as a line with $\theta=45^o$ and $r=\sqrt{2}R$ (that is because its vertical distance from the origin equals its horizontal distance at every point).

There are two more rings that are useful to us here: the two very small rings around the poles of the sphere.

The ring around the bottom pole transforms into a line with $\theta=90^o$ and $r=0$.

The ring around the top pole transforms into a line with $\theta=0^o$ and $r=2R$.

We now have three lines through which we can fit our surface. You can do this with pen and paper. I'm not quite sure of what kind of curve you end up with (I haven't done the algebra haha) but my guess would be some kind of sideways parabola.

EDIT: I did the math, $r=2R\cos(\theta)$

NOTE: I measure my $\theta$ as the angle between some line crossing the origin and the Z axis


How to visualize and programmatically work with huge point cloud

Depends how 'deep' you want to go.

With Unity/Unreal doesn't have to be 'programatically' - they do have GUI, you can just load your data with few button clicks. Potentially you could parse/convert your data to readable format obj might be easiest with for eg. python.

So not sure what programming language you have in mind but as you are mentioning some python modules I guess python.

Then you could display it in many different ways.

OpenGL (there are many Python bindings over the internet, check them out and choose one that suits you best)
Matplot, pygraph and similar also have an ability to plot in 3D
explore pandas as it is a great python library to deal with this types of datas

And for eg. you could put it all together inside a QT


Thorough, accessible material about Fourier basis functions and Spherical Harmonics?

wil, you largely have enough scholar background, you must have done Fourier and Laplace transforms in second year, and maybe in your engineering school again as part of signal processing classes.

If you read "stupid tricks" there is not much more you can do to find a condensed course at this point.

The second most famous paper that goes with SH for graphics is by Robin Green called "the gritty details":
http://www.research.scea.com/gdc2003/spherical-harmonic-lighting.pdf

And the third most important is the one by Ramamoorthi (the original paper preceding "An Efficient Representation for Irradiance Environment Maps"), which was called On the relationship between radiance and
irradiance: determining
the illumination from
images of a convex Lambertian object

And I think they mention somewhere that SH were previously most used by another science field, forgot which one, physics maybe, and that most of their base material came from these papers. So if you want to dig in the roots, you've got to pull out these mid last century references.


In general the two directions in BxDF are incoming $\omega_i$ and outgoing $\omega_o$ radiance directions, often defined in spherical coordinates $[\theta, \phi]$ or as a 3D unit vector in Cartesian coordinates $[x, y, z]$. The BxDF $f(\omega_i, \omega_o)$ defines how much of the incident radiance $L_i$ from direction $\omega_i$ hitting the surface is scattered towards direction $\omega_o$. What $\omega_i$ and $\omega_o$ exactly represent depends on the context.

Often $\omega_i$ represents the direction of a light source, but it could also be the direction of a surfel reflecting light or some other light emitting/scattering element in space. $\omega_o$ often represent the direction of the viewpoint (camera/eye), but it could as well be the direction of a surfel or other point in space whose incident radiance we are interested in calculating.

While $\omega_o$ is valid for normal oriented hemisphere above the surface, there are differences in valid $\omega_i$ domain between BxDF's. Because BRDF defines the amount of reflected light $\omega_i$ is valid for the normal oriented hemisphere above the surface. On the other hand, BTDF defines the amount of light transmitted through the surface so $\omega_i$ is valid for the normal oriented hemisphere below the surface. BSDF is the sum of the two so $\omega_i$ is valid for the entire sphere.


What are the usages of software rasterization in modern game engines?

To my knowledge, Software Occlusion Culling (which you already mentioned), is pretty much the only thing a software rasterizer would still be used for. Procworld makes use of a similar technique to display its huge voxel environments.

Most other culling methods like frustum culling do work on the CPU, but, to stick with the example, the test against the frustum happens on object level, probably with an axis-aligned bounding box (AABB). This intersection test is way simpler than using a full-blown software rasterizer.

In certain cases, software rasterization could be used for mouse picking of objects. In game engines, this is often solved using a physics engine and ray-triangle collision with a simplified mesh.

With the CPU being idle while waiting for the GPU in modern interactive 3D applications, one could think that it might be beneficial to use these idle cycles to render on the CPU using a software rasterizer. The problem here, besides the rendering getting horribly complex and convoluted, will often be the bandwidth. Images rendered on the CPU need to be transferred to the GPU before getting displayed, which might cancel out the benefit.


How to read vertex color before rendering texture?

For this kind of functionality, you shouldn't try to use the same framebuffer for the vertex colours and for the final image. Don't forget that GL is asynchronous, so alternating CPU reads and GPU writes to the same framebuffer seriously limit your achievable performance and make it much harder for you to get the concurrency right. (The OpenGL wiki has more about synchronization.)

Instead, you should create an FBO that you only use for your vertex colours render. Draw the vertex colours into that and use it for mouse picking. Only use the 'real' framebuffer (the one that gets drawn) for the final image.


Most of the answer is in the text you linked:

  Shapes almost always sample uniformly by area on their surface.
  Therefore, we will provide a default implementation of the
  Shape::Pdf() method corresponding to this sampling approach that
  returns the corresponding PDF: 1 over the surface area.

So it is not always 1. This is just the most basic way to sample a light. It is simple, fast and provides a good baseline to check other algorithms for correctness. As for:

  Assuming for example a sphere light source (but a cylinder would also
  do), if in the second formula above we use the entire sphere area as
  $A$, aren't we using a solid angle for the sphere which is double of
  what it actually should be? (by including the half surface we cannot
  see from $p$:

The half you cannot see will simply be excluded by the visibiliy test. Or because it is back facing, if you choose to emit light only on one side of the object. A better sampling algorithm will take that into consideration and adjust the PDF accordingly. Indeed, if you read a little further on that page, you will find:

  The second shape sampling method takes the point from which the
  surface of the shape is being integrated over as a parameter. This
  method is particularly useful for lighting, since the caller can pass
  in the point to be lit and allow shape implementations to ensure that
  they only sample the portion of the shape that is potentially visible
  from that point.

Which is exactly what you are asking about. But doing this is not about having correct sampling, it's about having efficient sampling. Any sampling method is correct as long as:

It can generate samples everywhere they are potentially needed.
Its PDF correctly represents the probability of generating each sample.


There is a direct formula for the rotation matrix for an arbitrary axis and angle. Given a unit vector $a = (a_x, a_y, a_z)$ and angle $\theta$, the matrix can be constructed as follows (derivation from Wikipedia):

First build a matrix $C$ from the components of $a$ according to the following formula:

$$ C =
\begin{bmatrix}
  0 & -a_z & a_y \\
  a_z & 0 & -a_x \\
  -a_y & a_x & 0
\end{bmatrix} $$

Then you can construct the rotation matrix from $C$ as follows:

$$ R_a(\theta) = I + C \sin \theta + C^2 (1 - \cos \theta) $$

where $I$ is the 3×3 identity matrix. This assumes you're using a column-vector convention; if you're using row vectors instead, transpose $C$.

By the way, this formula has a neat geometric interpretation. The matrix $C$ has the effect of calculating cross products with $a$. In other words, for any vector $v$, $Cv = a \times v$. If you imagine rotating some vector $v$ about $a$, the tip of $v$ traces out a circle perpendicular to $a$; $Cv$ is a vector tangent to that circle, and $C^2 v$ (which equals $a \times (a \times v)$) is a vector normal to the circle. So with those two vectors, you have a basis for the plane of the circle; then you can apply a variation of the usual sine/cosine formula for points on a circle.


glDrawArrays is failing with GL_INVALID_ENUM

I used MESA_DEBUG=1 (Debugging Tips | mesa3d.org, Environment Variables | mesa3d.org) and found out that glEnable(TEXTURE_2D) was causing the error.

I don't know why it only got triggered on the glDrawArrays (maybe weird bindings) but when I removed that call it no longer failed with GL_INVALID_ENUM.


How to take the derivative of a Bézier curve?

A simple example of taking a the derivative of a B'ezier curve can be shown using a cubic curve.
$$C_3(u) = \sum_{i=0}^3 B_{3,i}(u) P_i,$$ where $u \in [0,1]$ and $B_{n,i} = {n \choose i} u^i (1-u)^{n-i}$ is the $i$-th Bernstein polynomial of degree $n$. $P_i$ are the control points.
written out it is:
$$C_3(u) = (1-u)^3 P_0 + 3(1-u)^2 u P_1 + 3 (1-u)u^2 P_2 + u^3 P_3$$
we can differentiate this with respect to u
$$\frac{\partial}{\partial u} C_3(u) = -3(1-u)^2 P_0 - 6(1-u) u P_1 + 3(1-u)^2 P_1 - 3 u^2 P_2 + 6 (1-u)u P_2 + 3u^2 P_3. $$
Now we can rearrange the terms
$$\frac{\partial}{\partial u} C_3(u) =  3 \left((1-u)^2 (P_1-P_0) + 2(1-u) u (P_2 - P_1)  +  u^2 (P_3 - P_2) \right), $$ or
$$\frac{\partial}{\partial u} C_3(u) = 3 (\sum_{i=0}^2 B_{2,i}(u) (P_{i+1} - P_i))$$
We obtain a quadratic B'ezier curve where the control points are the vectors between the initial control points, scaled by a factor $3$. Therefore the derivative of a Bezier curve of degree $n$ is a B'ezier curve of degree $n-1$, where the control points are difference between initial control points scaled by $n$.
so:
$$\frac{\partial}{\partial u} \sum_{i=0}^n B_{n,i}(u) P_i = n (\sum_{i=0}^2 B_{n-1,i}(u) (P_{i+1} - P_i))$$


You probably know that the BRDF is to calculate the reflected light, from a light source to a camera (In examples a light source and a camera is used, but it does not need to be just that).

The property that you are talking about, basically says that when you swap the light source with the camera, it still gives the same result.

Lets look at an example I quickly made.

Ok, so here you see the basic setup. You have a light source, a camera and a point on a surface. Wi is the direction towards the light, the incoming direction. Wo is the direction towards the camera, the outgoing direction. N is the normal of the surface.

The property says that if we switch Wi and Wo with each other the result is the same.

The example would then look like this.

This looks normal and logical. You said that you should invert the direction vectors. If we do that, this is then our result.

You can see that it now looks like the surface is illuminated from the other side, and since the normal is not inverted, it will end up looking black.

So that is where you made your mistakes. The property says that you can swap the incoming and outgoing vectors and the result will still be the same. This is called the Helmholtz reciprocity. And where you might got confused was this part "how a ray of light and its reverse ray encounter matched optical adventures" (from the wikipedia). But it is not talking about the inverse (multipled by -1) but about the outgoing ray of the event in something like a reflection or refraction.

I recommend reading up on the Helmholtz reciprocity. For example on the wikipedia: https://en.wikipedia.org/wiki/Helmholtz_reciprocity

I hope I explained this properly, and if I made any mistakes, I am happy to learn and fix this answer.

Good luck with your adventures through the computer graphics universe!


Short answer: Move your near clip plane further away.

Depth buffer precision is very sensitive to the near clip plane distance.

Complicated answer: Use different math in your view projection. There are a few techniques that can help, some of them are outlined here:

https://developer.nvidia.com/content/depth-precision-visualized


When creating a JPEG, how can I minimize the occurence of artifacts?

JPEG compression involves three main steps:

Chroma subsampling. The image is converted from RGB into YCbCr color space, in which the luma or brightness (Y) is stored separately from the chroma or color components, Cb and Cr.  The Y component is kept at full resolution, but Cb and Cr are downsampled, typically to half resolution on each axis.  This exploits the fact that the human visual system is more sensitive to fine details of brightness than of color.
Frequency quantization. The Y, Cb, and Cr images are converted into a frequency representation, by breaking them up into 8x8 blocks and applying the discrete cosine transform (a variant of the Fourier transform) to each block.  The result is a matrix of numbers that describe the amplitudes of different spatial frequencies in the block.  These numbers can then be quantized (rounded off to a chosen number of bits of precision). Different levels of quantization are used for different frequencies, exploiting our visual system's relatively lower sensitivity to high frequencies.  This is where the JPEG encoder's quality setting comes into play: lower qualities use coarser quantization.
Entropy coding. The  quantized DCT values are passed through an entropy coder, which losslessly compresses the bit stream by using fewer bits to represent the more common values, sort of like a zip file.

Steps 1 and 2 are the lossy ones, and each produces its own type of artifacts (though there is some overlap).  Chroma subsampling tends to blur sharp edges between regions of different colors.  This is particularly visible in vector art, where brightly colored shapes pick up vicious jaggies around their edges. Frequency quantization blurs fine details in general, and also creates block-shaped artifacts at low quality settings, because the DCT is done on a block-by-block basis.  It is particularly visible on text.

This is why JPEG usually isn't used for images containing vector graphics or text—its compression algorithms are poorly suited for those cases, although they work well for photographs and other images with complex texture and not-too-sharp edges.


Is all grid based noise inevitably anisotropic?

As usual with numerical methods and samplings, it also depends of your quality threshold of what you consider "isotropic". And of what you would consider as a being or not a "grid-based noise algorithm".
For instance Gabor Noise reproduces a target spectrum, for instance blue noise, which in Fourier domain is a simple isotropic ring.
Now if you consider that this ring is not analytic but rasterized, as such it is not perfectly symmetrical. Also if the ring radius (i.e., frequency) get too close to the window size (i.e., maximum frequency), it will be truncated (and thus no longer symmetrical). Up to you to accept or not these as anisotropic ;-)

"This is not a circle" - Magritte . . . . . . . . . . . . . . . .   "This is not a circle" - Nyquist
You might or might not accept a rasterized ring in Fourier space to be "isotropic". Still, in the extreme cases where the ring get thinner than the resolution, or larger than the window, isotropy is objectively lost.


Why do I need to inverse the orientation matrix of a camera to be able to translate it in the direction it is facing?

People always forget that there is no "camera" in OpenGL. In order to simulate a camera you have to move the whole world inversely. So if you want ur camera looking 30 degrees downward, you move the whole world 30 degrees upwards. If you want your camera moved to the left, you move the whole world right. That's why you will notice the "-" sign in the translation vector where he used the variable position.

Hence the reason there is no separate "view" matrix in openGL, it's modelview matrix combined. That's the reason for taking the inverse. Since a view matrix represent's the camera's forward, up and side, you have to take the inverse since the orientation is defined for the world not the camera.


Get normalized device coordinate of an image pixel

You can modulus by row length to retrieve the x coordinate (think about the x coordinate "wrapping around" after each line), and division by row length to get the y coordinate (inverting the multiply you have by imageWidth). We subtract one from the width and height to ensure the last pixel in the row/column maps to 1.0. Note that this isn't "Normalized Device Coordinates", since that implies a 3D quantity which also stores depth, and that all coordinates lie in [-1,1].
struct Point2D { float x; float y; };

Point2D GetNormalizedPixelCoords(int pixelIdx, int imageWidth, int imageHeight) {
    Point2D point;
    point.x = (pixelIdx % imageWidth) / (float)(imageWidth-1);
    point.y = (pixelIdx / imageWidth) / (float)(imageHeight-1);
    return point;
}


Algorithm for adjusting the speed of a progress bar animation

You will need to persist the percent completed across frames and update it based on the time elapsed since last frame and the total time.

percentCompleted = 0;
totalTime = 10; //in seconds

void onUpdate(float deltaTime){
    percentCompleted += deltaTime/totalTime;
}

void hurryUp(){
    totalTime = 1;
}


What are the parameters measure the performance of a rendering?

I assume you mean performance of the numerical algorithm responsible for generating the image?

Usually the performance of a rendering algorithm is assessed through a pixel-wise comparison with a ground truth, converged image. This image is typically rendered for a very long time using a standard and (ideally) unbiased technique like unidirectional path tracing. For a fixed time and sampling budget, you then run your custom algorithm and track a meaningful error (e.g. relative MSE) between your intermediate image and the ground truth image. Plotting the error over time on a logarithmic scale should give you a sense of how your algorithm is performing.

When comparing algorithms, you need to make sure that you are actually comparing images that were output by the same rendering engine. This is crucial if you want to report a faithful metric, otherwise the comparison is unfair and inherently depends on the implementation. For instance, if rendering engine $A$ takes twice as long as engine $B$ to fetch and load a texture, your reported error will be higher, even though the main algorithm you are testing is the same (assuming you are treating materials as blackboxes). The main downside is that rendering researchers are typically required to implement other algorithms in their engine to report the true performance of their new algorithm.


In general, non-linear function would mean that an increase in an input does not produce a proportional increase or decrease in output. Mathematically, any function that relates one value to another that doesn't follow a straight line is non-linear. So x raised to the power y is a non-linear function.

This matters for colors because our brains don't perceive light in a linear fashion. If you double the number of photons reaching the retina, the brain doesn't interpret it as twice as bright. Further, we can better distinguish two dark shades that are separated by a certain difference in intensity than two bright shades that are separated by the same fixed intensity difference.

When encoding light values in a computer, we need to choose how precisely to record them without losing too much quality. If we use too many bits, then our hardware becomes more expensive. If we use too few then the image looks bad. Until the last ~10-15 years or so, it was generally considered too expensive to store more than 8 bits per red, green, and blue channel. The problem is that if you encode the light values linearly (where 2x causes your monitor to produce twice as many photons as 1x does), then images stored with only 8 bits per channel will have very obvious banding in bright areas of continuous color.

But remember above that humans can perceive smaller increments in darker shades than lighter? That means that we can use 8 bits per channel, but not use them linearly. If we instead take each 8-bit color channel value and treat it as a value between 0 and 1, if we raise that value to a power then we have smaller steps in the darker areas than in the lighter. This is called gamma-correction or gamma-encoding. We just have to remember to do the reverse (raise the value to the 1 / x power) when we want to output the values on a display.

So if you're dealing with non-linear RGB, it is probably gamma encoded. sRGB is a popular encoding that uses a power of ~2.2. (In truth, it's a little more complicated than just raising it to a power.) So when someone tells you that RGB is non-linear, that's usually what they are referring to. It is entirely possible to store images in linear RGB, so long as you use more than 8 bits per color channel. There are also formats that use a logarithmic encodings, though they are less common outside of film production.

CMYK is more complicated than RGB. Rather than having only a single thing that is outputting the color (the monitor), with CMYK, you have to deal with the medium you're printing on as well as the inks you are printing with. In a typical scenario, you print onto a white surface (such as a piece of paper). Ideally all visible frequencies of light should be reflected off of the paper and into your eyes or camera. When you add ink, the ink absorbs some frequencies of light and reflects others. (And I believe some passes through the ink, hits the paper and is reflected back as well.) The manner in which an ink reflects light is non-linear. Doubling the amount of ink may not cut in half the number of photons reflected back. So CMYK is also non-linear.


OpenGL ES 3 - Uniform buffer object with float array

Let's review what the specification says about std140 layout of arrays:

  If the member is an array of scalars or vectors, the base alignment and array stride are set to match the base alignment of a single array element, according to rules (1), (2), and (3), and rounded up to the base alignment of a vec4. The array may have padding at the end; the base offset of the member following the array is rounded up to the next multiple of the base alignment.

Emphasis added.

So, if you have an array of float, the array stride shall be the same as the base alignment of a vec4. Also, each array will be padded at the end to the base alignment of a vec4. Yes, a float[] takes up the same room as a vec4[] of the same size.

Welcome to the wonderful world of std140 layout.

If you want to have a real array of floats in a UBO... well, it's best to avoid wanting that. But if you have absolutely no other choice, then I suggest making it an array of vec4. Obviously, the size of this array will be the size you actually want, divided by 4 and rounded up:

const int samples = 31;
const int arraySize = ((samples + 3) / 4);

To fetch a single float from this array, use math:

arrayOfVec4[index / 4][index % 4]

Note that OpenGL ES 3.0 does allow non-constant array indexing of vec and mat types. It also allows the integer operations needed to pull this off.


Long story short: downscale using a standard downscaling algorithm. Then multiply the value in each element by originalArea/scaledArea. This is what Rahul meant in the comments.

Why that works:
You can think of every output pixel as a (weighted or not) average of a neighbourhood of the source pixel. And as we know:

average = sum / count

Now, for the caveats.

Broadly, there are 3 types of downscaling algorithms:

Ones that simply do resampling with some kernel
1.1. Ones that lowpass first
1.2. Ones that don't
Pyramid downscaling
Algorithms like the one in "Genuine Fractals" which are intended for detail-preserving upscaling, but could conceivably be abused for downscaling

Since "3." is not intended for downscaling, it's not useful for your case.

The problem with "1.2." is that, normally a small (e.g. 5x5) resampling kernel is used, which means that only a few of the source pixels are taken into account. In image resizing applications, this can manifest as aliasing. In your application, it can manifest as inaccuracy.

This problem with "1.2." can be fixed by using a big resampling kernel. I believe that's what the ImageMagick library used to do. E.g. taking a good-quality kernel like Lanczos and stretching it by x and y. Or you could go ahead and use a big box kernel like you describe in the question. Which one is appropriate depends on your exact application, but if you're dead set on using a box kernel, use that. The algorithm you described in the question would work fine, and I believe that on a CPU there is no better one (except splitting this one into threads), for the reason that any algorithm would need at least N (number of pixels) operations to take into account all the pixels, and your algorithm does a tiny amount of work for each of these N pixels.

But on the GPU there is a better algorithm that takes full advantage of the GPU's strong parallelism. It's called "parallel reduction", you can find info on it based on that. Since it's widely documented, I'll just sketch the algorithm:

Iteratively downscale the image by a factor of 2 by x and y until you get to your desired size.

"1.1." would probably also suit your needs, but I won't comment on it for now, as it's not much better than the other options.


Calculate the position and rotation needed to have a camera look at a certain region

I have a 2D region defined by 4 points in 3D space. I want to position my camera so that it looks at the region, with a settable variable determining which side it looks at,...

The first thing you need to do for this is to define a convention that specifies which side is the front and which one is the back of your plane depending on the ordering of your nodes. With triangles, you usually use the winding order. So you can define that if you look at the front of a triangle, the points have to be in clockwise order. In conclusion, if you see that the nodes of the triangle are ordered counter-clockwise, you look at the back.

  How do I calculate the orientation and position of the camera?

Once you have this convention, you have to calculate the normal of the surface. You can get it by calculating the cross product of 2 vectors. For example, if your points are named A, B, C, D, take the vectors A->B and A->C and calculate their cross product to get the surface normal. Be aware, that the cross product is sensitive to the vector/node order. So make sure the selected points result in a normal that points away from your front side.

Now, your camera orientation is the negative normal direction if you look at the front and the normal's direction if you look at the back.

Then you calculate the center point of your quadriliteral. There are several ways to do this, so just pick your favorite method or search the internet for it. Your camera position C has to be on the line that has the same direction as your surfaces' unit normal N and goes through the center point P of your surface. So it can be calculated by

$$
C = P + d \cdot N
$$

where d is the distance of the camera to point P. The distance depends on your camera's field of view and the size of your plane. In your special case, where the camera looks directly onto your surface, the camera/screen plane is parallel to your surface. So you can use the intercept theorem to calculate the minimal necessary camera distance so that all points of your plane are inside the cameras FOV.

Remark:

The described method leaves you with one degree of freedom for your camera that is chosen more or less randomly. The rotation angle around its view direction. Depending on the size and shape of your plane, the rotation angle also influences the camera's distance to the plane. So you might want to define an additional constraint to always get the same result. For example, you could say, that your surfaces side A-B has to be parallel to your screens left-hand side.


My (ADS) shader doesn't render the light direction correctly

It seems to me, to be that your different positions and normals are not in the same space. Having them in the same space is important because else it might think the normal is pointing left while it should point to the right.

If you don't know what I mean with space in this context it's basically a coordinate system. Think about a grid, grid A. On grid A you have a point. Then you have another grid, grid B. You place grid A on grid B. If you move grid A around, the point on grid A does not move relative to grid A. It does however move relative to grid B, so they are different spaces. Hope that clarifies it for you, if not I am so sorry.

You have a few coordinate spaces:

Local: This is the vertex locations relative to the model position.
World: This is the location relative to the actual world origin.
View: This is the location relative to the camera.

You have the light position, vertex position and normal:

Light position is in world space.
Normal is in world space, since you multiplied it with a model matrix making it go from local to world.
Vertex position is in view space, since you put it to world space with the model matrix and then to view space with the view matrix.

Do you see that you have one of the three variables in a different space?
I have a strong feeling this is the problem and if you do not multiply the vertex position with the view matrix, in the vertex shader, this should be fixed.

I hope that this helps you and good luck!


Issue with size() function in Processing language?

The window is 100px, 100px because it is the default size and you are not changing it, as your
size() is never being called because Setup() is not a predefined function.
setup() is the function, lower case s not upper case S. Same with draw().

Below is the working code.

class Star {
  float x;
  float y;
  float z;

  Star(){
    // Places the star in random X and Y coordinates
    x = random(0, width);
    y = random(0, height);
  }

  /* Colors the star */
  void update(){
    fill(255);
    noStroke();
    ellipse(x, y, 8, 8);
  }

  void show(){}
  }

// Array that contains all the amount of stars created (100 in this case)
Star[] stars = new Star[100];

void setup(){
  size(800, 800); // TROUBLE HERE. DOESN´T WORK
  for(int i = 0; i < stars.length; i++){
    stars[i] = new Star();
  }
}

void draw(){
  background(0); // Colors the background
  for(int i = 0; i < stars.length; i++){
    stars[i].update();
    stars[i].show();
  }
}


Calculate set of rectangles covering pixel diffs?

I would say it’s a weighted set covering problem.

In specific, the cost for a set of points is the number of extra pixels in the bounding rectangle of this set.

If the number of diff points is small, you can solve this by linear programming. Otherwise, try some approximated algorithms e.g. greedy.


How to generate chaotic halftone pattern?

I could make it by Worley noise

  Worley noise is a noise function introduced by Steven Worley in 1996. In computer graphics it is used to create procedural textures,that is textures that are created automatically in arbitrary precision and don't have to be drawn by hand. Worley noise comes close to simulating textures of stone, water, or cell noise.

https://thebookofshaders.com/12/

#ifdef GL_ES
precision mediump float;
#endif

uniform vec2 u_resolution;
uniform float u_time;

// Permutation polynomial: (34x^2 + x) mod 289
vec4 permute(vec4 x) {
  return mod((34.0 * x + 1.0) * x, 289.0);
}
vec3 permute(vec3 x) {
  return mod((34.0 * x + 1.0) * x, 289.0);
}

// Cellular noise, returning F1 and F2 in a vec2.
// Speeded up by using 2x2x2 search window instead of 3x3x3,
// at the expense of some pattern artifacts.
// F2 is often wrong and has sharp discontinuities.
// If you need a good F2, use the slower 3x3x3 version.
vec2 cellular2x2x2(vec3 P) {
    #define K 0.142857142857 // 1/7
    #define Ko 0.428571428571 // 1/2-K/2
    #define K2 0.020408163265306 // 1/(7*7)
    #define Kz 0.166666666667 // 1/6
    #define Kzo 0.416666666667 // 1/2-1/6*2
    #define jitter 0.8 // smaller jitter gives less errors in F2
    vec3 Pi = mod(floor(P), 289.0);
    vec3 Pf = fract(P);
    vec4 Pfx = Pf.x + vec4(0.0, -1.0, 0.0, -1.0);
    vec4 Pfy = Pf.y + vec4(0.0, 0.0, -1.0, -1.0);
    vec4 p = permute(Pi.x + vec4(0.0, 1.0, 0.0, 1.0));
    p = permute(p + Pi.y + vec4(0.0, 0.0, 1.0, 1.0));
    vec4 p1 = permute(p + Pi.z); // z+0
    vec4 p2 = permute(p + Pi.z + vec4(1.0)); // z+1
    vec4 ox1 = fract(p1*K) - Ko;
    vec4 oy1 = mod(floor(p1*K), 7.0)*K - Ko;
    vec4 oz1 = floor(p1*K2)*Kz - Kzo; // p1 < 289 guaranteed
    vec4 ox2 = fract(p2*K) - Ko;
    vec4 oy2 = mod(floor(p2*K), 7.0)*K - Ko;
    vec4 oz2 = floor(p2*K2)*Kz - Kzo;
    vec4 dx1 = Pfx + jitter*ox1;
    vec4 dy1 = Pfy + jitter*oy1;
    vec4 dz1 = Pf.z + jitter*oz1;
    vec4 dx2 = Pfx + jitter*ox2;
    vec4 dy2 = Pfy + jitter*oy2;
    vec4 dz2 = Pf.z - 1.0 + jitter*oz2;
    vec4 d1 = dx1 * dx1 + dy1 * dy1 + dz1 * dz1; // z+0
    vec4 d2 = dx2 * dx2 + dy2 * dy2 + dz2 * dz2; // z+1

    // Sort out the two smallest distances (F1, F2)
#if 0
    // Cheat and sort out only F1
    d1 = min(d1, d2);
    d1.xy = min(d1.xy, d1.wz);
    d1.x = min(d1.x, d1.y);
    return sqrt(d1.xx);
#else
    // Do it right and sort out both F1 and F2
    vec4 d = min(d1,d2); // F1 is now in d
    d2 = max(d1,d2); // Make sure we keep all candidates for F2
    d.xy = (d.x < d.y) ? d.xy : d.yx; // Swap smallest to d.x
    d.xz = (d.x < d.z) ? d.xz : d.zx;
    d.xw = (d.x < d.w) ? d.xw : d.wx; // F1 is now in d.x
    d.yzw = min(d.yzw, d2.yzw); // F2 now not in d2.yzw
    d.y = min(d.y, d.z); // nor in d.z
    d.y = min(d.y, d.w); // nor in d.w
    d.y = min(d.y, d2.x); // F2 is now in d.y
    return sqrt(d.xy); // F1 and F2
#endif
}

void mainImage( out vec4 fragColor, in vec2 fragCoord ){

    vec2 uv = (fragCoord.xy - iResolution.xy*.5)/iResolution.y;

    float w = 1. - dot(uv, uv)*3.;

    uv *= 48.;
    vec2 ip = floor(uv);
    vec2 v = cellular2x2x2(vec3(uv, iTime/2.));

    float c = v.x; //v.y - v.x

    c -= .35*w;

    c = smoothstep(0., max(.1/c, 0.), c);

    vec3 col = mix(vec3(0), vec3(1), c);

    fragColor = vec4(sqrt(max(col, 0.)), 1);
}

you can see this In shadertoy https://www.shadertoy.com/view/XlSBDz


How can I model ink dropped into still water?

Simulating drops of ink is probably one of the best applications of the Vorton Method.

Unlike fluid solvers based on the velocity form of the Navier-Stokes equations, which track the density and velocity of a fluid, the Vorton Method tracks vorticity instead. It does so by simulating a large number of vortons, each carrying a small amount of vorticity; you can think of a vorton as being a tiny particle that induces a small spinning vortex around itself. The sum of velocities caused by each vortex defines a velocity field in the fluid, which is used to in turn advect the vortons themselves.

Vorton methods are difficult to combine with boundary conditions and have a few efficiency caveats, but for fluid flow where intricate turbulance is the key feature and boundaries can be avoided, the Vorton method far outshines e.g. Eulerian grid solvers, which would need a large resolution to simulate turbulence at a comparable scale.

Michael Gourlay has a very accessible article series on the vorton method. Although his articles are targeted at video games, they hold up similarly for off-line simulation. Here's also an example video of a drop of ink simulated using the vorton method.


As suggested in the comments, there's a few ways you might be able to reduce the geometry before merging it into the big mesh and sending it out for drawing.

First of all, you might not want to draw cubes that are hidden behind other cubes. While this is not a trivial thing to check, it becomes easier when we at least try to limit it to cubes that are on the outer surface of the terrain and the cubes are laid out in a regular grid. In this case you first of all make a regular grid storing a boolean flag for each coordinate where there's a cube. Then all you need to do is walk over that array and for each active cell check its neighbours' flags and only add it to the geometry when it doesn't have all 6 face-neighbours active too. You can even optimize this by checking only the 3 neighbours in the direction of the camera.
Another thing you can do is frustum culling, basically ignoring all cubes that are not inside the actual view volume, which amounts to just checking the cubes against the 6 planes of the viewing frustum.
What you also could do is perform basic backface culling yourself, and only adding the geometry of the 3 cube faces that actually face the camera (or better yet, combining it with the first point, the ones facing the camera and not having an active neighbour).

But all this only reduces the amount of geometry that you are generating and sending over for drawing. It does not do anything for reducing the actual computation you do to generate that geometry (rather on the contrary actually). It is not clear what exactly it is that's causing your script to take too long or acquire too many resources but I also don't know anything about Javascript or Ajax or whatever specific web-stuff you're doing.

Maybe it's possible to delegate all this to some kind of background task that doesn't block the main process. This way you might also be able to process the whole file in smaller batches, generating parts of the whole geometry and updating the display whenever you generated another batch.
The above method might help to reduce overall memory consumption if the amount of actually generated geometry is much less than those 11M cubes from the file and if the regular grid isn't too large either. But you actually only need 1 bit for every grid cell, making just 2MB for 256^3 grid and 128 MB for a 1024^3 grid. You might further reduce this by tiling the grid space into smaller sub grids and processing these each. However, this might require you to traverse the terrain file multiple times if that isn't already sorted appropriately.
Which brings us to the possibility of simply restructuring your input file format to better facilitate any of the above methods, like already sorting your cubes into spatial subgrids, or even storing a full boolean grid rather than a compact list of coordinates.

This all really depends on what the bottleneck is here. But it should give you some general ideas of how you could approach this for optimization.


There are many shading languages built on top of GLSL or HLSL - what problems do they typically solve, and what worthwhile advancements do they make?

I think it is fair to say that the reason there are so many niche variations of GLSL/HLSL/Cg/whatnot is because no programming language is nor will ever be a one size fits all tool. Different problems require different tools, so sometimes it is worth the effort of developing a custom built tool if it is going to pay off in the long run.

Stock GLSL is by itself pretty much unusable. It hasn't even acquired much stability across versions, so for a program that targets more than one OpenGL version, some sort of preprocessing is a must. HLSL is a bit more stable across versions, but again, if targeting more than one D3D version, some work will need to done to get good portability.

The kinds of things people usually do are pretty much what you said, like a adding support for basic programming features such as modules and uniform syntax across versions, or even portability across different APIs (GL/D3D) without having to rewrite the shader code. More sophisticated things include fully fledged material systems or things like generating shader programs on-the-fly.

Shading languages will probably get better and more generic in the future, incorporating things that today are commonly hand-rolled as core features. The new GCN architecture is a sign of that. So shading languages will be more usable out-of-the-box a while from now, but custom built solutions will never go away because there's only so much you can generalize.


Understanding of Microfacet monte-carlo path tracing

Some more clarity on the fresnel.

F tells you how much light is reflected, and (1 - F) therefore tells you how much light is transmitted through the layer/material/surface.

Generally we put fresnels into two types Dielectric(water/glass) and Conductor(metals).

The approximation you are using is for a dielectric fresnel, so what you are actually modelling is a thin layer over the top of your diffuse. In renderers this layer is normally called the coat or clearcoat. It can be used to emulate laminated materials or a coating of water/sweat.

If you want to render metals you would need to swap out the fresnel for a conductive one. There are better approximations, but an easy artistic approximation is to swap the F0 of your schlick approximation with the rgb of your material. You can layer a diffuse below this if you need to but you may find with conductive it's not nessisary.

http://www.codinglabs.net/article_physically_based_rendering_cook_torrance.aspx

This is a good article on the topic for further reading.


When cylinder and frustum intersect the hole will be a view into the internals of the cylinder. The hole is where external of the cylinder occlude frustum and internal of the cylinder does not occlude the frustum.

Knowing this you should simply do the following to find the surface (or rather volume) made from the hole.

Render frustum without color and set depth accordingly. Set a stencil bit where the cylinder (external) occludes the frustum, without setting new depth. Clear the previously set bit where the internal of the cylinder occludes the frustum, without setting new depth.

Alternate between internal and external using CullFace.

The stencil mask you now have is the surface where the frustum hole is. Render the frustum (in color) masking it with the stencil. Make sure to use LEQUALS depth test to allow the frustum to render on top of itself. Voila. Note that the depth buffer holds the value of the unmasked frustum so If you need to render something within the hole you would have to render the whole scene again and mask it to only render in the hole unless depth test passes against the frustum. Left as student exercise.


Fastest shader compilation strategy on windows dx9 and dx11?

From what I can find out (not having tried it myself), using a thread per core to do D3D compiles is reported to be safe and gives a good perf speedup, and there doesn't seem to be any contention between threads in the compiler itself.

However, Fabian Giesen notes that you might see lower perf when running under a debugger, due to contention in the Windows debug heap allocator, which can (and probably should) be disabled.

BTW, the functions you mentioned are both wrappers around D3DCompile, and don't involve the driver per se at all; they only do the GPU-independent "HLSL source to bytecode" step, and not the GPU-specific "bytecode to machine code" step. So they're entirely Microsoft code, not GPU IHV code.


In bidirectional path tracing, is a camera subpath with $n$ vertices determined by a fixed number of random numbers?

For a fixed strategy, you can end up consuming a different number of samples depending on your mutation. This can happen for at least two reasons. If your perturbation changes some material along the path to, say, a multi-lobe BSDF, you would need more samples to account for the lobe choice. This would shift everything by the number of extra samples used. If your ray eventually escapes the scene as you are tracing your mutation, or it hits a light source prematurely, you would use fewer samples. In these cases, you'd have to reject this proposal automatically.

One way of mitigating this issue in practice is to separate the two random number vectors for the camera and light subpaths and always mutate all dimensions of the unit hypercube $\mathcal{U}^{o(k)}$, regardless if they are being used or not by the mutation. This doesn't remove the shift caused by BSDF changes (which is unavoidable) but at least you're not spilling your samples between camera and light subpaths.

Note that changing the strategy can also lead to an undesired rippling effect as primary samples will be used to perform a slightly different task (i.e. tracing a different strategy). This can be handled by introducing inverse mappings to preserve the geometry of the path, which is what is done by Reversible Jump MLT.


Rounding a corner formed by Arc and Line

I suppose you want an arc of C0 and C1 continuity between the line and an arc.

As illustrated above, you already have a vertex A which is the intersection of an edge and an arc of which the center positioned at O and radius equal to R. The question is thus pure mathematical: given A,O,R, edge direction BA, and a corner radius r, find C,B, and T.
For simplicity, here let's assume that the black dotted line has the form of $C_y=kC_x+b$, where k is the same as edge BA while b is easily derived by combining k and rounding radius r. Therefore, three constraint equations can be listed to solve $C_x$:

The distance TC is r: $(T_x-C_x)^2+(T_y-C_y)^2=r^2$
The big arc equation: $(T_x-O_x)^2+(T_y-O_y)^2=R^2$
Point C is on OT: $\frac{T_y-C_y}{T_x-C_x}=\frac{T_y-O_y}{T_x-O_x}$

Solve for Cx and you'll obtain four solutions (I used Mathematica):

$C_x=\frac{-bk+O_x+kO_y\pm\sqrt{-(O_y-kO_x-b)^2+(1+k^2)(R-r)^2}}{1+k^2}$
$C_x=\frac{-bk+O_x+kO_y\pm\sqrt{-(O_y-kO_x-b)^2+(1+k^2)(R+r)^2}}{1+k^2}$

The second expression is out of the arc, so you should use the first solutions. Given the two Cx values, they can be used to derive Cy values to make a candidate list for point C. Pick the correct C using manual check.

Now you have the center C of the round corner arc as well as its radius r. It should be relatively easy to determine point B and point T, and draw an arc through the two points.


Screen to World coordinates glm::unProject

You can calculate the world position of the pixel on near plane quite easily by first defining Normalized Device Coordinates (NDC) for the point and then transforming the NDC back to the world space. You can calculate NDC for your point as follows:
$$v=[2*(x+0.5)/width-1, 1-2*(y+0.5)/height, 0, 1]$$
I'm using 0 here for the z-component assuming near-plane in NDC is 0, but it could be something else as well, so check with your projection matrix what values comes out at the near-plane. This vector must be then transformed to clip-space by multiplying by near-plane distance:
$$v'=np*v$$
Now that you have clip-space coordinates, you just need to transform this back to world space with the standard clip$\rightarrow$world transformation matrix:
$$v''=M*v'$$


How can I draw regular polygons along the horizontal axis?

You can use the equation of a circle to do this. A circle can be drawn using the equation:

$r^2 = x^2 + y^2$

You can solve for the upper half of this by rewriting it in terms of $y$ like this:

$y^2 = r^2 - x^2$

so

$y = ±√(r^2 - x^2)$

But we only want the positive half. So we say just:

$y = √(r^2 - x^2)$

You can then repeat it by using (((x - 2) % 4) - 2) as the input value. In the end the equation is this:

$y = √(1^2 - (((x - 2) mod 4) - 2)^2)$

It looks like this:

In graph toy, it would be:

sqrt(1 - pow((((abs(x) - 2) % 4) - 2),2))