Compile errors on Window 10 with Qt 5.10

[csuft]

I encountered compile errors when I try to compile the project with QtCreator.

The compiler complains that it does not have compatible operators to convert from std::_Array_const_iterator<_Ty, 3> to int. The code line lies in ktrianglepointiterator.h:

inline auto KTrianglePointIterator::operator*() -> ValueType const &
{
// Reminder: FaceIndices start from 1
return m_cloud[static_cast<size_t>((*m_iterator) - 1)];
}

Development environment is Qt 5.10 on Windows 10 64bit.

[TReed0803]

Thanks for the heads-up. I'll take a look tonight after work, what compiler/version are you using?

…

On Wed, May 23, 2018, 06:43 zhangzhongke ***@***.***> wrote: I encountered compile errors when I try to compile the project with QtCreator. [image: 2018-05-23_213740] <https://user-images.githubusercontent.com/3948137/40427908-94e3a3ba-5ed1-11e8-9c9d-00cab52e93ee.png> The compiler complains that it does not have compatible operators to convert from std::_Array_const_iterator<_Ty, 3> to int. The code line lies in ktrianglepointiterator.h: inline auto KTrianglePointIterator::operator*() -> ValueType const & { // Reminder: FaceIndices start from 1 return m_cloud[static_cast<size_t>((*m_iterator) - 1)]; } Development environment is Qt 5.10 on Windows 10 64bit. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwMAhknSMsaMvF57cTuZmosUESJ-Calks5t1WeLgaJpZM4UKegG> .

[TReed0803]

Taking a while to update all my stuff... I don't use Windows very often, so maybe give me a few more days to get all my tools working here. I'll hopefully have a fix before the end of the week.

[csuft]

Thank you for your reply. I'm using Visual Studio Community 2015 and the version is 14.0.24720.00 Update 1.

[TReed0803]

The issue is that std::array was altered in recent standards, the iterator type used to be able to be dereferenced like a pointer, however the new C++17 standard makes more provisions around the format of the std::array iterator types. So, I can no longer apply the typename std::remove_pointer<To>::type call that I was doing to get the value type.

Simple fix, we can just say typename To::reference instead. (Though I will need to test and ensure I don't break other platforms. I believe for a while this iterator may have just been implemented as a pointer, which is why I needed to do this... May be a tricky fix not to break others.)

After fixing that I also found that one of the GL calls was not going through the proper context namespace (GL::, which is how we map the global GL function pointers). Again, simple fix just add the GL:: namespace prefix to these calls. (No regression risk here AFAICT)

After fixing that, I find that on my new PC the compute shaders don't compile! This is because for compute shaders gl_FragCoord doesn't technically exist. Some of my helper functions use this input, and I must've been on a more lenient driver before - even though I don't use these functions directly in the compute shader, it's causing shader compilation errors on my current PC.

For this, I will have to devise a mechanism of defining macros to ifdef-out the invalid information for certain compilation units. That will take a tiny bit of work, but not much as far as I can tell.

After fixing that, I noticed that OpenGLLightGroup is failing to draw instanced lights (I'm not sure why, it is crashing). So that is the next thing I need to look at. Commenting out the instanced drawing functions allows everything to render as-expected (sans lights, of course), but I'd like to figure this out before I commit anything.

Thank you for being patient, I will work on this more tomorrow.

[TReed0803]

Figured it out, this GL driver doesn't like it when glDrawElementsInstanced is called with an element count of 0. Sounds like a driver bug since the only documented error case is if the values are negative: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawElementsInstanced.xhtml

Oddly, QFileDialog started infinite looping as well. This is because the QFileDialog no longer stops other update signals from being executed... In the past, this was the case and update would block until the file dialog is closed. I have hacked in a bool to counter-act this (I believe it should not be needed, this sounds like a Qt bug - maybe fixed in later versions. THIS IS A RACE CONDITION AND SHOULD NOT BE DONE IN PRODUCTION CODE! However, for demonstration purposes I will accept that this is mostly correct and document accordingly.)

Finally, the lighting equation seems to be banding weird. Everything seems to work with these fixes, but there is some bad maths happening for lighting now. I'll file a separate bug for investigation and commit what I have to hopefully unblock you. If this is anything like the other bugs, it just depends on what GPU you have for whether or not you have the same issue I am seeing - so I can at least unblock you.

Will have a fix published shortly.

[TReed0803]

Scratch that QFileDialog business, I'll just use a mutex, it's not like it's that much harder and it sets a better example.

[TReed0803]

Issue Resolved in: 91ac4b5

I'm going to close this issue now, there is a rendering bug in some integrated GPUs that I noticed, but that is not pertaining to this. If this issue does not appear fixed, please re-open.

Thanks for the report!