Show off something you've made

[markaren]

If you have created something using threepp, I'd love to see it. Please share a gif or screenshot of of your work.

[wol101]

Using threepp inside a Qt OpenGL widget. It works pretty well although there are some issues with the GLRenderer when the OpenGL context gets switched, The workaround is to create a new GLRenderer each frame. I haven't got shadows to work either. Code at *[https://github.com/wol101/GaitSym5](https://github.com/wol101/GaitSym5/tree/development)*

[markaren]

Thanks for sharing. Regarding your issue, what if if you call resetState() on the renderer for each call? Shadows ought to work, but they often require som tuning of the shadow camera.

[wol101]

I'm sure I can get shadows working with a bit more effort but the state thing is weird. Recreating the GLRenderer works OK but calling resetState() doesn't. It effects the render and feels like maybe one of the shaders has got messed up, or some of the uniforms aren't being set to the right value (if I have a wireframe then the colour is wrong and the shape is distorted as if the MVP matrix is not correct - but I checked the material and matrices and they appear to be correct). The work around is fine for now and I really appreciate the effort that has gone into the port.

[asmwarrior]

The project is really nice! Good work. Though I'm a wxWidgets user, I still suggest if we could supply a QT example code by using this threepp library inside QT's window.

[wol101]

I’ve got a simple Qt example. It was the first thing I did. It’s based on your wxwidgets example. I’m happy to share it. Bill Sellers - Sent from my phone so please pardon my brevity.On 11 Apr 2024, at 16:05, ollydbg ***@***.***> wrote: The project is really nice! Good work. Though I'm a wxWidgets user, I still suggest if we could supply a QT example code by using this threepp library inside QT's window. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[asmwarrior]

Hi, @wol101 thanks, that's very nice. I have a code repo to share my own wxWidgets based threepp sample project, see here: https://github.com/asmwarrior/threepp/tree/wx-port, under the "cb" folder, because I use Code::Blocks as my main IDE. "threepp" is still built by cmake under msys2 mingw64.

This is the simple demo result wxWidgets window which embed a threepp opengl scene.

[wol101]

I've created something similar for Qt at https://github.com/wol101/threepp/tree/qt-integration
The simple example seems to work very easily and completely as expected but once I embed it in the more complex program it only works properly the first time through the paint loop. Calling resetState leads to a mostly black screen, but recreating the renderer each time works perfectly.

[asmwarrior]

I looked at your code, and I see that you are putting the source code of the threepp directly in your project.

Also, you are using a lot of shaders(I see a lot of header files of the shaders)

I'm not familiar with the QT, so I can't help much.

[wol101]

Thanks for having a look. The performance overhead isn't bad recreating the renderer and I'll have a look at the constructor to see if I can work out what's going on. Qt uses OpenGL as its back end for drawing all its widgets so there is a fair chance that it is changing a lot of settings. I'll move threepp to a library as soon as I'm more familar with what it is doing. I find being able to easily step through the code really helpful when trying a new library.

[asmwarrior]

Qt uses OpenGL as its back end for drawing all its widgets so there is a fair chance that it is changing a lot of settings.

Oh, this may be the reason. Under wxWidgets, I think it use the native OS API(for example, it use win32 API under windows).

My command to build the library is here: build-commands-under-msys2-mingw64.txt, but I think I have changed the cmakefile a little to fit my need.

[wol101]

Fixed it! Qt expects the OpenGL initialisation to be done in initializeGL() but it turns out there is no valid framebuffer at that point which threepp::GLRenderer expects. I can delay creating threepp::GLRenderer till the first time the paintGL() runs and then everything behaves itself. I've updated the example code to reflect this. I've no idea why I only saw the problem in the more complex code but hopefully this now works OK. Delaying the initialisation has negligible impact on performance whereas re-initialising every paint call worried me.

[wol101]

Shadows too! It's almost perfect but I am getting some random crashes deep in gl::GLTextures::uploadTexture sometimes when the view is changed. This is quite a big model (>5 million vertices) but the only textures are for the shadow maps so internally generated. The errors are strange though so it could easily be some sort of memory overun in my code. I'll continue to explore.

[asmwarrior]

Shadows too! It's almost perfect but I am getting some random crashes deep in gl::GLTextures::uploadTexture sometimes when the view is changed. This is quite a big model (>5 million vertices) but the only textures are for the shadow maps so internally generated. The errors are strange though so it could easily be some sort of memory overun in my code. I'll continue to explore.

Nice image. You project(animal locomotion) is very interesting.

[wol101]

Thanks. I've gone back to creating the threepp::GLRenderer every paint loop. Then the shadows work perfectly. If I try and reuse the GLRenderer then gl::GLTextures::uploadTexture fails because it gets sent an invalid texture (dispose is true and it tends to crash on the dynamic_cast<DataTexture3D*> line because the pointer is not a valid texture object. I'm not sure what Qt is doing to cause this effect. It feels like it might be getting in the way of some of the dispose event housekeeping. I wonder if there something that needs to be done that is normally handled by Canvas to dispatch events...

[wol101]

Just to say that it is now working perfectly. Turns out I just wasn't disposing of things properly. Once I fixed that, I could reuse threepp::GLRenderer as expected. Someone more familiar with three.js would have spotted it straightaway. I'm very pleased with it and the performance is certainly good enough for me.