Hot answers tagged

4

C++ has no defined ABI, so C++ programs can't link to libraries that were compiled with a different compiler. In addition, MS's Visual Studio C++ compiler is not ABI-stable, so you don't just have to use the same compiler: you have to use the same version that the library was compiled with. This would be a huge problem for a widely-used library like DirectX....


3

OpenGL itself is purely a graphics library. It doesn't give you access to keyboard input. However, if you're using OpenGL, you're also probably using a cross-platform context/window toolkit to create a desktop window and set up an OpenGL context for drawing into that window. These toolkits usually also give you basic keyboard and mouse input. (The idea ...


3

There's no such thing as a Vulkan context, the way there is with OpenGL. There are a number of things that kind of correspond to an OpenGL context. There's a VkInstance. This encapsulates access to the Vulkan libraries on the system, including the extensions. There's a physical device VkPhysicalDevice and a Device. The former encapsulates all the ...


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

You don't. These objects typically work with CPU memory, not device memory. And to the extent that they involve device memory, such allocations tend to be rare and/or fixed in size (a queue may have a small spot of device memory that the hardware queue reads commands from or something, but even that is implementation-dependent). Vulkan allows you to give ...


2

What GL_LUMINANCE as a texture format actually does is store one component of data per pixel that is used for the red, green and blue color components. So, a classic greyscale image (It doesn't use it for the alpha component, though, that's why there was also GL_LUMINANCE_ALPHA for two compnent storage and GL_INTENSITY that broadcasts it to all components). ...


2

The signature of glfwGetProcAddress is: GLFWglproc glfwGetProcAddress(const char *); It's a function that takes a string and returns a GLFWglproc. which is defined as typedef void(* GLFWglproc) (void); Essentially, that means glfwGetProcAddress is a function that takes a string and returns a pointer to function with no parameters and no return value. ...


2

When creating a OpenGL context you have to specify a profile mask, which is a way of telling the driver whether you want to use compatibility ("legacy") features or not. Drivers are required to implement all core profile features, but compatibility profile is optional - creating a compatibility context can fail even if the driver supports the version you've ...


2

The heading row of Figure 5(b) says that the units of $\sigma_s'$ and $\sigma_a$ are inverse millimetres, that is, inverse distance. Hence, $1/\sigma_t'$ has units of distance. If you send a beam of photons through a medium with scattering coefficient $\sigma$ and measure it at distance $l$, then the probability that a photon has made it that far without ...


1

Let me first address some misconceptions you have: the theory states that we need to shoot x number of rays for each intersection No, the "theory" doesn't state such a thing. Note also that the paper @gallickgunner is referring to is inapplicable in this case since smallpt is based on the rendering equation and not the limited variant present in Cook's ...


1

During the implementation, the way rays are scattered does not actually change and remains random. Actually the way rays are scattered does change, specifically when you sample a light. In chapter 8 he makes a mixture pdf in order to sample either the light or the bsdf. What changes looks to be the contribution of each ray. This does change, but not ...


1

There are two ways to 'translate' your object. The first is by moving each point of your object by the desired translation. The second is by translating the origin of your coordinate system. In this case it's the latter. Basically it turns out to be the same, whether you translate your object by a vector $\vec{t}$ or whether you translate your origin by $-\...


1

OpenGL is is a cross-language, cross-platform application programming interface (API), and it acts as a bridge between your CPU and your GPU. It's not an input handling library, since that is something that is OS specific (on Windows for instance you would use DirectInput) and that has nothing to do with the GPU. Now, as stated by the other answers, you ...


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