I can't give you a "better" approach here, but I think that the approach to
project each individual brush image onto the surface of the object
is not really a performance issue if you implement that using the GPU. Especially in an editor environment, where not much is going on in comparison to a computer game. All you basically want to do is to ...
As long as no pixel on the texture is used twice, you can render the geometry and display the uv-coordinates (texture coordinates). Usually they are a combination of red and green (2d).
When using a brush, you only need to read out the uv-coordinates you've hit and color the texture at position (uv) in the desired color.
paint onto a second texture, so ...
Ok. So Finally, I have solved the problem. This problem I been working on for a couple of weeks. Had to go through several books in math, gamedev etc. Went through all my code, to see if I had something I did missunderstand.
Finally I found the problem! I was trying to store normals in the texture, with values between [-1, 1], I did not think about the ...
You're not correctly inverting the mapping you used to store the depth value. When storing it you use:
vDepth = -(vPos.z - NearPlane) / ( FarPlane - NearPlane);
Then you reconstruct it as:
const float depth = normalDepth.w * (FarPlane - NearPlane);
but this misses both the offset by NearPlane, and the negative sign to flip the Z axis (since it points out ...
The problem is definitely a lack of linker flags.
It can see that you want to include <SDL/SDL2.h>, which is a sort of promise that said functions contained in that header have been built and will be available; but when your linker looks to find the actual machine code, it needs a little more than the header. It needs the library itself.
For SDL2, you ...