Last month I made a lot of small experiments and learned quite a lot of new interesting things. So let's talk about that.

It all started when I was creating the environment for the recent stencil tutorials.

I found it very annoying to place the each coins individually on the table, and I remember there was a blender addon that let's you simulate physics to place things there.

Physics placer addon

So I decided to do it for Godot too. Enabling physics in the Editor is simple enough.But things were not going well.

It took an embarrassing amount of time to figure out my table mesh had wrong normal.And this was causing the collision trimesh generated to be inverted.

The reason this was hard to find is actually due to an inconsistency with Godot's extracted materials pipeline.

When using internal material, Godot will assign a basic material for your mesh based on your model. So far so good.

But if you choose to extract that material, the generated material is not the same.You'll likely get the "same" material, but with cull disabled instead.

That's because, when extracting the material, Godot will follow blender's material viewport camera preference. (Which defaults to disabled).

Which is why all my materials (that I extracted to create them), had cull disabled. So I didn't see the normals were all wrong.

But even after that, I found myself kinda stuck in a limitation in the physics engine. Basically, Jolt is not made to work with small objects.

It is recommended to keep dynamic objects between [0.1, 10] meters. and static at [0.1, 2000]

The problem is, the coin dimensions are 0.05 by 0.05 by 0.009. And that causes problems.

Physics can become very wonky at this small sizes. I tried to increase the solver iterations, reduce penetration, biases. Enable continuous integration. But nothing seems to make much difference at this scale.

One possible solution that I found sometimes works better is to multiply the collider size, and scale down the collider node by that same amount. But it is not perfect.

Editor Gizmos

Than one day I decided I wanted to see how gizmos works in the editor.

I know you can only make then by using addons. And I knew 3D gizmos have a proper class to help handle and create them. But for some reason I decided to start with 2D because they might be easier to understand.

Well.... turns out 2D doesn't have a helper class to handle gizmos. But the EditorPlugin class structure already give you all the things you need to create your gizmos in 2D.

So a made a simple example to test things out.

You start by declaring a _handles() function to indicate if the selected node needs a gizmo. And if so, the _edit() and _make_visible() are called. Both which gives you the access to the selected node object.

And when handles() returns true, the forward_canvas_draw_overviewport() is also called. Here's where you can draw your gizmos. You are given an overlay Control node reference where you can call any of the usual draw 2d functions.

And for the input, you can use the plugin's foward_canvas_gui_input(). Which is also enabled when the handles() is returning true.

Unlike the 3D counterpart, you'll need to do your own drag logic for the points.The grab logic is not complicated, but when working with gizmos you need to convert back and forth from global coordinates, to world coordinates, and viewport cordinates.

So it can be a bit confusing understanding what all those transforms multiplications and affine_inverses do. But they are very much necessary for things to work.

Here is the code for the drag logic for the above gizmo:

Inspector plugins

After that, I decided to learn a bit about Inspector plugins since I'm already deep into editor plugins.

And something that has always annoyed me is changing the sky colors in Godot. More specifically, non-matching horizon colors. I hate to have to set both the ground and sky colors separately to make them match. So I thought I would try to solve that.

InspectorPlugin is its own class you need to register. But they work very similar to gizmos by using a _can_handle() function to indicate if they should change the inspector.

After that, you can freely add controls inside. Or use the proper EditorProperty class. This class syncs the class variable to its value and comes with a few signals.

I had a few problems to inject the sync functionally I wanted at first, and ended up having to re-implement the EditorProperty's ColorPicker because that it not exposed to gdscript, and I needed to replace the original property to make what I wanted. I couldn't find a way to get a direct reference for the current EditorProperty in use already to use their signals.

But in the end, it all worked great and I can finally change sky horizon colors together.

Procedural animations? IK experiments

So by this time I was done playing with the editor, and decided I wanted to make a simple game just so my game programming don't get too rusty.

But I really didn't want to make animations, as they take quite a bit of time for me, and I wanted something simple, but nice looking.

And that's when I remembered procedural animations. It might be fun.So I took a look at Godot IK node just to found out that it is actually deprecated.

I think since 4.3 they refactored the whole SkeletonModifier system, and in 4.4 they finally released the new modifier nodes to replace the old system.

These new nodes are very easy to use and work quite well. But there is no current replacement for the old SkeletonIK3D, the old IK solution.

So what I found works, is to use multiple LookAtModifier3D nodes in a hierarchy.

It works quite well, and looks very similar to an actual IK controller.

But while this works now, I don't know how well it would work when I start messing around with procedural animations. It might turn into a gigantic headache trying to adapt this to normal IK behavior in edge cases.

It seems the old SkeletonIK3D can still works as of now, but I haven't tried it yet. And I don't want a solution that might break in the future.

And that's when I found out about FABRIK. A very simple 2-pass algorithm to calculate IK joints. It has a simple implementation and is very fast. No need for crazy maths.So I thought I might as well learn how the SkeletonModifier3D works while I implement it in gdscript.

And that's when I stopped to make this post. And now I realized I'm nowhere even near starting to make the simple prototype game I set out to make initially.

Future videos and overdues

As you might realized. I learning a lot of new interesting things in the last few months.

But I'm very slow to turn them into videos. To the point that I'm already forgetting how I made some older stuff I wanted to make videos about at the time.

So, here's a list of things I learned that I need/want to make videos about:

Procedural Geometry / Terrain generation

Custom advanced Drag & Drop system (I made this nice system a while ago, but might have forgotten how it works by now)

Inspector Plugins

2D Gizmos Plugins

3D Gizmos Plugins

How to deal with small physics (if I ever figure this out)

Simple Finite State machine + examples

Behavior Tree AI with Beehave + custom nodes

Rayast Car continuation

Skeleton Modifier stuff / IK solutions

Other things I forgotten

And these are only the topics that I already have the code/examples made from a while ago.

I'm still not sure what next video topic I want to make.

I also want to revisit the raycast car again. If I do, first, I plan to fix the breaks (add proper break force) and add shapecast wheels.

Then fix the horrible side-force thing that I made. Which is what made me take a break from the raycast car to refresh my mind a bit. I think I'll add a physics player controller to push the car around to test more edge cases. (or just add a button to throw rocks at the car).

It might be easier to just use the simplified Pacejka model formula for cars like more advanced raycast sims do. But I'll take a better look at that later.

It's easy enough to implement, as the formula is already there. So I might make a video trying that out at some point too to see if it works better than what I came up with.

I'm still not sure about implementing acceleration torque and weight distribution to the car.While it might improve the simulation by a lot, I think it overcomplicates things, and I want to have a simple implementation that works for a lot of simple cases and let you improve it as needed.

I still have a lot of plans for the Raycast car. But I would need to solve those physics problems first to really start prepping the cars to make them game-ready.

But that's it for now. Just want to write a recap of random stuff I played around with this past month.

Thanks for reading, and until next time.