DmitriySalnikov / godot_debug_draw_3d

Draw 3D debug graphics and 2D overlays with this add-on.
https://dd3d.dmitriysalnikov.ru/
Other
480 stars 25 forks source link

Adding Godot 4 Support #2

Closed wp2000x closed 1 year ago

DmitriySalnikov commented 2 years ago

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

image

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

image

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.

CookieBadger commented 2 years ago

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

DmitriySalnikov commented 1 year ago

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

DmitriySalnikov commented 1 year ago

image

godot windows editor dev x86_64_D77hVq9vUQ

wp2000x commented 1 year ago

@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)

image

DmitriySalnikov commented 1 year ago

@wp2000x As I mentioned in the comment to this commit 7133097220b78d931d405a5db56ca4e071e6c7bf, 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...

DmitriySalnikov commented 1 year ago

image

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

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 https://github.com/godotengine/godot-cpp/pull/950 https://github.com/godotengine/godot-cpp/pull/956).

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

wp2000x commented 1 year ago

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#?

DmitriySalnikov commented 1 year ago

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.

https://github.com/DmitriySalnikov/godot_debug_draw_3d/blob/d6b0fd70d124e278c78705225e7ba6408849c1a2/addons/debug_draw_3d/DebugDrawCS.cs#L9-L13

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).

DmitriySalnikov commented 1 year ago

One more issue:

wp2000x commented 1 year ago

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.

https://github.com/DmitriySalnikov/godot_debug_draw_3d/blob/d6b0fd70d124e278c78705225e7ba6408849c1a2/addons/debug_draw_3d/DebugDrawCS.cs#L9-L13

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.

DmitriySalnikov commented 1 year ago

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).

wp2000x commented 1 year ago

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.

DmitriySalnikov commented 1 year ago

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.

DmitriySalnikov commented 1 year ago

--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 🤷‍♂️ image


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

image

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

DmitriySalnikov commented 1 year ago

"Simple" instructions for API generation:

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.....

wp2000x commented 1 year ago

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.

2023-01-30_16-59-33

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?

DmitriySalnikov commented 1 year ago

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.

wp2000x commented 1 year ago

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 😄

DmitriySalnikov commented 1 year ago

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. image Otherwise, you will need to add a precompiled library... Which also forces you to edit the project settings.

DmitriySalnikov commented 1 year ago

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.

DmitriySalnikov commented 1 year ago

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

GeorgeS2019 commented 1 year ago

@DmitriySalnikov

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

DmitriySalnikov commented 1 year ago

@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.

DmitriySalnikov commented 1 year ago

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.

GeorgeS2019 commented 1 year ago

@DmitriySalnikov I believe this is the current status for GDExtension for c# https://github.com/godotengine/godot/pull/77410#issuecomment-1561883694

DmitriySalnikov commented 1 year ago

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.

GeorgeS2019 commented 1 year ago

@DmitriySalnikov

https://github.com/antonWetzel/GDExtensionCSharp/issues/1#issuecomment-1576276659

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");
        }
    }
}
DmitriySalnikov commented 1 year ago

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. image

DmitriySalnikov commented 1 year ago

too much off topic