ImPlot Success

[tomvdb]

Hi,

I had the need to use ImPlot so went down the rabbit hole of getting it to work with ImGuiNet. The concept is fairly simple:

(1) Compile native cimplot dll files

to compile updated cimplot files I forked and modified the ImGui.NET-nativebuild repo. My version is available here (https://github.com/tomvdb/ImGui.NET-nativebuild)

(2) Generate new implot cs code using the codegenerator with updated definitions from cimplot

I then forked ImGui.NET and added the new dll files and cimplot definitions. The imgui controller required an update to set the implot context, but from there I could then load the implot demo window as well as create a seperate window with a barchart.

My forked version of ImGui.Net is at (https://github.com/tomvdb/ImGui.NET)

I have only tried native windows builds for implot for now.

Its probably all too messy for a PR, but that is where I'm at if its useful for someone

[gregkwaste]

Hi @tomvdb. I'm trying to follow the same procedure for the ImGuizmo. I keep getting memory corruption errors which are 99.9% related to a mismatch between the definitions and the binaries.

My steps for trying to make imguizmo to work are the following:

1. I've cloned https://github.com/TillAlex/ImGui.NET-nativebuild

2. I've updated each submodule and made sure to checkout to the same version for both cimgui and cimguizmo (1.89.7)

3. I've also cloned the ImGui.NET repository and again made sure to checkout the corresponding version of the repository.

4. Using the provided generators on cimgui and cimguizmo projects I'm analyzing the sources using the provided scripts and I'm updating the definition files and also generate the corresponding source files for the C bindings.

5. I'm building the native libraries with cmake via VS.

6. I'm building the ImGui.NET Generator project to make sure that the generator is updated.

7. I copy the generated definition files (actually everything that was generated), to the corresponding folder of the Generator project of ImGui.NET (the build folder not on the project sources).

8. I use the ImGui.NET generator to generate the C# source files.

9. The source code files are copied to the "Generated" folder of the corresponding project.

10. I'm building ImGui.NET and ImGuizmo.NET

11. Crash -.- (Attempted to read or write protected memory. This is often an indication that other memory is corrupt.)

Have I missed a point? Can you please elaborate the process a little bit more?

Thanks!

PS: I also see that the latest stable version of ImGuizmo was 1.83. Is there any chance that the library is indeed broken and I should experiment with much earlier versions of ImGui???

[tomvdb]

Hi @gregkwaste,

As far as I can tell you steps looks good. That's the process I followed as well.

Two extra notes from my side:

(1) I had a crash as well on my first run of implot. I enabled mixed mode debugging in my project in Visual Studio so that it would jump into the C file and actually show me why it crashed. That helped me to realize that I had to add some extra CreateContext changes into the imguirenderer in the example. ie, with the mixed mode debugging you can get the underlying issue.

(2) As you noted in your PS, imgui is outdated, so you will definitely have to revert to an older cimgui to use that. Or update it with the changes required.

Hope that helps :)

[gregkwaste]

Hi @tomvdb thanks for your reply!

I also got ImGuizmo.NET to work!

I repeated the process again with 1.89.7, and I first tested just the imgui library to see if I can get it to work. And it worked pretty much directly once I selected the correct commit (based on the corresponding release).

Now the crash that I was getting with ImGuizmo was related to me not knowing how to exactly use the library. I tested some other functions of the dll and they worked so I could tell that the wrapper was indeed built correctly. It turned out that I was trying to begin an Imguizmo frame prior to setting a matching context for the library. Once I did that I had to find out how exactly to used it in order to render things on the screen.

It is working properly now! FINALLY!

Thanks for the suggestions!

[tomvdb]

Awesome :) Nicely done!

[guillaC]

It could be interesting to have a NuGet package ;)

[zaafar]

The reason it's not done up till now is because I couldn't figure out the release process of these new/other libraries.
For example, currently ImGui.NET is 1.89.9. How do I get 1.89.9 version of cimguizmo?

[sonoro1234]

All submodules of LuaJIT-ImGui are compatible with last cimgui version. Generally last masters.

[gregkwaste]

The reason it's not done up till now is because I couldn't figure out the release process of these new/other libraries. For example, currently ImGui.NET is 1.89.9. How do I get 1.89.9 version of cimguizmo?

Imguizmo hasn't received any substantial update for a while, so I guess that its code is still compatible, with the latest Imgui. For me, it worked for 1.89.7, so I guess 1.89.9 should also work.

[zaafar]

For me, it worked for 1.89.7, so I guess 1.89.9 should also work.

Please note that imgui doesn't follow the same versioning system that c# (.net) follows, so there might be some changes in 1.89.10 (or 1.90) that will break the imguizmo or other libraries. Given how often some of those repo are maintained or tested with the latest version of imgui (e.g. Nelarius/imnodes#181), it will severely reduce the speed at which I want to release imgui.net. The other option is that Sonoro1234 or I maintain each and every repo that exists (e.g. https://github.com/sonoro1234/imnodes) so that we can fix the compatibility issues ASAP. I do not want to do that.

Maybe we can release a new package (e.g. ImGUIAndOtherLibs.NET) that is only updated once every dependency (looking at the libs mentioned here ImGuiNET/ImGui.NET-nativebuild#3) is updated.

Sorry for the rant :)

[guillaC]

For me, it worked for 1.89.7, so I guess 1.89.9 should also work.

Please note that imgui doesn't follow the same versioning system that c# (.net) follows, so there might be some changes in 1.89.10 (or 1.90) that will break the imguizmo or other libraries. Given how often some of those repo are maintained or tested with the latest version of imgui (e.g. Nelarius/imnodes#181), it will severely reduce the speed at which I want to release imgui.net. The other option is that Sonoro1234 or I maintain each and every repo that exists (e.g. https://github.com/sonoro1234/imnodes) so that we can fix the compatibility issues ASAP. I do not want to do that.

Maybe we can release a new package (e.g. ImGUIAndOtherLibs.NET) that is only updated once every dependency (looking at the libs mentioned here ImGuiNET/ImGui.NET-nativebuild#3) is updated.

Sorry for the rant :)

Your suggestion to create a new package, such as 'ImGUIAndOtherLibs.NET,' appears to be an interesting option for addressing compatibility issues. No need to apologize, thank you for your work.

[sonoro1234]

The other option is that Sonoro1234 or I maintain each and every repo that exists (e.g. https://github.com/sonoro1234/imnodes) so that we can fix the compatibility issues ASAP. I do not want to do that.

Yes, cimnodes is the only repo affected because imnodes is stuck on imgui 1.89.4. See: Nelarius/imnodes#180

[tingspain]

The other option is that Sonoro1234 or I maintain each and every repo that exists (e.g. https://github.com/sonoro1234/imnodes) so that we can fix the compatibility issues ASAP. I do not want to do that.

Yes, cimnodes is the only repo affected because imnodes is stuck on imgui 1.89.4. See: Nelarius/imnodes#180

How about the new ImNodeFlow?

[zaafar]

o wow, we have another one.
these things keep growing :)