Adding Godot 4 Support about godot_debug_draw_3d HOT 30 CLOSED

from godot_debug_draw_3d.

After a lot of confusion, I was able to build a library for godot 4.

But I haven't even tried to display anything yet. At the moment I can't even register any function with pointers.

Some of these functions can be ignored, but the problem still remains. Callable::bind() is still unavailable, but it can also be avoided.

I also need to rethink how to initialize the displaying of everything. Previously, a node was simply created, now I want to use a singleton that is not added to the scene...

upd. At the moment I can't even set the value of a boolean variable.. Perhaps I'll wait until GDExtension works more stably.

from godot_debug_draw_3d.

@wp2000x As I mentioned in the comment to this commit 7133097, you need a newer version of Godot. Beta 8 doesn't include this change yet.
Use for example this version: https://github.com/godotengine/godot/actions/runs/3714553342
But don't expect this addon to work correctly. It's currently has problems with centering boxes, clearing memory when closing, clearing geometry when switching scenes, and many other problems.

I will try to fix them as soon as I solve the problem with a completely broken and reinstalled Windows...

from godot_debug_draw_3d.

"Simple" instructions for API generation:

• Clone the godot repository.
• Build an engine from sources or use pre-build binaries from the news
• Run "path to the godot's exe" --headless --project "path to the project with .gdextension\project.godot" --generate-mono-glue "path to cloned repository\modules\mono\glue"
• Following this documentation, you need to add a local NuGet source: dotnet nuget add source "absolute path to the local nuget source" --name MyLocalGodotSource
• Build C# assemblies: cd "path to cloned repository" then "modules/mono/build_scripts/build_assemblies.py" --godot-output-dir=./bin --godot-platform=windows --push-nupkgs-local "absolute path to the local nuget source"
• Clear the folder .godot/mono inside the project
• You may need to clear the nuget cache manually. Delete a folder %appdata%\Godot\mono\GodotNuGetFallbackFolder

I hope I didn't miss anything. But I don't like this solution. Maybe if you have a lot of .gdextensions and if you have worked with the godot builds, then this will be the easiest and most convenient way to add the C# API, but do it only for the sake of one extension.....

from godot_debug_draw_3d.

I think the porting is complete.
I have collected the remaining issues into a separate topic. #9

from godot_debug_draw_3d.

Everything looks fine now.
But there are still a lot of problems left:

• godotengine/godot#70362
• Fonts have a static size.
• Graphs are sometimes displayed in the wrong places.
• godotengine/godot#70512
• Geometry is not cleared when changing scenes.
• Variables from GDScript are not converted by values (godotengine/godot-cpp#907).
• Callable does not have a bind method (godotengine/godot-cpp#802). (fixed in 1e5ba73 by using bindv)
• Frustum culling does not work.

And most likely I missed something else.

Plus, for a successful build, you need to apply 2 patches (the corresponding Pull Requests have already been created for them godotengine/godot-cpp#950 godotengine/godot-cpp#956).

Examples and libraries updated in the master branch (requires beta9).

from godot_debug_draw_3d.

I haven't started working on the C# wrapper yet. I just decided not to delete this .cs file, even though it was generated by a script that no longer exists.

I'll see what I can do about it later. I need to check how C# code generators work and whether they can generate code from GDExtension. If not, then I will now be able to generate the .cs API file from ClassDB without any problems 🙂 (except that I do not know how to add documentation there).

from godot_debug_draw_3d.

--generate-mono-glue can't even generate mono glue for me

C:\My\Godot\godot_v4.0\beta15\Godot_v4.0-beta15_mono_win64.exe --project "C:\My\Projects\GE\DebugDraw3D 4.0\project.godot" --generate-mono-glue .

$ Godot Engine v4.0.beta15.mono.official.4fa6edc88 - https://godotengine.org
Vulkan API 1.3.224 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 970

Ignoring type 'AnimationNodeEndState' because it's not exposed
Ignoring type 'AnimationNodeStartState' because it's not exposed
Ignoring type 'CreateDialog' because it's not exposed
ERROR: FATAL: Condition "r_iarg.type.cname != name_cache.type_String" is true.
   at: _arg_default_value_from_variant (modules/mono/editor/bindings_generator.cpp:3272)

Now I need to understand where I use NodePath at all... and why is the name of this class not equal to String

Aah, this all applies to String, StringName and NodePath.

I got something 🤷‍♂️

I got a dll with bindings for debug_draw_3d. It remains to connect them correctly to the project.

🎉🎉🎉
(in this project, only one script has code, all other files are commented out)

from godot_debug_draw_3d.

Isn't this a "standard" fix for casting Objects from an internal Godot type to an external GDExtension or C#? (they just tried to fix it several times already)
Also here is the binding generator which was mentioned in the comments there.

from godot_debug_draw_3d.

GDExtensionCSharp is also not a GDExtension binding generator for C#.. This is an implementation of C# support via GDExtension.
If you are interested, then this is how it was implemented for a long time in my GDNative version for Godot 3: https://github.com/DmitriySalnikov/godot_debug_draw_3d/blob/godot_3/addons/debug_draw_3d/DebugDrawCS.cs.
This can also be implemented now, but this is a very bad way of calling methods, because every time there is a comparison of strings with method names, type conversions to variant and back. Whereas official bindings use lower-level method calls.

Now I am not sure that it is even possible to make such bindings now.

from godot_debug_draw_3d.

I think this will be extremely useful, so I would very much look forward to Godot 4 support :D

from godot_debug_draw_3d.

With some patches and hacks, I was finally able to see at least such a graph

upd:

from godot_debug_draw_3d.

@DmitriySalnikov I wanted to try out the CI build but get this error, any ideas why?(https://github.com/DmitriySalnikov/godot_debug_draw_3d/actions/runs/3688845973)

from godot_debug_draw_3d.

I think the C# interface needs also a bit of work, because it does not run anymore out of the box on Godot 4? (DebugDrawCS.cs)

Edit: In the meantime, i tried to do a hacky fix up for DebugDrawCS.cs and creating a instance of the GD Extenstion via ClassDB with ClassDB.Instantiate("DebugDraw"); but it is not working, is this a Godot bug?
ClassExists and CanInstantiate are both returning true.
Or is there a different way to access the lib in C#?

from godot_debug_draw_3d.

One more issue:

• godotengine/godot#71897

from godot_debug_draw_3d.

I haven't started working on the C# wrapper yet. I just decided not to delete this .cs file, even though it was generated by a script that no longer exists.

godot_debug_draw_3d/addons/debug_draw_3d/DebugDrawCS.cs

Lines 9 to 13 in d6b0fd7

	/// ////////////////////////////////////////////////
	/// THIS FILE HAS BEEN GENERATED.
	/// CHANGES IN THIS FILE WILL BE OVERWRITTEN AFTER THE UPDATE!
	/// SEE debug_draw_3d/generate_debug_draw_3d_api.gd
	/// ////////////////////////////////////////////////

I'll see what I can do about it later. I need to check how C# code generators work and whether they can generate code from GDExtension. If not, then I will now be able to generate the .cs API file from ClassDB without any problems 🙂 (except that I do not know how to add documentation there).

Great! Im waiting eagerly, so that i can re-intergrate it into my GD4 C# project. Any ETA? 😄
I didn't saw any C# code generation in Godot for custom engine extenstions, so ClassDB came into my mind how to connect it. But that is also not really working.

from godot_debug_draw_3d.

I didn't saw any C# code generation in Godot for custom engine extenstions

I found that it is possible to do so https://www.reddit.com/r/godot/comments/zlglpk/comment/j081fkm/?utm_source=share&utm_medium=web2x&context=3
But it doesn't work correctly..
Maybe I can find out from there how to make a good binding generator.

At the moment I want to add a small optimization of instances data transfer to Godot.
After that, I will either try to fix memory leaks when closing the engine, or add a C# wrapper.

And it would also be interesting how difficult and whether it is even possible to add support for other C++ libraries (use debug_draw_3d from another GDExtension library).

from godot_debug_draw_3d.

Ah, good to know, that the mono glue generator also tries to generate it for extenstions. I also found this: https://github.com/antonWetzel/GDExtensionCSharp maybe it will help you as a base for a binding generator.

from godot_debug_draw_3d.

If I understand correctly, this is not what I need. Here the developer makes an alternative to godot-cpp but in C#. But I may still study this repository if I encounter some problems. Thanks.

from godot_debug_draw_3d.

Nice! Will test it out. Would it maybe make sense to ship a pre-generated nuget for every DebugDraw version release on nuget.org for this approach?

Edit: Ah i see now the problem, its one big glue package.

I build the Nugets successfuly, and verified that debugdraw is in there, but the project refuses to use those nugets. The local nuget source is there but the DebugDraw interface classes are not recognized. Deleting .godot/mono and %appdata%\Godot\mono\GodotNuGetFallbackFolder does not help.

Would it maybe be possible to separate the DebugDraw assembly part from the glue and make it as a standalone dll/nuget?

from godot_debug_draw_3d.

The local nuget source is there but the DebugDraw interface classes are not recognized. Deleting .godot/mono and %appdata%\Godot\mono\GodotNuGetFallbackFolder does not help.

I also faced this and struggled with it for a while. Clearing all caches and recreating the C# project helped me (maybe I did something else).

I have already asked a question in godot's RocketChat about generating an API for GDExtension, but there has been no answer yet. Most likely I will have to write a proposal.
My plan for now is to make my own C# API generator (or copy it from Godot) until the official one appears.

But unfortunately I can't develop the project yet. My PC's PSU failed and I'm without a PC until at least February 3rd.

But if you manage to use local nuget packages, then you can safely use them, because I will try to make the generator as close as possible to the Godot generator. And most likely it will be just a .cs file inside your project again.

from godot_debug_draw_3d.

I tried further, but still the same. Guess i will wait for your API generator.
Good idea with the proposal, something like this would be very nice when implemented out of the box.
Good luck with your PSU 😄

from godot_debug_draw_3d.

I found one annoying problem. The entire C# API consists of unsafe code.
This means that users of this extension will need to enable this checkbox if I generate a .cs file with API inside project.

Otherwise, you will need to add a precompiled library... Which also forces you to edit the project settings.

from godot_debug_draw_3d.

I tried several options with changing the original generator to support GDExtension API generation, but nothing worked. Even if you get direct access to all the internal methods and classes of GodotSharp.dll (InternalsVisibleToAttribute), there will still be problems with the Godot's SourceGenerator.
I will have to make my own generator from scratch and without maximum performance of GodotSharp.dll, or I'll just postpone C# support for now.

I want to release a GDScript-only version first. And if no one has created a proposal yet, then I need to write it as well.

from godot_debug_draw_3d.

@DmitriySalnikov

This could be a possible way to deal with GDExtensiong binding for c# based on ideas from LibGodotSharp

from godot_debug_draw_3d.

@GeorgeS2019 I noticed only a copy paste of my solution there, the rest will not help me in any way. But if I understood everything correctly, then you have confused GlobalClass with bindings for GDExtension.
As @j20001970 said:

it is about allowing C# classes to be registered as global classes (similar to Autoload in GDScript), not using GDExtension classes in C#

I would say that GlobalClass is an analog of class_name from GDScript.
And I agree with him that at the moment it is better to wait until the official support for GDExtension in C# appears. Or you can help Godot with the implementation of this feature.

from godot_debug_draw_3d.

Do you mean compiling the entire C# interop code only with my bindings (GodotSharp.dll and all tools libs)? Or only GodotSharp.dll with only my classes?

In the first case, it seemed to me that Godot.exe can only load specific predefined DLLs. And I am not sure that I will be able to load and use a full-fledged separate C# interop.
And in the second case with generation only GodotSharp.dll, I have already tried and faced a bunch of problems and errors. I tried to duplicate the C# interop generator from the Godot module, cutting out all unnecessary and replacing some names with my own so that there would be no conflicts.

Do you already have a ready-made prototype with the implementation of your ideas? I would be interested to see it.

from godot_debug_draw_3d.

@DmitriySalnikov
I believe this is the current status for GDExtension for c#
godotengine/godot#77410 (comment)

from godot_debug_draw_3d.

@DmitriySalnikov

antonWetzel/GDExtensionCSharp#1 (comment)

namespace GDMP {
    class SomeCoolObject {
        private GD.Object data;
         
        public SomeCoolObject() { this.data = GD.Instantiate("GDMPSomeCoolObject"); }

        public SomeType SomeFunction() {
            return (SomeType)this.data.call("some_function");
        }
    }
}

from godot_debug_draw_3d.

too much off topic

from godot_debug_draw_3d.