Feature/#468 access isosurface scalar

First, let me explain how I understood this implementation because I think it is quite confusing.

Instead of vector<vec2> for the texture coordinates we now have vector<vector<float>> and we can use GetNumberOfTextureCoordChannels() to find out the number of sets of texture coordinates and GetNumberOfTextureCoordComponents(i) for set i (or channel, as it is called here) to determine the dimensionality of the coordinates. This is not really what we discussed in the meeting, where we wanted to have three vectors like this:

vector<float>
vector<vec2>
vector<vec3>

Note that the number of components of a texture coordinate channel is determined via

texture_coords_[channel_index].size() / vertices_.size()

So a mismatching number of texture coordinates will not result in failure but the texture coordinates will appear to be lower dimensional which might lead to confusion. Additionally, the layout that the texture coordinates are in does not become apparent from the code, so instead of putting the coordinates like

x1, y1, x2, y2, ...

one might think to put them in like

x1, x2, ..., y1, y2, ...

Still, although I don't like it, this implementation works and gets the job done. What do the others think? Shall we leave it like this?

By Martin Bellgardt on 2018-07-31T11:22:48 (imported from GitLab)

You understood correctly.

This is not really what we discussed in the meeting, where we wanted to have three vectors like this:

Than I probably misunderstood the discussion. I was under the impression that we want to have an arbitrary number of texture coordinate channels which each can be 1D, 2D, or 3D. This was the solution with the least overhead we came up with.

By Simon Oehrl on 2018-08-08T14:16:24 (imported from GitLab)

added 2 commits

• 2c8cca33 - Create an OpenGL buffer for 1D texture coords
• 36c7eaa3 - Merge branch 'feature/#468_access_isosurface_scalar' of…

Compare with previous version

By Simon Oehrl on 2018-08-08T14:03:10 (imported from GitLab)