New answers tagged

1

Here are a few steps to (hopefully) help get you going: Rendering the cube: For the geometry a simple cube is needed, so really the first step is just to get a cube rendering just like you would expect, I suggest placing the cube at the origin in both world and object space. After you are happy with the way the cube is rendered, change the winding direction ...


3

First of all, I don't think you need volatile or memory barriers if you're just using atomic operations. Atomic operations are always supposed to be atomic regardless. However, having everything accumulate directly into one (or a small number) of atomic variables is not advisable because there will be too much contention on those few memory locations, thus ...


0

There are no performance guarantees in OpenGL. Many implementations will filter out some kinds of redundant state, but nothing guarantees that. The best you can do is this: if you change state, you should do so with the expectation that you will pay the cost of that state change. It should also be noted that the cost of a state change is paid at the next ...


0

You can put your data in one piece of memory on the CPU and then copy it in with glBufferStorage. It's just a bunch of memcpy calls. With C++20's std::span (or the GSL version), you can even make a function to build byte-spans from any number of vector<T>s (even of different types) and do the building and memcpy's manually. #include <vector> #...


0

It depends on the order of rendering. When first rendering the object which is far away and then rendering the closer object, the transparency will work. Otherwise when first rendering the close object, you depthbuffer will block the object which is behind. There are different ways to manage this issue: 1:First render all opaque geometries. and then render ...


Top 50 recent answers are included