Dyn4j integration

@jmaasing said: But you are saying that the Dyn4J Body class should be changed to inherit Animation. That is not integration, that is rewriting Dyn4J. It is like saying that java.util.Logger should inherit from the Animation class so you can integrate logging in your animations.

(The example with Logger is just incorrect, I ignore reacting to it)

Integration is integration.
By mean of what you achieve it - is another question.
If in order to integrate something with something you should tune source code of one of this “somethings” then okay, c’est la vie.

Doing hacks for usability now will compromise usability later :slight_smile: . I think that a PhisicAnimation class that wraps a body class is the way to go :slight_smile: . Is not better ?

@relucri said: Doing hacks for usability now will compromise usability later :) . I think that a PhisicAnimation class that wraps a body class is the way to go :) . Is not better ?

I did not talk about hacks in plural. I talked about one single hack “Body extends Animation”

Right, but why don’t you like the other implementation ? :slight_smile:

@relucri said: Right, but why don't you like the other implementation ? :)

With PhysicsAnimation things will go like this:

[java]/pseudocode/

class Animation{
Vector animationPosition;
}
class Body{
Vector bodyPosition;
}
class PhysicsAnimation extends Animation{
Body body;
void synchAfterAnimationIsUpdated(){
body.bodyPosition = animationPosition;
}
void synchAfterBodyIsUpdated(){
animationPosition = body.bodyPosition;
}
}[/java]

I prefer to avoid synchs by having one position variable in animation like this

[java]/pseudocode/

class Animation{
Vector bodyPosition;
}

class Body extends Animation{
// position is inherited from Animation
}[/java]

I feel that it makes code less buggy.

So you need that when body moves also animation should move and when animation moves also body should moves , right ? Sorry I don’t get used to work with Animation class but my opinion is that animation should position should be effected by the body ones and no viceversa . At least it’s how I implemeted it in my libgdx + box2d + spine2d tests . This way you just need something that call only synchAfterBodyIsUpdated() . It’s just how I’ll implement this things .

@relucri said: ... my opinion is that animation position should be affected by the body and not viceversa ...

What is your opinion is based on?

If I understand , Animation class contains information about how the parts of a Mesh move . So is not needed to have one to one dependency in position because some user cases could have one cube that is a rigid body ( so you can apply speed , gravity ecc ) and one mesh that doesn’t need to know that it is in a physical world . It should just follow the body and take care to play the right animation ( walk , jump ecc. ) . This is based on my previous 2d experience :slight_smile: but it could be wrong .

@relucri said: If I understand , Animation class contains information about how the parts of a Mesh move . So is not needed to have one to one dependency in position because some user cases could have one cube that is a rigid body ( so you can apply speed , gravity ecc ) and one mesh that doesn't need to know that it is in a physical world . It should just follow the body and take care to play the right animation ( walk , jump ecc. ) . This is based on my previous 2d experience :) but it could be wrong .

Well okay, this is just difference in terms. In my terms Animation is not pure Mesh, I mean your Animation class should have position field because you may want to just move sprites and check if they are colliding without any realism that physics can do for you.

But in general your game engine user will be angry if it will find out that with out any real reason you just don’t give him opportunity to move body with moving animation.

1 Like

After a couple of months being busy with personal things, I was able to start adding joint support. I would like to share some videos:

[video]http://www.youtube.com/watch?v=w3flmjMYgMI[/video]
[video]http://www.youtube.com/watch?v=f6sZ-ZSNTyA[/video]
[video]http://www.youtube.com/watch?v=d7HRitU1iJE[/video]

All this videos are about DistanceJoint. I will add more soon.

Regards

1 Like

FYI William just released 3.1.10 - it has some fixes for polygon decomposition so it will probably not have any impact on this integration.

@jmaasing:

Thanks. Using released 3.1.8 currently. I will move to last Dyn4j release when I get ready to release jME3-Dyn4j-plugin.

Added RevoluteJoint and MouseJoint support.

Test suite improved:

  • Run/Pause physic calculations
  • Enable/Disable fly cam mode
  • Drag dynamic objects.
  • Reset cam
  • Added new tests

New videos:
[video]http://www.youtube.com/watch?v=R-LJQxL6nlc[/video]
[video]http://www.youtube.com/watch?v=t8uK1xCRszA[/video]

Can someone explain how to install this plugin into JMonkey platform ?
I can’t find this plugin in the available plugins tab from jomkeyengine repo. I think this is normal (not released yet).
But I can’t find how to manually add this plugin into my platform. And the readme don’t provide any help.

Thanks

@RatKod said: Can someone explain how to install this plugin into JMonkey platform ? I can't find this plugin in the available plugins tab from jomkeyengine repo. I think this is normal (not released yet). But I can't find how to manually add this plugin into my platform. And the readme don't provide any help.

Thanks


It has not been released as a plugin yet. Sorry for that. I’m waiting for github-plugins-automated-submissions in order to avoid generating as a plugin.

I thing you can download the project from github and link it to your project in the meantime.