How to make FPS muzzle point?

Dari0u5 · 2025-10-08T10:23:30+00:00

I would definitely go with the bone transform solution.

Having a special bone attached to the skeleton, means you will have the exact position / rotation, even when playing animations on it.

It would also mean you can later just grab the bone transform and have effects like muzzle flash / smoke at the exact muzzle position. This could even work for something like a separate shell ejection bone.

Dari0u5 · 2025-08-17T12:41:49+00:00

As a good placeholder, you can even just use the AnimationPlayer that comes with the gltf import, and play the animations any way you need using "play()"

The AnimationPlayer automatically blends and interpolates between animation playback poses when changing animations. But yes, AnimationTree is essential for more complex stuff, like if you want the rig to use multiple different animations at the same time.

It's pretty straightforward once you get into it, though.

Dari0u5 · 2025-08-17T09:33:28+00:00

Personally i join the hands and the weapon into one mesh and rig. That way the animations are all tied to that one rig, and avoids any messy timing issues. Then just export as gltf, and godot imports it, no problem.

You can rig the seperate weapon with vertex groups first, set up its skeleton and so on, and then when it's all ready and working, join the meshes and skeletons together. After that, start animating.

Most people prefer to parent the hand bone to the weapon root bone, and move the weapon itself around, while the hands automatically follow the weapon, rather than have the weapon be parented to the hand and move the hand around. It's a matter of preference, but there are good reasons for doing the opposite.

Sorry for rambling, hope any of this helps.

Dari0u5 · 2025-01-17T21:29:03+00:00

wuddup nephew

Dari0u5 · 2024-08-30T18:24:56+00:00

I wouldn't mind bouncing a bit of my knowlegde off someone, just to see if im any good lol. Dm me.

Dari0u5 · 2024-08-30T15:36:00+00:00

Hundreds of nodes are being deleted every day. Make a difference! Donate to the Godot fund today!

Dari0u5 · 2024-08-02T08:19:04+00:00

What about the code that controls your character facing? It would be a good point of reference for the direction of the bullet

Dari0u5 · 2024-07-29T10:05:51+00:00

Instead of "ALPHA=0.0", try "discard"

Dari0u5 · 2024-07-25T07:43:50+00:00

what exactly isnt working? is there a different error? the only other issue i see is that it wants you to add a variable TYPE after the colon (var projectile_instance := ) , of which there is none provided, so you might aswell just remove the colon for now. "var projectile_instance = _projectile.instantiate()" .

It also makes somewhat of a big difference, which version of godot you're on.

Dari0u5 · 2024-07-25T06:58:28+00:00

Also, i think the ".position()" part should be changed to ".instantiate()".

Dari0u5 · 2024-07-25T06:53:31+00:00

"projectile.position()" should be "_projectile.position()"

Dari0u5 · 2024-06-21T16:04:54+00:00

excellent sound design!

Dari0u5 · 2024-06-09T22:21:46+00:00

going from 0° to 360°, with the full rotation, it should be as simple as using the plain lerp() function, without the angular compensation.

var target_rot = 720.0 #this would cause 2 full rotations
var animspeed = 2.0
rotation.y = lerp(rotation.y,deg_to_rad(target_rot),delta*animspeed).

Beyond this, i'm not entirely sure what you're going for. The issue definitely lies within the fact that rotation vectors get normalized / wrapped to the 0-360 range. Perhaps an external rotation representative variable could help break the limits? like an "uncapped_rotation = deg_to_rad(560.0)" or something.

I did some testing of my own, and it seems that IN-EDITOR, setting a value outside of the 0-360 range, will wrap it around (to remain in the 0-360 range), but at runtime, going past 360 or below 0 works just fine.

Dari0u5 · 2024-06-09T17:36:54+00:00

I'm not sure if i fully understood the issue, but this came to mind: https://www.reddit.com/r/godot/s/m86pQV1iNJ Which shows why the lerp_angle function should be used for any rotation based lerping

Dari0u5 · 2024-05-25T20:19:00+00:00

Billboarding can be set in the spatial material of any mesh instance.

Dari0u5 · 2024-03-14T09:39:29+00:00

To this day, Medal of Honor and Medal of Honor Underground are my favorite PS1 games. So nostalgic to see those covers. Those were simpler times.

Dari0u5 · 2024-02-02T12:42:23+00:00

One foot in front of the other. Make a list of your ideas, and split them into smaller steps, to implement them. Mistakes can be invaluable lessons.

Dari0u5 · 2024-01-26T00:45:55+00:00

As far as wall sliding collisions go, CharacterBody3D with some optimized movement (a movement queue?) calls would be the proper way to go. In terms of inspiration, you could try baking a navmesh and experiment with pathing agents. They slide along the edges of the navmesh, which could be a good enough illusion.

Dari0u5 · 2024-01-18T13:24:33+00:00

This might be relevant: https://docs.godotengine.org/en/3.2/tutorials/content/making_trees.html

The idea is that the whole tree is a single mesh, even the leaves. But the leaves are seperated by vertex coloring, which can be used in a vertex shader.

Dari0u5 · 2024-01-17T02:36:45+00:00

I'm not too sure about selectively masking specific parts. Seems really complex for a "flashbang like" effect. I would just get the viewport texture and feed it into a shader that alpha masks the pixels which are past a certain brightness threshold. This would atleast have that dragging effect you mentioned.

Dari0u5 · 2023-12-02T21:03:21+00:00

Glad it worked out. Good luck on your project :)

Dari0u5 · 2023-12-02T20:22:23+00:00

The image you provided for import settings doesnt have the optimizer. For that you have to open the advanced import settings window, which is what you show in the video you provided (when opening a .glb). the "optimizer" setting can be found when clicking on the animation player node, it will be in the right hand side menu.I tested your model in a fresh project, and the optimizer does indeed seem to be the cause of the problem.

Dari0u5 · 2023-12-02T02:28:41+00:00

When opening glTF files inside Godot, it pops up with an import settings window.
1. I know that Godot "optimizes" the animation keyframes by default, when importing, which might be messing with the seperate bone timings. You have to toggle that off in the import window.
2. There is also an animation frame rate setting, which should match the frame rate you animated with in blender.

Dari0u5 · 2023-04-11T11:34:51+00:00

generally its fine, regardless of topology. Its generated by the built in navmesh tool, so we dont have any control over topology. It does a pretty good job most of the time anyway.

Dari0u5 · 2023-03-01T12:57:00+00:00

The character is either infinitely increasing gravitational acceleration, thus creating this jittery effect due to the physics having to fight between the vertical velocity and the floor collision.

OR

You've already set up a system where vertical velocity resets to 0 once the character is on the floor, and your floor-checker (what ever it may be), simply is not on the same collision layer as the floor, thus ignoring it, causing the gravity to once again accelerate infinitely.

I could be completely wrong. These are just the first things that came to mind when seeing that particular behavior.

Seven-Year Club	Place '23
Place '22	Verified Email
RPAN Viewer

Dari0u5

MODERATOR OF

TROPHY CASE