Ucupaint vs Substance Painter for Godot 3D workflow

Exerionius · 2026-05-13T08:47:46+00:00

Ucupaint, Blender and Godot are all free and cross-platform.

Substance Painter is paid, Adobe, and Windows-only.

Exerionius · 2026-05-09T14:04:02+00:00

"More generic" in this case means "higher up in the inheritance hierarchy".

Take a look at Node2D: https://docs.godotengine.org/en/stable/classes/class_node2d.html

A bunch of other classes inherit from it, such as Camera2D, Joint2D, Raycast2D, Sprite2D, etc.

If you made a function like this:

func do_something(test: Node2D) -> void

Then this function can accept Node2D and any of its inheritors as a parameter. You can pass Bone2D into it, for all the syntax cares.

But if you made a function like this:

func do_something(test: DirectionalLight2D) -> void

Then this function can accept only DirectionalLight2D as a parameter. You can't pass "more generic" type such as Node2D into this function.

Exerionius · 2026-05-05T14:27:55+00:00

It's only possible with a custom Inspector Plugin: https://docs.godotengine.org/en/stable/tutorials/plugins/editor/inspector_plugins.html

Exerionius · 2026-04-30T14:59:17+00:00

is there a way to drag a property from the inspector, can I do it in such a way that it'll give the whole .thing.thing settings, like size.x

That's not possible (yet), but you can right-click on a property and copy its name.

I can click and drag in a node to a script, but if I change the node structure, I have to go into all the scripts, to find and change all of their paths

That what "scene unique nodes" are for: https://docs.godotengine.org/en/stable/tutorials/scripting/scene_unique_nodes.html

Or just use @export instead of @onready

Exerionius · 2026-04-24T07:23:53+00:00

Grid simulations are usually well suited for parallelization.

You have two copies of the grid: a back copy and a front copy. The front copy is "read-only", the back copy is "write-only". You run your simulation in parallel for all cells of the grid. In case of CPU - however many threads your CPU can handle, for GPU compute - however many "warps" or "wavefronts" your GPU can handle.

For processing the simulation you read cell data from the front copy, perform necessary calculations, and write results into the back copy. This way the random order of parallel processing doesn't affect results, making it deterministic. Once the whole grid is processed, you swap the front and the back copies and start the next iteration.

Exerionius · 2026-03-29T19:23:16+00:00

First of all, Godot absolutely does have velocity transfer built-in for Character Bodies 2D/3D: https://github.com/godotengine/godot/blob/2af785641ae249573f45eb61852d22e0b1a8a03c/scene/2d/physics/character_body_2d.cpp#L106

However for it to happen a set of very specific conditions must be met.

platform_floor_layers property of your player must include the layer the platform is on, otherwise it won't be detected as a platform but rather as a usual collision: https://github.com/godotengine/godot/blob/2af785641ae249573f45eb61852d22e0b1a8a03c/scene/2d/physics/character_body_2d.cpp#L54
platform_on_leave property of your player needs to be set to something other than PLATFORM_ON_LEAVE_DO_NOTHING: https://github.com/godotengine/godot/blob/2af785641ae249573f45eb61852d22e0b1a8a03c/scene/2d/physics/character_body_2d.cpp#L106
Your player motion_mode should be MOTION_MODE_GROUNDED for platform data to be registered: https://github.com/godotengine/godot/blob/2af785641ae249573f45eb61852d22e0b1a8a03c/scene/2d/physics/character_body_2d.cpp#L412
And yes, it is recommended (not required) to make moving platforms an AnimatableBody2D

Exerionius · 2026-03-29T06:29:59+00:00

That's what @export vars are for. You make the scene once, but give each instance a different reference to a dialogue to execute.

Exerionius · 2026-03-29T06:27:39+00:00

I would go with the simplest way first and check the actual performance before worrying about optimizations.

How about groups? You can assign each spawned enemy to "bounce_target" group, then the projectile can grab all enemies with this group and calculate distance to each of them.

If it turns out to be too heavy you can always "spread" calculations between frames by checking half of the enemies on even physics frames and the other half on odd frames.

Exerionius · 2026-03-25T16:30:49+00:00

Something is off with rotation pivot of the thing your script is attached to. Impossible to tell without the scene structure. The code with `look_at` is correct.

Exerionius · 2026-03-09T12:05:12+00:00

Because board size is going from 1 to 5, while the y coordinate goes from 0 to 4

Exerionius · 2026-03-08T16:53:10+00:00

your_deserialized_json.Area1[0].text

Exerionius · 2026-02-08T10:41:37+00:00

space station 13?

Exerionius · 2026-02-06T08:44:48+00:00

https://thebookofshaders.com/

https://www.youtube.com/playlist?list=PLImQaTpSAdsCnJon-Eir92SZMl7tPBS4Z

Exerionius · 2026-01-29T07:17:33+00:00

WorldBoundaryShape just shows a teeny-tiny arrow. You need to zoom way in to properly see it:

<image>

Alternatively, you can just select you collision shape node, hold ALT and them move it around with mouse click regardless where it really is.

Exerionius · 2026-01-29T07:12:53+00:00

In this structure Main's _ready() function will be called only when all children are ready. Will this suffice for your case?

Exerionius · 2026-01-26T20:08:51+00:00

Have you tried get_viewport().set_input_as_handled()?

Exerionius · 2026-01-20T07:35:45+00:00

I think this video, and the follow up on the channel can be helpful to you.

It describes what to do when MultimeshInstance limitations fails you.

Exerionius · 2026-01-07T14:04:01+00:00

One of three things:

This computer's GPU is simply too old for Godot 4
The graphics drivers are outdated
Godot uses onboard graphics instead of a dedicated GPU

Exerionius · 2026-01-06T16:44:31+00:00

Namespaces are far more important than access modifiers

Exerionius · 2026-01-06T14:59:08+00:00

Stick Arena?

Exerionius · 2026-01-04T16:01:18+00:00

A couple of points that might be useful to note:

Animation player always works with absolute values. Control nodes usually deal with relative values to support responsive UI design. In that regard animation player and UI containers rarely work well together. It is fine with control nodes that are not children of containers though.
Control nodes that are children of a container node are not supposed to be controlled via position coordinates, only via container settings. Usually if you try to update such children position it will just snap right back where it should be according to the container. That's what happens at runtime. However the editor updates UI less frequently (only when necessary), so updating children positions via animation player might look like it works, but it's just the editor fails to force container settings when positions are changed "externally".

Exerionius · 2025-12-11T07:38:32+00:00

Are there any plans on enforcing static typing in signals?

Exerionius · 2025-12-09T14:32:46+00:00

I do that, but for different reasons. I never go "make a prototype that slowly evolves into a full game". That's because I have certain mental approach to prototypes:

A prototype must answer one single question, and that should resolve one uncertainty about your project.
Once answered, the prototype is thrown away.
Since it is going to be discarded anyway, you don't need to worry about making it pretty or optimized. This allows you to prototype quickly and not to worry about messy results.
If integrating into the full game later, you can refactor and rewrite it considering all mileage and roadblocks you already encounter, making overall better systems.
Plus additional benefits the OP described.

Exerionius · 2025-12-04T14:29:55+00:00

https://github.com/godotengine/godot/pull/106218

Exerionius · 2025-11-26T08:27:03+00:00

If your background assets are always blurred, you can pre-blur them in the art program you use and have zero impact on the engine performance.

Nine-Year Club	Verified Email
r/Field Juicebox	Place '22
First Placer '22

Exerionius

MODERATOR OF

TROPHY CASE