Home Website Youtube GitHub

Mgear springnode gravity

mGear Development
#1

hi,

i added gravity to the spring node and want to ask some developers if my approach is right.
in the springnode.cpp i add a gravity float variable to the goalForce.y vector like in this code snippet.

...
float gravity = data.inputValue(aGravity, &status).asFloat();

// computation
MFloatVector velocity = (_currentPosition - _previousPosition) * (1.0 - damping);
//velocity.y += gravity;
MVector newPosition = _currentPosition + velocity;
MFloatVector goalForce = (goal - newPosition) * stiffness;
goalForce.y += gravity;
newPosition += goalForce;
...

would this be right?

it works (somehow), but when the gravity is too high, i loose a lot of dynamics and then it feels not so right anymore…

1 Like
Help compiling mGear dist
#2

Without digging in too deeply, it seems you are adding in gravity separately after the calculation and separate from the damping and stiffness. I would guess that the gravity should be included in the velocity calculation.

Otherwise it is overriding it, rather than properly contributing to the vector.

And to imagine why damping should also affect gravity, imagine long hair underwater.

1 Like
#3

that was also my first thought, as seen in the commented line, where i add the gravity to the velocity.y vector.
(but that gave me strange dynamic update results in maya, especially with DG.)

#4

Your commented out line does the same thing. It adds after, and ignores any damping in the line:

MFloatVector velocity = (_currentPosition - _previousPosition) * (1.0 - damping);

#5

This is untested pseudo code, and I know nothing about the syntax of what I guess is C++? but I’d make gravity a vector, and include it in the velocity.

vector gravity = (0, data.inputValue(aGravity, &status).asFloat(), 0);

// computation
MFloatVector velocity = (_currentPosition - _previousPosition + gravity) * (1.0 - damping);
MVector newPosition = _currentPosition + velocity;
MFloatVector goalForce = (goal - newPosition) * stiffness;
newPosition += goalForce;
1 Like
#6

thanks, i will try that approach…
i let you know if it works better…

#7

The thing I don’t know without testing, is how the goalForce works. The spring wants to travel back to it’s original position. So maybe I am totally wrong and including gravity before the goalForce might just not work.

But if that were the case, I would suspect you would still want to calculate dampened gravity first, and then override the goalForce with gravity again.

MFloatVector goalForce = (goal - newPosition) * (stiffness - gravity); or something… I’ll stop replying with guesses though! :slight_smile:

1 Like
#8

on wiki https://en.m.wikipedia.org/wiki/Verlet_integration there is some code implementing gravity force, but this uses an accelaration vector…which i assume is the same as the velocity vector in mgear springnode computation…
the forces are added after the accelaration computation.
i have to try…

#9

The mGear spring node is a very simple position-tracking solver. It takes into account only current and previous position. It can’t account for forces (second order acceleration) without a rewrite. This loses the simplicity of the spring node.

#10

hi aerys

we already implemented gravity to the spring-node in our custom mgear…
already shared it with miquel…
next step could be to have some collision detection…

1 Like
#11

@soulcage, nice ! Is it something that can share to the group?

#12

i can share it, but it is for mgear 2.5.24 and the solvers are only compiled for maya2018…
also the component scripts are modified to work with the custom spring node…so its not implemented for higher versions of mgear (v3.x.x has a different python modules implementation as prior versions…)

#13

I’m curious to see it, since maya 2020 is out I will probably compile a few nodes when the new devkit is released so I can play around with a gravity-enabled spring.

Collision detection sounds like a fun project haha

#14

its here…

scroll down for the links…

1 Like
#15

Fantastic thank you!

#16

I guess my original concern came down to the fact that adding gravity is the same as simply offsetting the goal position in the spring node to move it downward. But when I thought about it more I realized it’s the correct thing to do.

I added a simple collider effect to the node. You can set a sphere of arbitrary radius to repel the spring and also choose how forceful the collision is. Kinda fun effect!

2 Likes
Blocking volume for Chain Spring
#17

cool. have to try out…
for collision i thought to use closestPointOnMesh function/node…
there is a simple code for that here

forgot to mention, that if using gravity values more/less than 0, the spring intensity could be set above 1 to compensate the damping effect of the gravity…

1 Like
#18

In my opinion a full mesh collision effect like that kinda tarnishes the beauty of the spring node which is that it is instantaneous. I would keep it to some sort of closed form geometrical collider, like a sphere or capsule. https://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm

Perhaps it would be better to write a new node if you want something with more options? Full mesh collision gets to the point where you might be better off building a simple bullet sim into your rig instead since they can do all kinds of clever stuff to make it fast.

1 Like
#19

just testet.
aerys this is really great!!! works like a charm…
maybe also a plane (ground) collision would be nice…

springNodeCollision
springNodeCollision881Ă—629 360 KB

would it be possible to have more collision positions (array of collision positions)? maybe a lookup for a set (rig collision set) where spheres are inside that the node can pick up?

3 Likes
Keeping Transform axis on rig generation
#20

Same repository as before.

spring_new

3 Likes