13

Talking about Linear RGB must be avoided because it does not tell you anything about the RGB colourspace intrinsics, i.e., Primaries, Whitepoint and Colour Component Transfer Functions. A few years ago, assuming it was sRGB was middling but nowadays with DCI-P3 and BT.2020 being very common, it must be ruled out. The ideal gamut for rendering is the one ...


6

There are explicit rules in the OpenGL specification about invariance guarantees. For the purpose of this discussion, these rules boil down to the following. Given a particular series of vertex processing shaders (VS, tessellation, and GS), there are some set of input values, uniforms, and the like which lead to the computation of the final gl_Position ...


5

In practice, when we say "linear RGB," we mean "sRGB without the gamma correction." It would be more correct to say that there is the "sRGB colorspace" and the "linearized sRGB colorspace", with the sRGB specification definition the conversion from one to another. Yes, there are infinitely many "linear RGB" color spaces. But the thing that all of these "...


4

It's generally a good idea to add noise like this when you're using a gradient, to avoid visible banding in the gradient, especially on smartphones. Often smartphone screens claim to be 24-bit colour but the panel itself is actually only 16 or 20 bit. The chief difference between the example and your attempt to reproduce it is that your noise is in RGB ...


3

That's just how the Reinhard operator works. If the scene has very high dynamic range important detail may be lost near the high luminance region as you found since both will map near 0.99. Reinhard is a form of global operator. There are other types of algorithms using local operators which tonemap the pixel based on the intensity of the underlying ...


3

Here's a more complete answer from the extent of my knowledge. A sort of brief overview you can google more about. I'm sure I didn't cover all the different techniques but most branch off the mentioned ones. Note: if it's a liquid we are more concerned with getting an accurate surface representation. Surface Extraction Methods: The most common way would be ...


3

Copying this from another thread where i posted this as the answer but as Wyck suggested, the correct answer is the first one. There is the whole derivation of it but I'll be discussing a brief overview. This is for the perspective projection where the line joining the eye and the center of the projection/image plane is perpendicular to it. Like here As ...


3

Picking up from step 2, where you generated line segments to represent individual stitches, I would first suggest that you apply rounded ends to each segment, rather than square ends. I would then convert each segment to an outline, (i.e. each rounded stitch becomes an separate poly-line representing the outer boundary.) For example, suppose you start with ...


3

Throughout my answer I'll sometimes refer to some results in https://sites.fas.harvard.edu/~cs278/papers/veach.pdf by using [MIS,section_number]. You can skip the following derivation if you don't care about the mathematical explanation of why using MIS to combine estimators is valid. I'll have to start with what the purpose of MIS is. The general idea is ...


2

$$ \def\mvec#1{\begin{pmatrix}#1\end{pmatrix}} \def\ivec#1{\left(\begin{smallmatrix}#1\end{smallmatrix}\right)} \def\mmat#1{\begin{bmatrix}#1\end{bmatrix}} \def\vec#1{\mathrm{\mathbf{#1}}} \def\mat#1{\mathrm{\mathbf{#1}}} $$ If you have the screen-space x and y coordinates as well as the depth of your fragment, you can directly compute the coordinates of the ...


2

The rendering equation aims to describe what the light distribution for a specific scene is, under several assumptions. The most important assumption is that we are working in a geometrical optics framework - so we do not consider the wave properties of light - meaning no diffraction for example, we also do not consider quantum effects, such as ...


2

Suballocating from a larger buffer is absolutely the way to go, with caveats. I'm coming more from a DirectX/Vulkan side of things, but this should apply equally to OpenGL (I just won't have direct API calls here in this answer). The things to consider are the following: Do you need to index into the larger buffer, or are you OK with binding the resource to ...


2

That would be because the GPU is deterministic. For the same inputs (vertex positions) it should produce the exact same per pixel depth outputs. Z-Fighting usually occurs with polygons with different vertex positions but still on the same plane, so interpolation rounding errors show up as differences and hence Z-fighting.


2

A few more options: don't use a scenegraph. They don't map well to the data a gpu needs for rendering. A flat array of object tends to work much better for the cache as well separate the scenegraph into render-related data and non-render-related data. Then only double buffer the render-related data. The render related data would end up in a flat array ...


1

Yes, it is possible to do this. If you use a tool like Photoshop in 32-bit per channel mode, any values less than 0 or greater than 1 should be usable as a high dynamic range values. I don't know that I agree with your contention that "people don't seem to do this". Given that the tools exist, they must be supporting some workflow.


1

After coming back to the problem now with a fresh pair of eyes, I have managed to find my mistake. Ad Question 1 Yes, the formula is correct. The problem is hidden in the tangent and bi-tangent . When performing normal mapping, the tangent frame has to be perpendicular to the mapped normal, otherwise the term will not carry any information about the ...


1

It'd be hell a lot easier if this were on graphicsexchange, since I can't use latex here but anyways. In the first pass of Photon Mapping you don't need to use the Flux form of rendering equation. You just divide the original flux coming from the light source among the N photons, then for each photon you use Russian Roulette to determine whether it reflects,...


1

Ad 1) Yes, if both monitors have the same resolution but different screen sizes, this means the pixels of the larger monitor are bigger. It could also mean the space between the pixels is different. Ad 2) No, the physical size of a monitor makes no difference for the GPU. It only cares about the resolution, for example 1920x1080 vs 3840x2160. The latter ...


Only top voted, non community-wiki answers of a minimum length are eligible