@H said: So, I don’t know what stuff will be needed. So, I will try release the code soon and then make changes according to users suggestions/ideas.
I really like this 
plus the future submit in JME plug ins list ! Keep the good work!!
@DmitryKolesnikovich said: May be you have some thoughts from your expirience about "float vs double"? Specially when you want your game run on mobile devices. Is it worth to care about such things?
I don’t have experience about mobile devices. jME3 uses float (to set location, rotation, etc.) and Dyn4j uses double (to set location, rotation, etc). I just convert from double to float. I.e: in order to get location from Dyn4j object and set the location on jME3 objects. What other thing should I do?
@H said: I don't have experience about mobile devices. jME3 uses float (to set location, rotation, etc.) and Dyn4j uses double (to set location, rotation, etc). I just convert from double to float. I.e: in order to get location from Dyn4j object and set the location on jME3 objects. What other thing should I do?
Please, make Body extends Animation, so that I will not synchronize Body and Animation position myself.
@H said: Exactly! I'm using Bullet integration as a guide, so you have the two options: you can run the Dyn4jAppState on a different threat (by default) with fix timestep (1/60 sec) or on the same threat using variable timeStep.
Oh, I just re-read what you wrote, that’s not what variable time step means, even if running on the render thread you want to use fixed time step. I will ask on Dyn4J forum to double check I get it right but time step has nothing to do with threading.
@DmitryKolesnikovich said: Please, make Body extends Animation, so that I will not synchronize Body and Animation position myself.Body is a class from Dyn4j engine. I use body into a RigidControler in order to get the physic's object location and rotarion, and update jME3's Geometry location and rotation.
@jmaasing said: Oh, I just re-read what you wrote, that's not what variable time step means, even if running on the render thread you want to use fixed time step. I will ask on Dyn4J forum to double check I get it right but time step has nothing to do with threading.
Are you sure? I will try to explain how I undertand this fixed vs variable time step stuff:
My understanding is that fixed timestep will run the physics calculation using a constant time step (usually 1/60 sec). Variable timestep will run the physics calculation using the tpf usually. Dyn4j’s recomendation is to use fixed timestep and this needs to be done in a diferent thread. If I undertood correctly, it makes no sense to run fixed timestep inside render thread. Let says your render thread takes 1/240 sec to render the geometries (tpf = 1/240 for this run). You will run physics calcultion using 1/240 sec when runing inside render thread. Next render cicle will take 1/245 (or 1/230 or 1/250) so tpf will be 1/245 (or 1/230 or 1/250). So you will run physics calculation using 1/245 (or 1/230 or 1/250). If you run physics calculation in a different thread, then you will run physics calculation every 1/60 sec no matter how long the render thread takes to render the goemetries. Dyn4jAppState schedules a runnable instance that is called every 1/60 sec and runs physics calculation using 1/60 secas timestep. Dyn4j has a logic for fixed timestep that goes like this. If you call the method to run fixed timesteps pasing a param equals o bigger the 1/60, calculations a done. If not, dyn4j will acumulate (it will not run calculations) the time for next calls to same method till the timestepSum is equal o bigger then 1/60.
Do you understand the same? Am I wrong (I can missunderstand this - my english is not so good as you can see ;-P)?
@H said: Are you sure? I will try to explain how I undertand this fixed vs variable time step stuff: My understanding is that fixed timestep will run the physics calculation using a constant time step (usually 1/60 sec). Variable timestep will run the physics calculation using the tpf usually. Dyn4j's recomendation is to use fixed timestep and this needs to be done in a diferent thread. If I undertood correctly, it makes no sense to run fixed timestep inside render thread. Let says your render thread takes 1/240 sec to render the geometries (tpf = 1/240 for this run). You will run physics calcultion using 1/240 sec when runing inside render thread. Next render cicle will take 1/245 (or 1/230 or 1/250) so tpf will be 1/245 (or 1/230 or 1/250). So you will run physics calculation using 1/245 (or 1/230 or 1/250). If you run physics calculation in a different thread, then you will run physics calculation every 1/60 sec no matter how long the render thread takes to render the goemetries. Dyn4jAppState schedules a runnable instance that is called every 1/60 sec and runs physics calculation using 1/60 secas timestep. Dyn4j has a logic for fixed timestep that goes like this. If you call the method to run fixed timesteps pasing a param equals o bigger the 1/60, calculations a done. If not, dyn4j will acumulate (it will not run calculations) the time for next calls to same method till the timestepSum is equal o bigger then 1/60.Do you understand the same? Am I wrong (I can missunderstand this - my english is not so good as you can see ;-P)?
Yes, we understand the same 
William explained it pretty good http://forum.dyn4j.org/viewtopic.php?f=1&t=94
For fixed time step, if the tpf is smaller than 1/60 Dyn4J just adds it to a counter, when the accumulated time is > 1/60 it runs one execution of the pipeline. So if you call update(elapsedTime) more often than 1/60 everything runs smooth at 1/60.
If tpf is larger than 1/60 - Dyn4J will still only run one execution - which means it will “loose time” - or actually loose precision in the simulation.
As long as you pass in elapsed time (tpf) and it is 1/60 or less it makes no difference if it is a separate thread or the render thread - you can still use fixed time step and physics will run at 1/60.
Variable time step means that Dyn4J runs one execution when you call update, if this was the render thread then every frame would step the physics engine even if tpf was smaller than 1/60. But is this something you would want? Put another way: why should I run physics at 1/240 just because I can?
@H said: Body is a class from Dyn4j engine. I use body into a RigidControler in order to get the physic's object location and rotarion, and update jME3's Geometry location and rotation.
This means in my code as a developer I need to do the same.
I mean I can not just create new instance of body and go with it.
For every Body I should create new instance of Animation and synchronize their location and rotation manually.
It’s pretty painful. It’s desirable to let your plugin do all synchronizations for me.
The ideal variant is to make Body class (from Dyn4j) as a child of Animation class (from jME3)
I mean to tune Dyn4j source code itself by making “Body extends Animation”
I don’t think that extends body is a good idea , most of all they are two differt things and It’s quite bad to extends a class if it not satisfy the "is A " principle . Maybe he could just build an helper class to sync Animation and Body . This is a general advice I don’t know how he implemented it .
Just my 2 cents 
@relucri said: I don't think that extends body is a good idea , most of all they are two differt things and It's quite bad to extends a class if it not satisfy the "is A " principle . Maybe he could just build an helper class to sync Animation and Body . This is a general advice I don't know how he implemented it .Just my 2 cents
Sometimes “is a” rule is avoided. For example button is not text, it contains text. But in android API Button | Android Developers Button extends android.widget.TextView, because it’s just easier to make things this way.
For example, if for android.widget.CheckBox object (that extends Button) you do not want to set any text it’s not like you do not include text inside CheckBox as a child, but just like set text to null (CheckBox inherits text from TextView). So CheckBox extends TextView instead of having ability to have TextView as a child.
@DmitryKolesnikovich said: Sometimes "is a" rule is avoided. For example button is not text, it contains text. But in android API http://developer.android.com/reference/android/widget/Button.html Button extends android.widget.TextView, because it's just easier to make things this way.For example, if for android.widget.CheckBox object (that extends Button) you do not want to set any text it’s not like you do not include text inside CheckBox as a child, but just like set text to null (CheckBox inherits text from TextView). So CheckBox extends TextView instead of having ability to have TextView as a child.
But in GUI terms, this makes total sense. A button is a label that you can click on. A checkbox is a button that can be toggled. This is why every UI does it this way. Even in Swing you can make a Label look just like a Button but be unclickable… likewise for Buttons to look like Checkboxes, etc. Visually they are no different it is only the behavior that is added. The “is a” relationship is very clear. Besides a label “has” text… and a TextView “has” text. These are not text on their own.
And I agree with relucri that the proposed animation extension is kind of hacky and muddies the class hierarchy… especially when there are way better ways to do it.
@pspeed said: And I agree with relucri that the proposed animation extension is kind of hacky and muddies the class hierarchy... especially when there are way better ways to do it.I agree too. Changing Dyn4j code is not a good idea. It will become hard to maintain. We need to solve this using Controllers or some thing else
@H said: I agree too. Changing Dyn4j code is not a good idea. It will become hard to maintain. We need to solve this using Controllers or some thing else
A Control is how JME’s bullet integration does it, right? I could be misunderstanding the issue because I’m not sure how this relates to Animation at all.
…I think you can probably take a good lead from the bullet integration, though.
@pspeed said: But in GUI terms, this makes total sense. A button is a label that you can click on. A checkbox is a button that can be toggled. This is why every UI does it this way. Even in Swing you can make a Label look just like a Button but be unclickable... likewise for Buttons to look like Checkboxes, etc. Visually they are no different it is only the behavior that is added. The "is a" relationship is very clear. Besides a label "has" text... and a TextView "has" text. These are not text on their own.And I agree with relucri that the proposed animation extension is kind of hacky and muddies the class hierarchy… especially when there are way better ways to do it.
I do not want to prove anything. I just notice that in android API the ability to click on UI controll is defined not in Button class but in View class - the root of all android widgets View | Android Developers.
So it’s not Button who adds to Label ability to click - label (TextView | Android Developers) already has this ability. Still we have Button class for some reason.
For me it’s pretty “hacky”, but it’s simple.
@DmitryKolesnikovich said: I do not want to prove anything. I just notice that in android API the ability to click on UI controll is defined not in Button class but in View class - the root of all android widgets http://developer.android.com/reference/android/view/View.html#setOnClickListener(android.view.View.OnClickListener).So it’s not Button who adds to Label ability to click - label (TextView | Android Developers) already has this ability. Still we have Button class for some reason.
For me it’s pretty “hacky”, but it’s simple.
Generally, one has a button class because then one has button state… pressed, released, focused, etc. A button “is a” label that adds button state. A checkbox “is a button” that adds sticky state. Put another way, a button is a special kind of label and a checkbox is a special kind of button.
@pspeed said: Generally, one has a button class because then one has button state.... pressed, released, focused, etc. A button "is a" label that adds button state. A checkbox "is a button" that adds sticky state. Put another way, a button is a special kind of label and a checkbox is a special kind of button.
Button class does not add to label such states as pressed, released, focused. All those states label already inherits from it’s parent.
I agree that “button is a special kind of label”. But not because this is theoretically right way. This way is pretty “hacky”. We use this “wrong” way only because we want to keep things simple.
I fail to see what this has to do with Dyn4J integration. A physics body neither “is an” animation or “has” an animation or is concerned with anything visually at all. It is a physics body owned by the physics subsystem that you can use to read data from the physics system or influence the physics system. If the user of the physics system want to use data from the physics system to do something with the physics data then read the data from the physics system and do it, what you do with data from the physics system is up to your use case.
@jmaasing said: I fail to see what this has to do with Dyn4J integration. A physics body neither "is an" animation or "has" an animation or is concerned with anything visually at all. It is a physics body owned by the physics subsystem that you can use to read data from the physics system or influence the physics system. If the user of the physics system want to use data from the physics system to do something with the physics data then read the data from the physics system and do it, what you do with data from the physics system is up to your use case.
Yes, but in 90% of all use cases I will wish from Body to be Animation inheritor.
Is not it reasonable to want from game engine to cover those 90% of all use cases in simple manner (by extending Body from Animation)?
Furthermore the rest 10% of all use cases will not suffer at all just because of this “Body extends Animation” hack.
Of course in my private work I can do whatever I want, but I just wish to improve JME usability by sharing my ideas with community.
@jmaasing said: ... A physics body ... is not concerned with anything visually at all.
Obviously this logic is harmful for integration intentions. Because by integration we mean connecting unrelated things together.
@DmitryKolesnikovich said: Obviously this logic is harmful for integration intentions. Because integration means keeping into account different things in one place.
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.
1 Like