Custom JointLimitation - Overriding a C++ function in GDScript

Help Programming
, ,
1

Godot Version

4.6.1

Question

I’ve been trying to make custom limitations for Inverse Kinematics joints. I created my class extending JointLimitation3D, and overriding the _solvefunction to have a custom one (like the only “vanilla” JointLimitation, JointLimitationCustom3D does in here). But it doesn’t work, the function doesn’t even seems to be called (I tried to print things in there but it doesn’t work). Calling super._solve() in the function doesn’t work as well, tells me it doesn’t exists (which is what leads me to think that I can’t override that function). I haven’t found much documentation about overriding C++ functions, but from what I know from this tutorial it shouldn’t be a problem. If anyone knows how to achieve what I want, please let me know.

Thanks in advance !

2

So I checked and _solve() is a virtual function. That means you should be able to override it.

However for us to troubleshoot your problem, you’re going to have to show us your code. (The whole file - not just the _solve() function.) Format your code by doing this:

```gd
#Code here
```

It will appear like this:

#Code here
3

Here’s my code. So far it’s basically nothing since I’m just testing things.

extends JointLimitation3D
class_name JointLimitationCustom3D

@export_range(-180, 180, 0.1, "degrees") var min_angle: float:
  get:
    return min_angle
  set(value):
    min_angle = min(value, max_angle)
@export_range(-180, 180, 0.1, "degrees") var max_angle: float:
  get:
    return max_angle
  set(value):
    max_angle = max(value, min_angle)

func _solve(direction: Vector3) -> Vector3:
  print("VGUDHYIHZQDVUYIUOQJZDOHUUQZDOIJP")
  
  # var center_axis = Vector3.UP
  
  # var current_angle = direction.angle_to(center_axis)
  
  # if min_angle <= current_angle <= max_angle:
  #   return direction
  
  # var plane_normal
  
  # if is_equal_approx(current_angle, PI):
  #   plane_normal = Vector3.RIGHT
  # else:
  #   center_axis.cross(direction).normalized()
  
  # var max_rotation = Quaternion(plane_normal, max_angle)
  # var min_rotation = Quaternion(plane_normal, min_angle)
  

  return Vector3.UP

Nothing prints in the console when I start the scene this object is used in (with a CCDIK3D)

4

What’s your Scene Tree look like? (Screen shot please.) Is your joint attached to a ChainIK3D?

5

image
image273×288 10.7 KB

Above is my scene tree. CCDIK3D inherits from ChainIK3D, so it should be good. In the next message are the settings of the CCIK3D, where the joint uses JointLimitationCustom3D as Limitation (i can only add one image per message).

Not all my bones show up here, but it should be normal as they don’t all have child nodes (in that case it’s just textures, that’s how the .glb after blender export)

6

image
image635×1361 79.5 KB

7

Does this work as expected before you use your customized node?

8

Yep, using JointLimitationCone3D works as expected.

9

Nope, that is not how it works. Don’t go looking in C++ code for virtual functions thinking you’ll be able to override them in script, you won’t.

If you must look in the C++ code, script overridable functions are ‘declared’ (actually implemented by boilerplate) in header files with macros beginning GDVIRTUAL, with the number of args it takes appended (part of the macro, so GDVIRTUAL2(foo, int, float) GDVIRTUAL4(bar, Vector2, float, bool, bool), etc). There are then matching GDVIRTUAL_BIND() calls in _bind_methods() where meaningful names for the args can be set, and that registers it in the ClassDB.

Or just look at the GDScript docs, where such functions will be listed. If it aint there, you are out of luck :frowning:

C++ virtual != GDScript overridable

2 Likes
10

Yeah, it doesn’t appear in the GDScript docs, thanks for confirming my suspicions.

Is there any other way I can customize the way a joint limits itself in a ChainIK3D ? In that case, in theory JointLimitationCone3D could work for me if I could move the center of the cone (I know moving the bone would do the trick, but i’m not sure if that would break the rest of skeleton or not).

Or maybe it is worth it to go and make a pull request to Godot to implement the GDVIRTUAL macro for this function myself ?

Sorry, that’s a lot of questions at once, but I hope someone’ll be able to answer them.

Thanks in advance !

11

You can actualy extend it, you’ll just have to drop down to C++.

In terms of customisation it only appears to have single property angle, how it is connected to the skeleton I have no idea about (never played with this stuff), but it must connect to a joint and be orientable somehow (one would think).

An IK-Solver is not something you would typically implement in a scripting language, worth a try if you like of course, but I doubt they would make _solve() GDVIRTUAL, this is a thing you do with native code.

12

Ok, I’ll try to look into C++ then, thanks a lot !

13

Okay, so after trying a lot, I found out that the _solve function, despite being virtual, is not possible to override using GDExtension and godot-cpp, since it doesn’t appear in the engine’s extension_api.json and it is not defined in the code generated by godot-cpp :

// THIS FILE IS GENERATED. EDITS WILL BE LOST.

#pragma once

#include <godot_cpp/classes/ref.hpp>
#include <godot_cpp/classes/resource.hpp>

#include <godot_cpp/core/class_db.hpp>

#include <type_traits>

namespace godot {

class JointLimitation3D : public Resource {
	GDEXTENSION_CLASS(JointLimitation3D, Resource)

public:
protected:
	template <typename T, typename B>
	static void register_virtuals() {
		Resource::register_virtuals<T, B>();
	}

public:
};

} // namespace godot

So what do I have left as options ? Would custom C++ modules help me ? I’m trying to avoid this solution as much has possible, since having to ship a custom version of the engine seems like a pain…

Where would I even start to make the _solve function modifiable by GDExtensions ?

14

You’d make a feature request and get feedback, then implement it with a PR.

15

Oh wow, yes of course; for GDExtension ‘normal’ virtuals won’t be able to pierce the binding wall, it’s essentially the same wall you were facing initially.

So module would be the only way to push ahead yourself now. (FWIW, the engine compiles in a reasonable amount of time, for a large cpp project, and after the first time you are only building your module).

Else the feature request to expose it, which I still feel is unlikely but may be worth a try.

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.