can you teach me the forces part?

I'm at work just now, but maybe in a few hours' time?

I've created this room because I feel kinda shy and dumb to be asking some questions in the other one

I'm very far behind the others

but I think I have some concrete questions now

The other room's pretty quiet right now, so I don't think you need to worry too much about that.

I asked so many questions regarding the same subject that I'm too shy to re-ask, but ok

@Henri Alright, just patching and testing today's changes now, so I should be free to chat a bit. How may I help?

oh hi

I've made a vector (2d) lib that works just like unity's

Neat!

are you ready?

Might depend - what am I getting ready for? ;)

I might ask again some questions Ive already had asked

but theres always a reason

lets start

Fire away

since I'm using ECS, what should I change (in InputSystem) when an input is received: velocity, acceleration or it doesnt really matter (since theyre all going to be changed on the MotionSystem)?

I'd say your input system should focus on applying accelerations or forces. Then your movement or physics system can handle the integration of forces/accelerations into velocity and into displacement.

great. this is what I was thinking

This makes it a bit easier to mix physics effects from multiple different sources/systems, and have them all interop consistently.

is this just because it makes it easier or...?

Sort of like having a standard interface - you know everything's working consistently without having to hold the code from all the other systems in your mind at once.

If they're all just applying accelerations, it's predictable, and you probably don't have to worry too much about update order and such.

Depending on your complexity, you might also want to separate your Input system (reading player commands out of input devices) from your Character Control system (turning commands into movement of an avatar)

ok, so far Ive got this: accel += vector::right * speed (max) * dt on my InputSystem

vector::right means Vector2.Right unity-wise

and all the vectors to be mentioned here are going to be 2d

Hm, that looks odd to me. A speed multiplied by a time makes a displacement, not an acceleration.

wops

actually, wait

lets rollback a little bit

Like saying "I drove at 60 mph for half an hour" is a way of saying "I drove 30 miles" - you're describing a distance.

when we talk about forces (newtons), are we talking about the vector's magnitude?

the same for: velocity.magnitude = 10, does it mean were driving at 10 space/time?

Forces can be vectors or scalars. With speed/velocity, we have different names for the scalar measure (speed) and the vector (velocity). But for forces we usually use the word "force" for both.

Yep, speed is the magnitude of a velocity vector.

so if I want my entity to move at max 30 space/time, it's velocity vector must always been clamped to 30?

So a velocity vector with magnitude 10 means it represents a speed of 10 spatial units per unit time, in some direction.

Yep.

oh man I'm so happy to hear this lol

you have no idea

Oh yeah?

yea!

moving on...

the reason I'm multiplying by maxSpeed is because my vector::right/left/up/down are in the range of [-1, 1]

No, because speed * time is still a distance, not an acceleration.

So the expression on the right is in some units like "metres per kilogram" which is... weird.

Do you know the trick of dimensional analysis? You can use it as a check when you have a physics formula you're not sure about.

should it only be input / mass then?

no

you mean the hand thing?

fingers*

We can see the h in the denominator cancels out with the h we're multiplying by, leaving us with just m - and that's how we can confirm that expression computes a length.

hmmm

I understand that when accelerating, we have to add an acceleration vector to the direction were moving

Here movementForce is a scalar in Newtons, representing the "thrust" that our character's engine/legs can apply.

how big can movementForce be not to mess up all the following calculations on the MotionSystem?

is this something i should worry about? like, this could be a very big value that would overpass our max speed

Depends on your situation. A sparrow will need a lot less force to move around than a Saturn-V rocket, and we can simulate both of those in games.

That's why I like working with speed first, then calculate the acceleration needed to reach it in a second step.

It makes enforcing a set maximum speed much easier.

we can call these forces here impulse?

because we could do the following

accel += inputVector * impulse / mas

on where Motion componentes would have: velocity, acceleration and impulse

Impulse is a different thing. Impulse / mass = deltaV

thurst or whatever :P

the names are quite unclear to me as I'm brazilian and couldnt figure what theyre named in portuguese

(ive been studying this since yesterday and had only 5 hours of sleep so far)

Are you re-zeroing your acceleration at the start of each simulation step?

It's generally not something you want to accumulate frame over frame, the way we do with velocity

You'll notice in the version I showed you yesterday, all my acceleration values were either input parameters or temporaries. Only velocity and position were persistent between simulation frames.

@DMGregory no

but I was thinking something like projectile-wise

some factor that would also be used for projectiles (later on)

Even for projectiles, we'll usually persist a velocity and position, but use a constant or re-calculated acceleration each frame.

we could name it initialAcceleration or whatsoever

is it better?

Then I'm not quite sure where this accel +=... is happening.

the problem here is that we have to scale the input force based on the entity were moving

what confuses me is that we could use the f=ma to find out a corresponding needed force to move the object

but then again we dont know a

we need to calculate this controlForceMagnitude somehow

Here, this is an input parameter. Something the designer tunes to decide the feel the character should have.

If you like though, we can change the input parameters to something like "maxSpeed" and "timeToMaxSpeed" and then solve an equation to find a force that achieves that speed in that time.

@DMGregory the problem is that if this is a static value, we would have problems when switching control over a sparrow and a tank, for example

no?

Usually the sparrow and tank would each have their own hand-tuned parameters.

If they even used the same movement script at all!

which means each would have a controlForceMagnitude value, right?

Yep. It would be a member variable of the character control component.

thats what I meant with "maxSpeed" above

We can absolutely make it work with maxSpeed as an input parameter, like in the example I showed last night.

We still need a second parameter though, to control how quickly we reach that max speed.

Without that, the system is under-determined.

@DMGregory I think this might be the way to better achieve this force value, no?

because:

Which way is "this"?

hover the mouse above it and it highlights your message

if this is what youre asking

so, I'll have a JSON defining some entity models: dragon will have the A, B and C components and corresponding values

Alright. We'll need one more ingredient to solve that equation then: what acts against the player's input to slow the character back down?

and "controlForceMagnitude" is just something very intuitive

id rather define my [moving] entities with maxSpeed and timeToMaxSpeed, I guess. Idk

@DMGregory the player input? if I understand, nothing

but if youre talking about all the possible forces to slow down the player, it should be wind and friction only

So you're drifting through frictionless space - if you push in one direction and then let go, you keep floating in that direction forever?

but if youre talking about all the possible forces to slow down the player, it should be wind and friction only

idk if you read it

or if youre just busy

I did. So next we need to know the friction model you're using and the typical baseline friction values to expect. (This is why I said I prefer not to go the force route - it makes achieving a particular max speed much more complicated than the alternative I showed you)

haahhaah