Character movement and animation using physics engine

[Panuchka]

Hi again, it's going to be long and maybe silly post once again. Today's topic is character animation and movement using physics (Cannon.js for now). Still doing the Bomberman clone.

I've been digging for a some kind of a tutorial for this, but have not found it so far. What I basically wish to know is how to:

1. Import a character with animations "the right way". I currently have a character, which has animations for idle/walking/running/jumping(start/looping/end). The problem is, the animations are all in different files and the format is FBX. So, what is the preferred way to import my character to BabylonJS? Should I just try to mash all the animations in a single file somehow? Currently, if I export the FBX to .babylon format, I get multiple files for each animation. When I import the animations to my scene, they are all playing by default. Sorry if this is a beginner question...
2. Move a character using physics properly. I guess the main idea is similar to what Unity does. I created a picture (Image 1) attached to my post to demonstrate what I mean. I currently have a SphereImpostor, which is moving using keyboard controls (using addImpulse). Now, I guess what I need to do is kind of have all the other stuff such as the visible mesh that has the animations and the box for wall collisions to somehow stick with the ball that is moving. And also to rotate the animation to the direction where the ball is leading the character Am I on the right track here?

Image 1: How I would like the 'character' to be like.

Some threads that I dug up on the similar matters:

Buuuut he decided to not use physics at all. Also found this demo, but it's from 2014... http://babylonplayground.azurewebsites.net/babyoncharacterwalk

[Wingnut]

Hi @Panuchka! 

Regarding #2 - what has convinced you that a physics engine is needed for a Bomberman game?  It is mostly over-head view, so, why use a physics engine?  Likely, the built-into-BJS collision system would work fine. 

IF you feel you MUST use physics (on your player and its collisions), then you are entering the world of "rag dolls".  (search the forum)

It is a violent world... not because of the demented things you can do to ragdolls, but because of the violence that will happen in your head... when you start dealing-with the Quaternions and matrix transformations.  We have seen humanoid rag-dolls in BJS, and they are fast and fun, but let it be known... they were coded by one of the best coders we have ever seen...  Sam Girardin.  

He made a powerful demo using Babylon.js, he gave us a great source code package.  We loved the demo and we fainted over the source code.    Let's take a look at the Oimo.js ragdoll thing.  And there's the Cannon.js ragdoll thing.  Both will need conversion to BJS mesh... but we have plugin interfaces to both of those physics engines.  How is your pain threshold?    Then, how to incorporate your animations?  Phew.  As you see on Sam Girardin's old-man ragdolls, he has some animations on-board... walking, running, but none of the animations react with anything.  Does he walk into a sphere or attempt to jump up onto a tight rope?  Nope... not during the animations.  One might ask one's self... IS the physics active during the old man's walk and run?  Nobody knows.  Probably not.

There is lots more to talk about... like Cannon's meshImposter that accurately represents any single mesh, but possibly not true for morphing mesh driven my weghtedVertices of skeleton armature animations.  Then there's Oimo's heightMap physics, which uses many many sphereImpostors... underlying the entire terrain.  It works well, too.  I have seen another friend-of-BJS @AndyBeaulieu do SOMETHING here... (which reminds me... I need to add his site...  to our offsite tutorials list).

I don't want to discourage you from using physics engines, Pan... but... are you sure you want to go that route?  Other things are just as cool, and they might perform faster and without all that delicious pain.    Are you sure-footed about your project requirements, or are they open for discussion?  Others may comment soon, and disagree with me, who knows?

I'll leave #1 question... for others.  Be well, P!  Talk again soon.

[Panuchka]

Thanks for the input @Wingnut, I appreciate it!

I'm a Master's student in Computer Science, doing my thesis basically on the viability of 3D webgl engines for game development (at the moment). The reason why I'm currently using physics is pretty much trying to figure out how easy it is to use them.  I'm also secretly comparing everything here to Unity, since I'm more familiar with it (and since Unity has webgl export thingy nowadays).

Oh man, I looked into the source of the old man too and... It really seems a bit complex. What I've gathered now is that physics based games with animations are a bit of a no-go for now? At least if you want to have animations or so. Of course some 'tilt the board and make the ball go through maze'-kind of physics puzzle games would be possible, but nothing that requires complex models, animations and movement, am I right?

[Wingnut]

2 hours ago, Panuchka said:

What I've gathered now is that physics based games with animations are a bit of a no-go for now? At least if you want to have animations or so. Of course some 'tilt the board and make the ball go through maze'-kind of physics puzzle games would be possible, but nothing that requires complex models, animations and movement, am I right?

Hi P.  Ya know, I can't say they are no-go.  They are "go", but... do you have a 3D mind?  Do you understand Quaternions, matrices, physics joints and constraints, how to avoid letting impostors undesirably overlap/collide, how to assemble compound impostors, how physics engines do their stuff?  (and about 20 other difficult/variable questions.)

Then, do you have a smoking-fast game/simulations computer?  Is that the only machine that you will run the P-sims upon?  Will you be only using rigidBodies, or will you need softBodies?  And maybe, the big question, are you talking to someone who has any experience with these things?    (Hopefully, smarter people than I... will comment)

Non-JS-based physics engines... run much faster, of course.  I have seen great physics... but not that often in Javascript.  Look at some PhysX demos, and you'll get a whole new perspective... and you'll drool.   But PhysX demos are always coded in a multi-threaded OS environment.  JS is single-threaded.  Might we see physics engines built-into computer hardware in the future, or already?  Will we be able to interface to those... from within JS?  How fast must the sim run, in the end... for us to label it as "a success"?

All in all, I don't think you can say "no go" quite that easily, and be completely accurate.  Maybe "slow-go", or "know'n'go" (things work great if designed exactly correct, via pre-planning knowledge).  There are just SO many factors involved.  Every time I use and/or examine a JS-based physics engine, I say to myself "wow, this is fantastic" and moments later... I say "...for what it claims to do/be". 

I wish I could give you a definitive answer, but I just can't.  Everyone has differing opinions of what "go" and "no go" mean, and on which platforms.  NASA uses physics sims, construction companies use physics sims, train sims, flight sims, racing sims, all have used physics engines successfully... and all with faster environments than JS.  JS can be successful too, if you keep your requirements within reason.  What is "within reason", eh?  You might put 5 years of study into "Are physics engines ready?" and after that 5 years, you might sound just like me.  "Ready for what?"

I'm not much help, am I?  Sorry.  If you can, be a patient and we might hear some other opinions/analyses.

[Panuchka]

1 hour ago, Wingnut said:

They are "go", but... do you have a 3D mind?  Do you understand Quaternions, matrices, physics joints and constraints, how to avoid letting impostors undesirably overlap/collide, how to assemble compound impostors, how physics engines do their stuff?  (and about 20 other difficult/variable questions.)

Quaternions, matrices, yes. Joints and contraints, not yet so much I would like to improve my knowledge in these areas though.

1 hour ago, Wingnut said:

Then, do you have a smoking-fast game/simulations computer?  Is that the only machine that you will run the P-sims upon?  Will you be only using rigidBodies, or will you need softBodies?  And maybe, the big question, are you talking to someone who has any experience with these things?    (Hopefully, smarter people than I... will comment)

Non-JS-based physics engines... run much faster, of course.  I have seen great physics... but not that often in Javascript.  Look at some PhysX demos, and you'll get a whole new perspective... and you'll drool.   But PhysX demos are always coded in a multi-threaded OS environment.  JS is single-threaded.  Might we see physics engines built-into computer hardware in the future, or already?  Will we be able to interface to those... from within JS?  How fast must the sim run, in the end... for us to label it as "a success"?

Well, philosophically thinking some of us are more into building Lego™ blocks themselves and not using the blocks to build something. I personally love to use the blocks someone else has already defined. So I guess I'm saying that for me, success is defined by "can I use this right now and is it viable". Most real life projects need some pre-existing technology to be ready so you don't have to invent the wheel again. It kind of baffles me that a 3D-framework for building games doesn't have a solid solution for a common 3D-game issue. 

Also I have to say that JavaScript is (in my opinion) a really nice environment to work with. I really love the ability to test the game on multiple platforms quickly and the fact that I can write JavaScript on the client side and the backend.  You've been helpful, don't worry! I think I'm going to give up on the physics though, since it seems too much of a hassle. Hopefully I can have some help on the animation problem too!