Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JOODE : practical use for games  (Read 5170 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Posted 2005-11-24 12:43:16 »

I thought about how much generic JOODE can be without being useless.
I explain myself : sometimes you have gameplays ideas that needs physics that aren't as the real world, and you have to use tricks to realize that.
E.g. : take a 2d mario-like platform game. You want your personnage to remain upright. You can reset its rotation each step, but it :
- isn't clean
- cause bugs
So the best solution is to write your little physic engine yourself.
It's not the only case where a physic engine isn't adapted.
So JOODE may be better suited for industrial simulations than games. ( :\ )
Another thought : we should split more our discussions : one topic for each programmation aspect.
I don't have the time to look at the sourcecode right now (I should release a beta version of my game soon, and I have a lot of work todo) but I'll take a look later. I'm still interested and engaged.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline c_lilian

Senior Devvie


Projects: 1


Java games will probably rock someday...


« Reply #1 - Posted 2005-11-24 13:26:20 »

I'm planning in the coming months to write a racing game as a jogl applet. having joode available would help me integrating good physics modeling (although I'm not sure i'll use it : i might go the "fun" way and don't simulate car collisions with a physics engine). joode would help me to avoid signing that small game.

I'm also thinking about a jogl applet showcase, where everybody could plug a small opengl demo into a larger applet. joode in that context could boost some of the demos included.

My 2c'

Lilian

Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #2 - Posted 2005-11-24 17:19:40 »

So JOODE is just good enough for demos ?  Undecided
Maybe we could add non-realworldphysics behaviors with special classes (I've no idea how.. but that would be cool.)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Devvie




money is the worst drug- we should not let it rule


« Reply #3 - Posted 2005-11-24 17:56:25 »

mmh a possibility to simplify some calculations (e.g. by simply ignoring some test cases or not applying forces automatically...) would be way cool. Cheesy

So we'll have to think of a way to controll such things. Actually I think this might be very similar to the Xith-problem of acessing OpenGL/LWJGL directly during the program flow.

Let's see, if we can find a good way of doing this.

:: JOODE :: Xith3d :: OdeJava ::
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #4 - Posted 2005-11-24 19:05:04 »

I thought about how much generic JOODE can be without being useless.
I explain myself : sometimes you have gameplays ideas that needs physics that aren't as the real world, and you have to use tricks to realize that.
E.g. : take a 2d mario-like platform game. You want your personnage to remain upright. You can reset its rotation each step, but it :
- isn't clean
- cause bugs
So the best solution is to write your little physic engine yourself.

While a true physics engine like ODE is probably overkill for a mario-like game (it really depends on what you are trying to do in the game, it could be fun to have "real" physics), there may be simpler solutions:
- you don' have to render using the rotation angle, then the sprite is always upright, though this would cause problems with the rotation causing problems within the simulation when interacting with other objects.
- I know very little about ODE at the moment, but can you not set hard constraints?  I.e. can there be an infinitely strong force holding the sprite's rotation in place?
- Is there a way to hook into the objects to balance forces with artificial ones?  So you could write a simple filter that would make sure the rotational forces always sum to zero for an object.  I could see this as an extension of connecting player controls, such as thrusters for a space ship.

Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #5 - Posted 2005-11-24 23:42:14 »

It should be fairly straight forward to invent new joint types that provide contrainst that fix things like an ordinate or rotation in a global sense. Thus you could be able to do 2D platform stuff fairly easy. It would be harder to force the collision systems default primitives into a 2D envorment without wasting resources, however writing your own collision system and plugging it in would be fairly straight forward.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #6 - Posted 2005-11-25 11:16:10 »

mmh a possibility to simplify some calculations (e.g. by simply ignoring some test cases or not applying forces automatically...) would be way cool. Cheesy

So we'll have to think of a way to controll such things. Actually I think this might be very similar to the Xith-problem of acessing OpenGL/LWJGL directly during the program flow.

Let's see, if we can find a good way of doing this.

I think so. I hope we'll find a solution.

I thought about how much generic JOODE can be without being useless.
I explain myself : sometimes you have gameplays ideas that needs physics that aren't as the real world, and you have to use tricks to realize that.
E.g. : take a 2d mario-like platform game. You want your personnage to remain upright. You can reset its rotation each step, but it :
- isn't clean
- cause bugs
So the best solution is to write your little physic engine yourself.

While a true physics engine like ODE is probably overkill for a mario-like game (it really depends on what you are trying to do in the game, it could be fun to have "real" physics), there may be simpler solutions:
- you don' have to render using the rotation angle, then the sprite is always upright, though this would cause problems with the rotation causing problems within the simulation when interacting with other objects.
- I know very little about ODE at the moment, but can you not set hard constraints? I.e. can there be an infinitely strong force holding the sprite's rotation in place?
- Is there a way to hook into the objects to balance forces with artificial ones? So you could write a simple filter that would make sure the rotational forces always sum to zero for an object. I could see this as an extension of connecting player controls, such as thrusters for a space ship.

ODE is not built on a spring system, so you can't do what you suggested. But you can reset the rotation each step, but it causes bumps when the object moves.

It should be fairly straight forward to invent new joint types that provide contrainst that fix things like an ordinate or rotation in a global sense. Thus you could be able to do 2D platform stuff fairly easy. It would be harder to force the collision systems default primitives into a 2D envorment without wasting resources, however writing your own collision system and plugging it in would be fairly straight forward.

Yes and these joints should remove the rotation calculations or the performances will be bad.
How, and I really think we should make collision system pluggable.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #7 - Posted 2005-11-25 14:33:32 »

ODE is not built on a spring system, so you can't do what you suggested. But you can reset the rotation each step, but it causes bumps when the object moves.

I don't understand.  Physics is physics.  f = m * a applies regardless of the use of springs.  Are you saying there is simply no way to inject a force into the system or filter out an undesired force component to artificially balance the forces on a body?

I basically suggesting that rather than resetting a position or rotation, that there be a way to prevent a (unbalanced) force from applying to movement on that axis of translation or rotation in the first place.

I admit I am speaking from ignorace of the ODE system though.  But I wonder how constraints are placed on the system to begin with.. i.e. if I wanted to model the classic amusement park test of strength game where you hit a lever with a mallet to send a weight shooting up a rod with a scale, toward a bell at the top.. I hope you know what I mean Smiley   Anyway, how would you keep the weight on the rod?  I guess that "sliding along a rod" thing is a special kind of joint? .. actually I'm pretty sure that is a joint.

Now with a free body, call it "Mario" Smiley, how does a special joint prevent rotation?  If the joint is attached to Mario, what is the 'other' end of the joint attached to such that Mario can move around on the 2D plane, but not rotate?

It's sort of interesting to apply a "real" physics engine to a 2D mario-style game like this.

Offline arne

Senior Devvie




money is the worst drug- we should not let it rule


« Reply #8 - Posted 2005-11-25 15:25:53 »

ODE is not built on a spring system, so you can't do what you suggested. But you can reset the rotation each step, but it causes bumps when the object moves.

I don't understand.  Physics is physics.  f = m * a applies regardless of the use of springs.  Are you saying there is simply no way to inject a force into the system or filter out an undesired force component to artificially balance the forces on a body?

Yes, what you say is correct - As far as I understood the whole business, the joints simply apply forces to make sure the joint-restrictions are preserved. So actually both methodds of dealing with the problem would be equivalent.

BUT

If it is possible for joints to do more than this - Joints would be the way to go, because it'll make calculation faster and the joints more stable.

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #9 - Posted 2005-11-25 16:20:08 »

Wow ! I get pretty confused when I read all these thoughts..

Joint is a pretty undefined thing in my mind. Is it just :
 - A way to "attach" two bodies to obtain a specific behavior
or
 - Something that apply a force each step ?

I abandoned ODEJava a some weeks ago but what I remember is when I was resetting the rotation there was bumps in my character's movement.
It's simply because :
 - Forces are applied to the body and it moves as realworld physics would
 - The collisions are detected
 - I reset rotation
 - The collisions are applied
Or something like that (I can't remember exactly)

We could probably make the physics "adaptable" because I think the realworld physics are pretty boring for most game cases. So if we could remove "features", such as gravity (made in ODEJava), rotation, or inertia, or add some : air resistance....

I'm sorry I'm giving so general and vague ideas.. but I have no clear idea presently...

Anyway it's very interesting, I'm glad there are still some people interested in that...

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #10 - Posted 2005-11-25 17:14:29 »

For sure.. I think it would be cool if we could "change the rules".. e.g. make the force of gravity act more like a spring pulling objects down, or have surfaces with inverted friction characteristics, so they didn't counteract a force, but complemented it to increase the force vector.. making "super ice" that was "less than frictionless" Smiley

For your rotation problem, that's where it makes sense to implement the "rotation stabilizer" as a joint.  Then while forces are applied the "joint" could constrain the rotation forces so that they are always 0.

Offline arne

Senior Devvie




money is the worst drug- we should not let it rule


« Reply #11 - Posted 2005-11-26 08:53:23 »

Quote
So if we could remove "features", such as gravity (made in ODEJava), rotation, or inertia
Not remove, but the possibility to unplug those. Or to change them by setting the reaction with interfaces.
i.e.:
1  
2  
3  
interface Reaction {
  public void execute(Body b);
}


it could then be used like this:
1  
2  
3  
4  
5  
class Gravitation implements Reaction {
  public void execute(Body b) {
    b.addForce(0,0,-10); //if z is up
  }
}

or
1  
2  
3  
4  
5  
6  
7  
class AirFriction implements Reaction {
  public void execute(Body b) {
    Vector3 v = b.getVelocity();
    v.scale(-0.1f);
    b.addForce(v);
  }
}

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #12 - Posted 2005-11-26 13:03:26 »

Yes !!
It's really a good concept I think.
We should dig that more, I'm sure we can implement other game ideas with that.
Hmm.. could we do slightly more complex behaviors/reactions ? How about a pre-made boucing ball ? You just have to adjust its mass, bounce factor... We could do many more predefined objects like that. Or if you don't like that system we could just make a list of examples "How to do platform movement with JOODE", or "How to have proper car physics". I think it's good if we think of JOODE as game-oriented rather than realworld-physics-oriented.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline arne

Senior Devvie




money is the worst drug- we should not let it rule


« Reply #13 - Posted 2005-11-26 16:30:30 »

Quote
I think it's good if we think of JOODE as game-oriented rather than realworld-physics-oriented.

definitely Smiley


:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #14 - Posted 2005-11-26 17:55:40 »

Quote
Joint is a pretty undefined thing in my mind. Is it just :
- A way to "attach" two bodies to obtain a specific behavior
or
- Something that apply a force each step ?

Joints enforce a constraint between two bodies (or sometimes just one body). The constraint is defined using a jacobian matrix. Using that archetecture you can make the two bodies hold an invarient to one another such as they must rotate around a certain relative point etc. It would be fairly easy if you understood these jacobian matrices to create an invarient that kept the body positionally in one plane or stopped it rotating. As for doing this economically without wasting computers resources on unecissary 3D calculations that is really out of the scope for one system.

Quote
Hmm.. could we do slightly more complex behaviors/reactions ?

Actually I was doing this using javaODE. The first step to making the system easy to expand is having a well defined event system. The way I had it working was that when bodies, joints and geoms were created or destryoed they emmited an event. The were also of the type "Bindable". Bindable objects could be bound to other bindables. When was destroyed all other bound objects would be destroyed. With this event system it was fairly easy then to add custom behviours to things. Behaviours were bindable and becuase of the event system they were tidied up when stuff was going on. The other main event model I added was an event system that delivered world.step() events.

So yeah, if you wanted a spring system added you could create a Spring and add it to a body. This would behind the scenes bind to the body(or bodies) and also register itself with the step event model. Every time the world would be stepped the spring could apply its forces. If the body (or bodies) was removed from simulation you would not need to worry about tidying up the spring becuase it would take care of itself.

It was kind of my intention from the start to add a good event model to JOODE becuase it makes it so much more extensable. If you want global behviours for bodies (like gravity) you can add code that listens for creation events and add bindable gravity behaviours to all bidies that are created.

Like I said I have had this kind of thing with my old system. What I also had with my old system was a generic way for behaviors to be defined. I did not actually like it though because to make it generic it basically ended up as complicated as just writing java code. What I did find really useful though was allowing behaviours to be defined in scripts (beanshell scripts actually). So I am thinking maybe it would be really good if we added that kind of support to JOODE. I am not sure if people will think its poluting the system though. I would suggest we add scripting support using whatever that standard is for scripting, thus not tying the user to any particular scripting technolgy. I would also suggest that scripting and dynamically loading behaviors should be transparent operations. So you add behaviours defined in scripts exactly the same way as behaviors defined in dynamically loaded classes (so you can gradually replace scripted code with compiled code).

Anyway, most of these concerns are secondary utill JOODE is working preoperly  Huh


Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #15 - Posted 2005-11-28 07:51:55 »

I totally agree with you.

I'm actually continuing my own little physic engine for my 2D game cause I need to release a version soon, but after that, I'll take a look at the code and contribute as I can. So later we can add all these desired features.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #16 - Posted 2005-12-20 16:31:41 »

Okay, me again.

So I didn't changed my plans, I think I will :
  - Make a "clean" version of my little physic engine (2D, no rotations, simple collisions, no complex algorithms) for a first version of my game
  - Merge with JOODE / use JOODE later

But I'm not sure how the 2nd stage wil be realized..
Do you think it's possible to do a 2D/3D engine ? How will we be able to "unplug" some features (like rotation) ?
What is going on actually for JOODE ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline f.l.x

Senior Devvie


Projects: 3


there is no place like 127.0.0.1


« Reply #17 - Posted 2005-12-22 10:23:15 »

a good (fair complex) 2d phisics engine would be a very nice tool to have, this game (gish) comes to my mind. It has the better phisics engine in a plataform game i've ever seen.

Litterarum radices amaras, fructus dulces
http://flx.proyectoanonimo.com
figth spam!
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #18 - Posted 2005-12-22 16:07:41 »

Yes, you're right, Gish has a really wonderful physics engine..
Any JOODE developer idea on 2D/3D issue ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #19 - Posted 2005-12-23 01:08:24 »

Well beyond what I said last time, creating special joints that fix objects into a 2D plane or stopping rotation, no.
But I beleive those two ideas to be pretty interesting, so when I do joints I am gonna have a look to see if I can do that.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #20 - Posted 2005-12-23 09:26:32 »

Well, creating a joint that fix an object in a 2D plane isn't a good idea, because it imply more computations for a simpler thing. For stopping rotation, a "code unplug" would be feasible, but for constraining in a 2D plane, I don't see how this could be easily done, since it's in all the computations formulaes.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #21 - Posted 2005-12-23 14:12:10 »

Oh right..... I do see what you mean and it is technically feasable. After the calculations are done after stepping a method is called named stepBody or something. Its the bodies responsability to actually take the results from the LCP algorithm and add it to its angular and linear velocity. So.... I spose if it just ignored it..... No wait..... We have still wasted computations in the step bit..... Still it probably complicates things a bit less for the LCP algorithm by one less constraint (the joint) being present.
Yeah. So a subclass of Body can over ride the stepBody method and ignore certain parts of the calculations. And make sure it never ends up with a linear velocity in one direction or whatever. My ownly concerns is that a joint or someting might go crazy trying to compensate but they way I have it working in my head at the moment I don't think it can do that. Hmmmm. Interseting.

The thing I liked about doing it with joints though is that you could define the plane of movement. If you just ignore one coord, as in the idea above, you are limited to movement in axis aligned planes. OK if your whole game is 2D but not the flexability I crave Shocked)

If you really wanted the system to be pluggable, then I suggest that bodies would throw a step body event and do nothing by default. It would be the responsability of (bound) listeners to implement the actual application of linear velocities and angular velocities. The thing is though, stepBody is such a low level method that it seems wasteful to pipe it through an event model... still.... you might be able to do some insane things....hmmmmmm......

An event model actually isn't the ideal thing. I forget what the proper pattern should be. The interceptor model, like JBOSS's old security system before AOP, invoke(...) and all that.... You can plug together a sequence of things to be applied. The problem with the event model system is you never know what order stuff is going to be applied so you need a pattern with ordering in the sequence of events. Anyway details! details!

Let me know what you think...

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #22 - Posted 2005-12-24 13:18:25 »

Ok here's what I think : Why don't make JOODE *truly* open ?
I mean, very modularized, like :
 - You can choose if you want to have a 2D or 3D simulation
 - You can choose if you want to compute rotational stuff or not
 - You can choose which algorithms that is used to solve equations
 - You can choose the integrator you want
 - You can choose the friction model you want
 - And so on..

That will make JOODE *really* interesting, because everyone can implement every algorithm he want, from the naive first order Euler integrator with no rotational computations to the complex Kunga-Rutta 4 robust algorithm, including something like a Verlet integration scheme.
To implement something like that, we surely need a "sequential system" in "physic simulation stepping". And interfaces for objects.
I suggest also that we shouldn't limit JOODE to rigid body simulation, so we can implement cloth simulation, partial and global deformations of objects, and so on.
All algorithms should be contained in a class that implement an interface (Ex : EulerIntegrator implements Integrator), and are nothing but code that treats data contained in the World / Space / Geom / Body / Particle / Joint classes.
So we clearly data and the code.
What we have to do is determine if this is really feasible and if yes how to do that. We should be careful because sometimes models don't have the same data representation.
Following this idea, there would be only one type of space, and several type of CollisionTesters. However this could cause problems as kinds of spaces sometimes needs additionnal data stocking.
So we could maybe replace this by simply extending basic classes, so we can add data needed for the algorithm to work.

With this approach, I then see JOODE as a "big open-source framework released with a bagful of algorithms" rather than a "semi-open library with only one buggy algorithm useable only in specific cases".

As for the 2D plane in arbitrary location / orientation issue, I think we could do the 2D/3D choice AND a 2D plane joint, cause it won't have the same uses.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #23 - Posted 2005-12-24 21:36:44 »

Quote
Well, creating a joint that fix an object in a 2D plane isn't a good idea

Errr...you are joking right ?

www.novodex.com

'nought said

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #24 - Posted 2005-12-27 15:16:53 »

Well there are allready a variety of constraint solvers in the pipeline. Cholseski, LCP various different optimizations leading up to that point. At the moment its very crude the way you choose which you want to do (change a static variable and recompile). But this will be turned into an abstract factory pattern at some point (using the properties system kitfox made). So in a sense some of the functionality you want is there. It is definatly not the case that there is just one buggy algorithm that everything else is built around.


Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (50 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (57 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!