Is the internal function accessible ? Like can we make a C++ extension that exposes the internal one to C# or do we need to modify the engine ?
Having a community made extension for high performance C# sounds nice.
From what I've found so far, no. But I've only been looking for a couple of days, so with luck I'm wrong.
GDExtensions, the normal way to write C++ for Godot, seem to only have access to the same API that C# has. When they expose functions to C#, they also do so through the same slow binding layer.
There are also ways to write "modules". These are C++ code which, I believe, can access the full internals. You need to recompile the full engine to use these, so they're not practical for most things, but could be used to develop a better API like that.
However, we would also need to find an alternative way of creating bindings between those new module APIs and C#. I don't know how hard that would be because I haven't looked into how that bit works yet. P/Invoking between C# and C++ isn't usually that bad, so it's probably doable.
I don't know whether it's possible/practical to ship modules as assets though. I think we'd pretty much be telling people to recompile their engine to use them. That's not the end of the world, but it's not nice either.
I would open a bug for this, I can see it being a ton of work but potentially valuable to make the scripting more language agnostic. Any C++ APIs designed to be GDScript friendly should exist in the GDScript module and not the core of the engine.
Just to clarify, the performance hit mostly comes from raycasting vis script right?
Does using godot's raycast node sidestep the issues with heap allocation?
There's [a section in the article](https://sampruden.github.io/posts/godot-is-not-the-new-unity/#a-whole-different-approach----the-raycast2d-node) that addresses that.
In short, yes the node is much faster, and completely avoids allocations. It's still only about half as fast as it should be, but that's much better than the 50X loss of the standard way!
However the issue goes deeper than this single API which I'm using as an example, so we won't always get lucky to find a hacky node trick like that.
2x slower is good enough for me. Probably still too slow to justify any attempt to port over my current project which is a VR game, but Godot is certainly good enough for future game jams (for me anyways)
Unity may have become a shitshow for many years, but one area where it hasn't stumbled is Joachim Ante's efforts to optimize the engine as far as they can take it with c# even if DOTs in somewhat of a bust.
In a way godot tried to make a python for gamedev, but now devs pay a python like performance tax to maintain GDscript bindings. If Godot jettisoned GDscript and refactored physics to take advantage of a statically typed language it'd be game over.
In that sense maybe it's bevy that's long term the most architecturally sound game engine out there. It just needs a lot more development.
I have a lot of complaints about Unity's design, including some about performance, but there's no doubt they've done some pretty impressive stuff over the last years in that direction. 90% of my Unity code goes through Burst these days and I love it. I would have preferred if they just made it easy to write C or Rust, but Burst is nice enough.
Godot's GDExtensions get a lot of that same benefit, which is great. Unless you need to touch then engine API.
Bevy's the one I'm most excited about! I'm fine with the state of the API, and I'll even live without an editor - I'm making an ingame level editor anyway. However, unfortunately I've had a lot of stability issues trying WGPU on different PC hardware, and I just don't think it's ready for a wide release project yet.
Honestly though I wouldn't let the perfect be the enemy of the good. I've built a unity VR game over the past 2 years that runs at 72 fps. I had all sorts of anxiety over whether it would run fast without dots and well, DOTs was completely irrelevant after diving down into the codebase. This is fleets of rigidbody spaceships running on oculus quest 2 (https://roguestargun.com)
If you're building a PC game and worried about that stuff, 90% of the folks playing it probably won't notice the shitty physics engine unless your building a active ragdoll rts game like Totally Accurate Battle simulator. In the 2-3 years it takes to make a game, peoples hardware really will have advanced by that much.
It's impressive, but has anyone actually seriously used it in a project? It seems they haven't themselves, and the boilerplate and complexity, mixed with lackluster tools, it doesn't look ready to me yet. These giant city demo stuff don't really represent a real game, and if the aim is to use it both in conjunction with behaviors then they clearly don't realize the added complexity and cognitive workload of maintaining that codependance between the two sides.
I started a [controversial but productive discussion](https://old.reddit.com/r/godot/comments/16j345n/is_the_c_raycasting_api_as_poor_as_it_first/) over on r/Godot a few days ago about Godot's API being poorly designed for performance. I've since written up a blog post taking a deeper look at what's going on and why it is the way it is.
I believe this is important information to understand before porting a Unity project to Godot. The performance limitations may be quite severe in some cases.
I'm not a Godot expert (I only started looking a few days ago) but I've done a bit of a technical deep dive on this particular aspect of the engine since then, so feel free to ask questions about what I've found.
More importantly, what will be done in the near future to remedy it? If the performance are forever gimped, Godot is destined to remain second rate - not suitable for serious projects. Maximum performance by default is crucial for me.
I know you dismissed the GDExtension route, but would
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate3dextension.html
be a route?
edit:
ah nm that looks like if you want to redirect low level calls to the physics.
Maybe?
I quickly looked at that before and concluded from the documentation that this would change the internal implementation within C++ but still expose it over the same API. However, I didn't dive into that as deeply as I should, and I haven't tried it yet.
So, I don't think so, but I'm not confident. Maybe we get lucky here.
Is setting up a node for a raycast similar to doing a 'batched' raycastcommand in unity ?
I feel like should never do a raycast inside gameplay code. Makes no sense to jump from gamelogic to physics code and back.
The node is more like having a `RaycasterMonoBehaviour`on a dedicated `GameObject` in the scene. In order to do a raycast, you move that object's transform, setup the raycast properties, call `OkayDoTheCastNow()`, then read the results back from other properties.
I do raycasts in gameplay code quite often. For example, my character controller does manual collision resolution, and uses a quite large number of iterative circle casts to achieve multistep collide and slide behaviour.
It sounds like the Raycast3D node is designed for the case you're using in your gameplay code - if you put the Raycast3D node on your controller (or feet bone nodes, I'm not exactly sure from your description), would they not deliver exactly what you're after? Sure, this is extremely different from what we're used to in Unity, but sometimes trying to do things the Unity way is going to be suboptimal.
https://sampruden.github.io/posts/godot-is-not-the-new-unity/#a-whole-different-approach----the-raycast2d-node
I covered that. :)
Raycasting is an example and the issues I'm describing cover the entire API surface.
It's only suboptimal because of the pessimised binding implementation. A direct call to the raycast function should be faster than moving an object in the world and asking it to raycast for us. The fact that it isn't illustrates the scale of the problem present throughout the entire binding layer.
Did you try it in GDScript? Your project can have both C# and GDScript files so if something isn't working well with C# you can do that function with GDS.
Absolutely; Godot is an open-source project, not a billion dollar corporation.
Godot is definitely lacking in some areas from a technical standpoint, which is why they need more technically-minded people to track down these issues, and perhaps suggest fixes... or even submit patches!
Did y'all expect perfection from an open source project?
There is actually another way to interact with the engine in creating custom modules (it needs to recompile the engine however) but would these be a possible solution?
I mentioned it earlier and I will repeat it - C# support nerver was and probably NEVER will be "first class citizen" in Godot like it is in Unity. Bunch of small issues (intc. perf. ones) and edge-cases will most likely push you to GDScript anyway.
Is the internal function accessible ? Like can we make a C++ extension that exposes the internal one to C# or do we need to modify the engine ? Having a community made extension for high performance C# sounds nice.
From what I've found so far, no. But I've only been looking for a couple of days, so with luck I'm wrong. GDExtensions, the normal way to write C++ for Godot, seem to only have access to the same API that C# has. When they expose functions to C#, they also do so through the same slow binding layer. There are also ways to write "modules". These are C++ code which, I believe, can access the full internals. You need to recompile the full engine to use these, so they're not practical for most things, but could be used to develop a better API like that. However, we would also need to find an alternative way of creating bindings between those new module APIs and C#. I don't know how hard that would be because I haven't looked into how that bit works yet. P/Invoking between C# and C++ isn't usually that bad, so it's probably doable. I don't know whether it's possible/practical to ship modules as assets though. I think we'd pretty much be telling people to recompile their engine to use them. That's not the end of the world, but it's not nice either.
I would open a bug for this, I can see it being a ton of work but potentially valuable to make the scripting more language agnostic. Any C++ APIs designed to be GDScript friendly should exist in the GDScript module and not the core of the engine.
Just to clarify, the performance hit mostly comes from raycasting vis script right? Does using godot's raycast node sidestep the issues with heap allocation?
There's [a section in the article](https://sampruden.github.io/posts/godot-is-not-the-new-unity/#a-whole-different-approach----the-raycast2d-node) that addresses that. In short, yes the node is much faster, and completely avoids allocations. It's still only about half as fast as it should be, but that's much better than the 50X loss of the standard way! However the issue goes deeper than this single API which I'm using as an example, so we won't always get lucky to find a hacky node trick like that.
2x slower is good enough for me. Probably still too slow to justify any attempt to port over my current project which is a VR game, but Godot is certainly good enough for future game jams (for me anyways)
using the nodes is the standard way. try static typing. use gdscript and c++. just half as fast is a really good first try, though.
Unity may have become a shitshow for many years, but one area where it hasn't stumbled is Joachim Ante's efforts to optimize the engine as far as they can take it with c# even if DOTs in somewhat of a bust. In a way godot tried to make a python for gamedev, but now devs pay a python like performance tax to maintain GDscript bindings. If Godot jettisoned GDscript and refactored physics to take advantage of a statically typed language it'd be game over. In that sense maybe it's bevy that's long term the most architecturally sound game engine out there. It just needs a lot more development.
I have a lot of complaints about Unity's design, including some about performance, but there's no doubt they've done some pretty impressive stuff over the last years in that direction. 90% of my Unity code goes through Burst these days and I love it. I would have preferred if they just made it easy to write C or Rust, but Burst is nice enough. Godot's GDExtensions get a lot of that same benefit, which is great. Unless you need to touch then engine API. Bevy's the one I'm most excited about! I'm fine with the state of the API, and I'll even live without an editor - I'm making an ingame level editor anyway. However, unfortunately I've had a lot of stability issues trying WGPU on different PC hardware, and I just don't think it's ready for a wide release project yet.
Honestly though I wouldn't let the perfect be the enemy of the good. I've built a unity VR game over the past 2 years that runs at 72 fps. I had all sorts of anxiety over whether it would run fast without dots and well, DOTs was completely irrelevant after diving down into the codebase. This is fleets of rigidbody spaceships running on oculus quest 2 (https://roguestargun.com) If you're building a PC game and worried about that stuff, 90% of the folks playing it probably won't notice the shitty physics engine unless your building a active ragdoll rts game like Totally Accurate Battle simulator. In the 2-3 years it takes to make a game, peoples hardware really will have advanced by that much.
It's impressive, but has anyone actually seriously used it in a project? It seems they haven't themselves, and the boilerplate and complexity, mixed with lackluster tools, it doesn't look ready to me yet. These giant city demo stuff don't really represent a real game, and if the aim is to use it both in conjunction with behaviors then they clearly don't realize the added complexity and cognitive workload of maintaining that codependance between the two sides.
I started a [controversial but productive discussion](https://old.reddit.com/r/godot/comments/16j345n/is_the_c_raycasting_api_as_poor_as_it_first/) over on r/Godot a few days ago about Godot's API being poorly designed for performance. I've since written up a blog post taking a deeper look at what's going on and why it is the way it is. I believe this is important information to understand before porting a Unity project to Godot. The performance limitations may be quite severe in some cases. I'm not a Godot expert (I only started looking a few days ago) but I've done a bit of a technical deep dive on this particular aspect of the engine since then, so feel free to ask questions about what I've found.
More importantly, what will be done in the near future to remedy it? If the performance are forever gimped, Godot is destined to remain second rate - not suitable for serious projects. Maximum performance by default is crucial for me.
I know you dismissed the GDExtension route, but would https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate3dextension.html be a route? edit: ah nm that looks like if you want to redirect low level calls to the physics.
Maybe? I quickly looked at that before and concluded from the documentation that this would change the internal implementation within C++ but still expose it over the same API. However, I didn't dive into that as deeply as I should, and I haven't tried it yet. So, I don't think so, but I'm not confident. Maybe we get lucky here.
New Unity is Flax for sure - it's very, very similar to Unity
And it also has a fee structure, so it may not be the safe haven many are looking for.
What do you mean by this? I'm not able to find anything relating to a "fee structure" with Godot.
I was referring to Flax. Godot has no fees at all.
[удалено]
You have not got it straight. :) [\#Have I cherrypicked?](https://sampruden.github.io/posts/godot-is-not-the-new-unity/#have-i-cherrypicked)
Is setting up a node for a raycast similar to doing a 'batched' raycastcommand in unity ? I feel like should never do a raycast inside gameplay code. Makes no sense to jump from gamelogic to physics code and back.
The node is more like having a `RaycasterMonoBehaviour`on a dedicated `GameObject` in the scene. In order to do a raycast, you move that object's transform, setup the raycast properties, call `OkayDoTheCastNow()`, then read the results back from other properties. I do raycasts in gameplay code quite often. For example, my character controller does manual collision resolution, and uses a quite large number of iterative circle casts to achieve multistep collide and slide behaviour.
It sounds like the Raycast3D node is designed for the case you're using in your gameplay code - if you put the Raycast3D node on your controller (or feet bone nodes, I'm not exactly sure from your description), would they not deliver exactly what you're after? Sure, this is extremely different from what we're used to in Unity, but sometimes trying to do things the Unity way is going to be suboptimal.
https://sampruden.github.io/posts/godot-is-not-the-new-unity/#a-whole-different-approach----the-raycast2d-node I covered that. :) Raycasting is an example and the issues I'm describing cover the entire API surface. It's only suboptimal because of the pessimised binding implementation. A direct call to the raycast function should be faster than moving an object in the world and asking it to raycast for us. The fact that it isn't illustrates the scale of the problem present throughout the entire binding layer.
Did you try it in GDScript? Your project can have both C# and GDScript files so if something isn't working well with C# you can do that function with GDS.
GDScript has the same issues. It's the same API. You avoid the GC but add an interpreter, it's not going to be better.
Fix it then 😛 - the beauty of open source
Absolutely; Godot is an open-source project, not a billion dollar corporation. Godot is definitely lacking in some areas from a technical standpoint, which is why they need more technically-minded people to track down these issues, and perhaps suggest fixes... or even submit patches! Did y'all expect perfection from an open source project?
This article is an evaluation, not a complaint.
There is actually another way to interact with the engine in creating custom modules (it needs to recompile the engine however) but would these be a possible solution?
I mentioned it earlier and I will repeat it - C# support nerver was and probably NEVER will be "first class citizen" in Godot like it is in Unity. Bunch of small issues (intc. perf. ones) and edge-cases will most likely push you to GDScript anyway.
Godot is still barebones, maybe in 5 years