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 bugsSo 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.

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.

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 bugsSo 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.

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.

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 bugsSo 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.

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 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" , 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.

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.

Joint is a pretty undefined thing in my mind. Is it just : - A way to "attach" two bodies to obtain a specific behavioror - 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 appliedOr 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...

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"

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.

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.

Joint is a pretty undefined thing in my mind. Is it just :- A way to "attach" two bodies to obtain a specific behavioror- 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

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

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.

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 ?

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.

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.

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 )

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.

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.

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.

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