Solium - personal research and development

xyz

kuligs2 As for the update thing... well idk, why would i want to update the transform each frame even when its not moving?

Eh, dude. Think! If the input vector is zero it doesn't mean the thing is not moving. You have smoothing/inertia/interpolation which does the moving. Technically, you can stop interpolating when the interpolation target is reached but then you constantly need to check whether the target is reached. You'll execute some code each frame either way so you may as well just interpolate always.

Try increasing your smoothing times and you'll see that if you interpolate only when there's input, your interpolation will inevitably stop halfway if you release the input quickly in the middle of interpolation.

You yourself earlier complained that is feels "sticky" or whatever when your code interpolated only if there is input. You want to interpolate whenever there's something left to interpolate, or to simplify the code - just do it at all times. The computational cost is negligible. You already do that with the velocity vector anyway.

xyz

kuligs2 but i would think that weapons would be part of the character node and its important where they are aiming in order to land a hit on target (melee)

Weapons have visual and non visual representations as well. Visual representation will follow player's visual representation and functional representation will do whatever it needs to do to sell the illusion of shooting, depending on game type and mechanics.

xyz

kuligs2 Here's the complete example. It lets you toggle all interpolation via a flag. You should first implement the logic in your system like that - without interpolation. When you get that working properly, add interpolation on top of it.
The orientation basis that's manipulated can be either body itself or just the visual representation. It doesn't really matter.

extends CharacterBody3D

@export var speed_max: float = 2.0
@export var move_inertia: float = 0.2
var speed_wanted: float = 0.0
var speed: float = 0.0
var move_dir: Vector3 = Vector3.ZERO

@export var orient_inertia: float = 0.3
@onready var basis_wanted: Basis = global_basis

@export var inertia_enabled: bool = true


func _physics_process(dt):
	var input = Vector2(Input.get_vector("left", "right", "up", "down"))
	if input.is_zero_approx():
		speed_wanted = 0.0
	else:
		move_dir = (%cam.global_basis * Vector3(input.x, 0.0, input.y)).slide(Vector3.UP).normalized()
		speed_wanted = speed_max
		basis_wanted = Basis(Vector3.UP.cross(-move_dir), Vector3.UP, -move_dir).orthonormalized()
		
	if inertia_enabled:
		global_basis = global_basis.slerp(basis_wanted, dt / orient_inertia).orthonormalized()
		speed = move_toward(speed, speed_wanted, dt / move_inertia)
	else:
		global_basis = basis_wanted
		speed = speed_wanted
		
	velocity = move_dir * speed

	move_and_slide()

That's all there is to it.

kuligs2

Tinkering more, ive noticed that there is a problem. Most notably when walking into a wall, the camera starts to spazz out, even tho its not colliding with anything.

Idk, why.. the camera setup is pretty much the same as per godot docs. Camera is inside the springarm3d and the springarm3d is inside another node you control to rotate it ..

Maybe its related to when character hits a wall, the speed is not zero, and that little oscilation is making the springarm to flop around too fast and so it spazzes out?

Also, ive been thinking, how to make sure when you hit a wall with character that you dont move the character in the direction of the wall or any other obstacle, not relying on the engine with just collision event that stops you from moving?

Or maybe there is another way to handle this?

Ofc i would want to be able to step over the ledges or ramps or something like that but if there is something that is above some pre determined height, i would like to stop, and not move/change state to walk, even tho the input is pressed.

My thought was to use is_on_wall() to check that, but not sure if that would solve the problem i face with the camera.

kuligs2

Interestingly when removing collision shape from SpringArm3D you dont get this effect. So i guess i fixed the camera..

In the past, since like godot 4.0, the camera would be clipping through the walls if the spring arm didnt have collision shape, now its other way around... smh..

Before i had this:

Characther still bobbs when you force input/direction against wall. But its not as violent as was before

kuligs2

Ive been thinking how what or how to make better player character collision shape? Does anyone have any ideas?

Been trying to find out online but cant seem to find anything other than people using capsule.

What is my gripe with capsule is that when you stand over the ledge, you can get to a position where you are clearly over the edge but the player is in air and it register as on_floor.

Ive been thinking attaching collision shapes to feet bones, but it seems that doesnt work because the CharacterBody3D needs collision shape and the bone attachement are not direct child of that node.

Maybe im thinking in a wrong way and im missing something simple?

xyz

kuligs2 Put invisible walls on edges.

kuligs2

xyz too much work and complicates things..

xyz

kuligs2 I thought you liked too much work and complicating things.

If you can put regular walls into a level, why would it be too much work to add invisible ones? And I don't see anything complicated about it. It's super straightforward.

You can also raycast. I've answered a similar question recently over at official forums:
https://forum.godotengine.org/t/best-way-to-prevent-player-from-walking-off-ledge/126728/35

If a single central raycast still pushes the visual representation too far over the ledge, use a circular array of raycasts in the same way.

kuligs2

xyz maybe it didnt translate well but what i meant is that you create level/world and then you need to go over every ledge or something that player could jump off, meaning you do the level twice.. and if you make changes to level then its another potential place for bugs to start multiplying..

Raycasting, need to see if this is what i want so that it feels good when playing..

xyz

kuligs2 You can automate creation of such colliders. It'd be worth the effort if you want player so slide along the ledges. If they just fall down or stop, then raycasting will be more than enough.

Raycasts will feel good if you implement them to feel good.

kuligs2

xyz Colliders are easy to create with physical bones thing or something but, getting the character3d node to recognize all of them is another thing.

Because all of them colliders are part of bones, and this make them move with character animations but the character3d node expect the collider (single?) to be child of the node.

Havent explored this in more detail, gotta redo them darn animations with simpler rig.

EDIT:
Here its shown how its done, but its for hitboxes, but in generat you get all the collisions attached to the bones, now the question is how to make it work with char3d node.

Hmm.. maybe instead of char3d node, use a plain node3d or something?

xyz

kuligs2 Colliders are easy to create with physical bones thing or something but, getting the character3d node to recognize all of them is another thing.

Don't do that. Just make things work with a single capsule. Keep it simple.

kuligs2

Ok so the New rig with minimal bones looks like this

Articulating fingers will be a pain tho.. the weights are a mess..

kuligs2

kuligs2 Well the more i pose the guy, the more i realize im missing bones/parenting to the wrong bones etc.. and now its starts to look like the default blender human armature 😃..

Maybe i should use that instead? .... sheesh..

Tomcat

kuligs2 Ok so the New rig with minimal bones looks like this
…
Articulating fingers will be a pain tho.. the weights are a mess..

In the minimum rig, finger bones are not needed.

rig with minimal bones

Especially for you, I have censored the private parts, even though I am fundamentally opposed to censorship.

MikeCL

A tip if you want to save time, use the Blender Meta Rig and combine it with Rigify and Game Rig Tools

Rigify = creates all the animation controls for you with a robust IK system (and you can pick if you want to controls based on IK or FK). You might need to manually activate the addon if it's not already (comes with blender so you only need to activate it)

Game Rig Tools = Converts that controller rig back to a skeleton that's game friendly and you can bake down the action animations to NLA tracks.

Very powerful combo. and it's free. Saves a ton of time. Use that and just delete the face bones if you don't need them.

MikeCL

kuligs2 You are not supposed to export the control rig to the game engine. Those are only for animating in blender, you then bake the animation down to a "deformation" rig that is "game engine friendly" without the controllers. (or maybe I'm misreading what you mean here?)

MikeCL Game Rig Tools

Is great for this ☝️

Also when you have the animations baked down to NLA tracks, also set the following setting:
Animations Mode = NLA

kuligs2

Tomcat well since my model have fingers, bones are needed, otherwise how are you gonna make them hold a weapon, or fist when running? Only T-1000 runs without fisting fists.

Tomcat

kuligs2 well since my model have fingers, bones are needed, otherwise how are you gonna make them hold a weapon, or fist when running?

In the minimal rig, one finger is more than enough (with plenty to spare) to understand the situation and work through the process. When transitioning to a full-fledged model in your main work, you can add the missing ones. But I already understand that you like to waste time on unnecessary things.

xyz

kuligs2 Go with "one finger" and a thumb as @Tomcat suggested. It's enough to depict grabs/fists in this type of third person view.

MikeCL

kuligs2 You could use 3 finger bones..

thumb,
index finder
the rest.

This way you get a reduced amount of bones, and you still have the index finger if you need the character to be able to point etc. But this also depends on the requirements you have for the character.

If the only thing the character will be doing with the hands are, having fingers open as default, and then be able to make a fist. Then I would recommend what @Tomcat showed. The tweak I would do is to align the finger bones to the index finger, so the bones are more aligned in a straighter line. They would deform better when making a fist, also align the geometry so the fingers aren't as spread out, or you would have a hard time closing the fingers to a fist with only one finger rigged.

kuligs2

Tomcat im not wasting time, im learning. Failure is how you learn. If we never failed we would not learn a thing.

I dont know how to rig 1 bone to all fingers so that they can close to a fist, but ill see what i can do..

Ive been thinking of reusing the human armature from blender but not generate meta rig. That meta rig introduced like 100 more bones that are hard to filter. The deform armature was what i would say "minimal" rig.

I will remind yall, that this is not a game im working on, just a research type project to see how to set up things for something with more substance.

« Previous Page Next Page »