return{current_meshs,rendering_params};// I think we could also work with a Mat face_instance in this function instead of a Mesh, but it would convolute the code more (i.e. more complicated to access vertices).
return{current_meshs,rendering_params};// I think we could also work with a Mat face_instance in this function instead of a Mesh, but it would convolute the code more (i.e. more complicated to access vertices).
return{current_meshs,rendering_params};// I think we could also work with a Mat face_instance in this function instead of a Mesh, but it would convolute the code more (i.e. more complicated to access vertices).
return{current_meshs,rendering_params};// I think we could also work with a Mat face_instance in this function instead of a Mesh, but it would convolute the code more (i.e. more complicated to access vertices).
// bool enable_texturing = false; Maybe re-add later, not sure
// bool enable_texturing = false; Maybe re-add later, not sure
// take a cv::Mat texture instead and convert to Texture internally? no, we don't want to recreate mipmap levels on each render() call.
// take a cv::Mat texture instead and convert to Texture internally? no, we don't want to recreate mipmap levels on each render() call.
autot1=std::chrono::high_resolution_clock::now();
assert(mesh.vertices.size()==mesh.colors.size()||mesh.colors.empty());// The number of vertices has to be equal for both shape and colour, or, alternatively, it has to be a shape-only model.
assert(mesh.vertices.size()==mesh.colors.size()||mesh.colors.empty());// The number of vertices has to be equal for both shape and colour, or, alternatively, it has to be a shape-only model.
assert(mesh.vertices.size()==mesh.texcoords.size()||mesh.texcoords.empty());// same for the texcoords
assert(mesh.vertices.size()==mesh.texcoords.size()||mesh.texcoords.empty());// same for the texcoords
// another assert: If cv::Mat texture != empty, then we need texcoords?
// another assert: If cv::Mat texture != empty, then we need texcoords?
// Todo: Split this whole stuff up. Make a "clip" function, ... rename "processProspective..".. what is "process"... get rid of "continue;"-stuff by moving stuff inside process...
// {
// classify vertices visibility with respect to the planes of the view frustum
//#pragma omp parallel for
// we're in clip-coords (NDC), so just check if outside [-1, 1] x ...
for(inti=0;i<mesh.tvi.size();i++){
// Actually we're in clip-coords and it's not the same as NDC. We're only in NDC after the division by w.
constautotri_indices=mesh.tvi[i];
// We should do the clipping in clip-coords though. See http://www.songho.ca/opengl/gl_projectionmatrix.html for more details.
// Todo: Split this whole stuff up. Make a "clip" function, ... rename "processProspective..".. what is "process"... get rid of "continue;"-stuff by moving stuff inside process...
// However, when comparing against w_c below, we might run into the trouble of the sign again in the affine case.
// classify vertices visibility with respect to the planes of the view frustum
// 'w' is always positive, as it is -z_camspace, and all z_camspace are negative.
// we're in clip-coords (NDC), so just check if outside [-1, 1] x ...
unsignedcharvisibility_bits[3];
// Actually we're in clip-coords and it's not the same as NDC. We're only in NDC after the division by w.
for(unsignedchark=0;k<3;k++)
// We should do the clipping in clip-coords though. See http://www.songho.ca/opengl/gl_projectionmatrix.html for more details.
{
// However, when comparing against w_c below, we might run into the trouble of the sign again in the affine case.
visibility_bits[k]=0;
// 'w' is always positive, as it is -z_camspace, and all z_camspace are negative.
// split the triangle if it intersects the near plane:
if(enable_near_clipping)
{
vertices=detail::clip_polygon_to_plane_in_4d(vertices,glm::tvec4<float>(0.0f,0.0f,-1.0f,-1.0f));// "Normal" (or "4D hyperplane") of the near-plane. I tested it and it works like this but I'm a little bit unsure because Songho says the normal of the near-plane is (0,0,-1,1) (maybe I have to switch around the < 0 checks in the function?)
}
// triangulation of the polygon formed of vertices array
-1.0f));// "Normal" (or "4D hyperplane") of the near-plane. I tested it and it works like this but I'm a little bit unsure because Songho says the normal of the near-plane is (0,0,-1,1) (maybe I have to switch around the < 0 checks in the function?)
}
// triangulation of the polygon formed of vertices array
