next »

[Maud'Dib Atreides]

Ok. I don't really like to ask too many questions here, but here's one that's pretty important.

In my game, you can choose your hairstyle in Character Creation.

One of the Options is Long Hair.

The thing is though, the game uses a large amount of action (Flipping, Parkour)

Which means I don't want to hair to act as a stiff rod. I could animate it, but I'd have to animate it for 360 degrees, because the character can rotate a full 360 degrees.

Basically, the question is this. This may be a very large question to ask

Programming Languages Aside: (Although this is in C# I can take an answer in Pseudo-Code)
But I am using OpenGL, but I'm using up to 1.2 for Older Systems

How would I create physics on a string-like object that allowed it to move about, like a string like object?

I was thinking of taking the CastleVania WhipBrandish approach, where I had multiple particles and animated them to operate with their own physics

http://castlevania.wikia.com/wiki/Brandish_Whip

This may be a complicated question, and I understand this.





I'd love to have the hair comprised of multiple strings, or one stiff string.

And if it's still unclear what I'm trying to create, I'm trying to create a limp noodle that is affected by forces such as velocity.

[BorisTheBrave]

You are in luck, this sort of thing is not uncommon in games, particularly 3d.

E.g, tf2 calls them Jiggle bones. The idea is you make a series of short bones, which bend under physics, and then you skin the mesh with them. Skinning is a long topic, but there are plenty of resources for.

As for the physical animation, it can be very crude and still look quite convincing. The easiest way is to consider each bone connection as part of a particle system. The particles move about, but there are spring forces that encourage them to stay in proper relation to the connected particles, and also to keep the base following the head. But it might be easier to hook up a proper physics engine, rather than tinker with it. Phsyics engines are particular important if you need "hard" constraints, rather than just forces that just roughly keep things together. For example, keeping the length exact (non-stretch), or ensuring the hair doesn't overlap the rest of the mesh.

I'd bet the rope animation you linked works by a near identical system.

[Maud'Dib Atreides]

You are in luck, this sort of thing is not uncommon in games, particularly 3d.

E.g, tf2 calls them Jiggle bones. The idea is you make a series of short bones, which bend under physics, and then you skin the mesh with them. Skinning is a long topic, but there are plenty of resources for.

As for the physical animation, it can be very crude and still look quite convincing. The easiest way is to consider each bone connection as part of a particle system. The particles move about, but there are spring forces that encourage them to stay in proper relation to the connected particles, and also to keep the base following the head. But it might be easier to hook up a proper physics engine, rather than tinker with it. Phsyics engines are particular important if you need "hard" constraints, rather than just forces that just roughly keep things together. For example, keeping the length exact (non-stretch), or ensuring the hair doesn't overlap the rest of the mesh.

I'd bet the rope animation you linked works by a near identical system.

You couldn't pseudo-code part of this for me, could you?

[sigfarter]

String theory is still just a theory, you are going to make your computer travel back in time.

[Dacke]

I imagine you can look up inverse kinematics to get some basic ideas. But then you'd probably use some forward kinematic animation, probably. Or something like that?

[stevesan]

Well, depending on the computing resources you have to work with, you can do a variety of things. Most obvious is to just simulate a spring-mass system with some number of particles (probably what that video does), and then update a textured mesh over it. Existing physics libraries often have this stuff in the form of constraints, so you can play around with those.

Spring-mass systems aren't terrible to implement on your own, but that depends on what level of programming expertise you have.

[Marries]

Why do you think a lot of protagonists have short hair (or are even bold)? It's very difficult to get long hair robustly working in every circumstance. If you want to develop this on your own, you'll spend a lot of time on it. Spend that time on more important parts of your game instead!

But there are alternatives to implementing such a complicated system by yourself. You could look for a physics engine which supports this (in a way BorisTheBrave said), but I'm not even sure this would work perfectly. Or you could try to solve it in a simpler way, for example with animations or by limiting the hair length to avoid hair-body interaction (such as a pony-tail).

[Nix]

LOOK WHAT I FOUND BY REMEMBERING

[Maud'Dib Atreides]

LOOK WHAT I FOUND BY REMEMBERING

Thanks. I also forgot to mention that this is 2D (lol?)

[Nix]

It doesn't matter in the slightest, dude. The math is almost identical. No "lol" you bum.

[CharsAce]

You could try verlet?

[Charybdis]

You could try verlet?

I second this: Verlet physics is what you need. Bones and inverse kimenatics are complete overkill for something like this.

Many people know euler physics, where you store position and velocity. The integration looks something like this:

particle->_velocity += (particle->_summed_forces/particle->_mass)*DELTATIME;
particle->_position += particle->_velocity*DELTATIME;

The problem with euler is that the velocity is explicit and blind over the whole timestep. It can easily get out of sync and overstep, and will probably explode if you have 'stiff' springs, unless you set the timestep incredibly small.

With verlet integration, velocity is implicit. That is, you store position and old position, and work out the velocity.

Vector2D current_velocity = particle->_position - particle->_old_position;
current_velocity += (particle->_summed_forces/particle->_mass)*DELTATIME;
particle->_old_position = particle->_position;
particle->_position += current_velocity*DELTATIME;

You just need to constrain the position and the implicit velocity will always be in sync. To modify the velocity you just need to mess with the old position, e.g. flipping the old position around a line or plane will make the particle bounce off it.

This is a lot more stable and you can have very stiff springs, in fact they can be infinitely stiff (that is, you can snap the points of a spring to be of exactly the rest length distance apart and it won't explode).

It's just a very basic explanation but it should give you some idea of how to implement it. I'm sure you can take it from here.

[Maud'Dib Atreides]

Thanks everyone. I'm almost done with it.

(I guess I should upload a video for your harsh judging on it's realism when I'm complete?)

It's amazing how typing CastleVania Whip Brandish took me right back here. 

[stevesan]

Thanks everyone. I'm almost done with it.

(I guess I should upload a video for your harsh judging on it's realism when I'm complete?)

It's amazing how typing CastleVania Whip Brandish took me right back here. 

Well, I for one won't judge on "realism"..whatever that means in this case Just as long as it looks good, runs well, and doesn't get in the way of gameplay!