jME Physics 2 - collaboration between projects

Game Mechanics
#1

In the project proposal thread for jME Physics 2 MagicSpark[BlueSky] stated

[quote]I won’t object to the jME Physics project but I do think it’s principle is the opposite of code re-use and collaboration between projects.

I just wonder if jME Physics will use a fork of JOODE, as it does with ODEJava. I heard jME physics was fixing some bugs in ODEJava, then why do not contribute to ODEJava itself ?

That is splitting effort you don’t think there are enough duplicated work in the java game development area ? Don’t say Xith3D and jME aren’t in competition. (Some will say “it’s not the same developers that use it”, "they don’t have the same goals/architecture/performances/usecases/structure/taste).

Forks are good when projects are definitely dead (as Java3D was, why Sun just resurrect it ?) and when the projects owners don’t want any further contributions different from the original goals.

And let me tell you if you guys succeed to make a common adapter for ODEJava, JOODE, Novodex, Newton, Havok, then I promise I’ll shut up. But if it’s the case then you’d better to do a scenegraph-agnostic & physic_library-agnostic lib. But that just seems impossible to me.
[/quote]
Which indeed is an important point!

Copying the ODEJava sources for jME Physics was not the best idea. It was done to avoid conversion of the math classes - jME uses different Vector3fs, Quaternions and Matrices… currently I don’t have a better idea for this as to change the imports and adapt to the behaviour of those math classes.

I would love to have a JOODE binding for jME Physics 2! Only I’m afraid we will face the same problem like with ODEJava - any suggestions? At least the conversion to native data is gone - maybe we should then accept a conversion from (and to) jME math package?

btw: the only actual bugfix for ODEJava itself I have done was discussed in the forums and added to ODEJava (the fix for triangle buffers).

And regarding that scenegraph agnostic physics library abstraction layer… well, yes, I think that does not really work, too.

#2

Thanks for bringing this post to this forum. It seems to be an interesting discussion of how to get scenegraph-based renderers together with physic-engines, but is it realistic to talk about this?

A scenegraph-renderer consists of nodes, which contain information about the position and the rotation of objects as well as information about the geometry of these objects. Additional it keeps information about how things get rendered.

A physics-engine consists of bodies, which contain information about the position and the rotation of objects, and geometries, which describe the geometry of these objects. Additionally it keeps information about forces, masses, and joints.

Summarized: Position vector, rotation matrix or quaternion, and geometry information must be shared. That’s quite few information, but it is very close related to the math library used.

Bringing both worlds together results in two options: Having the same math library in every project or having wrappers which hide the math libraries from the implementations. The current implementation of JOODE has its own math library, but this will be replaced by another one. We should think about having a wrapper hiding the concrete implementations, since the operations used mostly are basic vector and matrix operations. I do not know what impact this will have on performance and memory consumption, but it would give us an option to profit from acceleration hardware.

Anyways sooner or later JOODE will leave the path of being a pure Java port of ODE. Currently already some components are under development that bring new features to JOODE not implemented in ODE. The JOODE API will have to change as well. If we step in direction of an open architecture, which has a better support for different implementations for collision detection, forces, and constraint solvers, we could make JOODE customizeable. There we can benefit from an object-oriented programming language. This would also allow us to add algorithms used in other physic-engines.

So I am interested in what are goals of jME Physics 2 if it wants to everything agnostic? As stated above I think JOODE can contibute only very few things to this dicussion.

#3

It does not. As stated above it does not make sense to me to be scenegraph agnostic. jME Physics is a physics abstraction/API layer for the jME scenegraph.

I think the developers on this forum can contribute a lot to this discussion :slight_smile: (and that’s not only JOODE developers)

Your suggestion to have wrappers for the math package or to abstract from the actual data holding classes seems problematic to me: first performance would be degraded (polymorphism costs a magnitude in access time). Second it would be very hard to define the semantics of operations on the math data without actually specifying the whole math package.

Thus either using the same math package or converting values on demand seem to be the only choices to me. Why do you use a custom math package in JOODE and which package should be used in favor and why?

#4

With Volatile-Engine and Novodex, i made a few interfaces that allowed me to convert from one math library to the next using those interfaces. Novodex has its own physics library in C++ and VE has its own library in Java, so the wrapper for the Novodex classes that implemented the interfaces held a pointer to the actual object in C++ land, while Java just had a concrete implementation.

A set of interfaces that JOODE can possibly supply would be the best option IMHO, not just for jme-physics, but to anyone else invovled.

DP

#5

My fault, I mixed up the response from MagicSpark with the jME Physics goals. Sorry.

That’s why I said JOODE :wink:

I think about wrappers, which implement an common interface. By doing this we could have implementations for different libraries. I do not think that the performance impact would be that much. Moreover it is questionable if the impact on memory consumption is nearly the same just as having math structs twice.

The custom math package is a relict from the ODE port. ODE has its own math library and this was ported as well. But this library is very unhandy, since it makes use of pointers a lot. As I already mentioned it will be replaced sooner or later. For me (personal opinion) vecmath from Java3D would be the preferred library. I think it is the most popular library used for game development.

#6

About vecmath libraries, Yuri VI. Gushchin mentioned an alternate vecmath lib that generated much less garbage. But there are legal issues with Sun, cause it’s an implementation of javax.vecmath

#7

For deciding wether to use interfaces or dublicated position/rotation/scale etc. we really should do some performance tests. (my guess is that copying data could be faster than having interfaces)

But I think what really should not be doubled is the memory needed for trimesh geometry as that is a lot of memory. Wouldn’t it be most appropriate to use java.io float buffers there? Does JOODE use them?

#8

We have to obey the tradeoff of performance and memory consumption. But some tests would be nice :slight_smile:

Right now JOODE does not support trimesh geometry. But I agree that the trimesh definition should be an array of float of a float buffer. It will be interesting how to handle Vertices, Edges, and Faces, because this are informations that might be needed by Renderer and Physics Engine.

#9

I thought the overhead of calling an virtual method these days is pretty much equal with that of a concrete method with modern JITs ? And this is more so with 1.6…

Copying data is a really horrible way of doing it; you can’t keep references to a Vec3f and so on every single update, every single dynamic object has to copy data over from its physics counterpart whether it has moved or not (because it simply doesn’t know if it hasn’t moved or not, unless JOODE supports sleeping). Keeping references means that only the objects that have moved will suffer the virtual call overhead, which is neglectiable these days…

Or is there something im missing ?

DP

#10

Let’s assume we will have very low impact on performance by putting there an wrapper around the concrete math implementation. What are the concern regarding memory?

As far as I see we only need plain vector and matrix operations for JOODE (add, multiply, dot-, and scalar-product). The vector and matrix data will always be a plain array of float or double values. The rest of the code will be methods to manipulate the data. What will a wrapper look like?


public interface Vector {
  void add(Vector vector);  
  void add(Vector vector, Vector result);
  void multiply(float a);
  void multiply(float a, Vector result);
  ...
}

Isn’t this the code implemented by nearly every math library? What are the benefits of putting there a wrapper instead of a concreate math library? If we manage to share the underlying data structures (arrays) from my point of view we will have no benefit.

So my suggestion is to put there interfaces, which allows us to share the data structures (arrays), and use whatever math library fits best to the needs of JOODE.

#11

I want to mention one thing - we will probably not be able to get away from using the current math library, or each math library would have to support general nxn matrices (for the LCP - and lots of other uses)

So the mathlibrary would only show at the front - we should check, how deep this would go. And then we can decide what would bring more performance and/or better design.

#12

For the internal calculations - especially the lcp solvers - we will need own math implementations.

The frontend requires us to have:

[ul]

  • position vectors
  • rotation matrices and/or quaternions
  • force vectors
  • torque vectors
  • maybe the moment of inertia matrix
  • vectors for the definition of geometries
    [/ul]

I think that’s all. If we have interfaces working with arrays we won’t have to show anything at the front - the math library will be hidden from the user.

#13

The advantage of having interfaces instead of a concrete implementation is that graphics libraries such as Xith that have their own library can still use JOODE without having to have redo their maths libraries. Also, for game engines like VE that already have a binding to another physics library, they can generalise their entire maths stuff with specific implementations that are relative for each physics library used (e.g. for Novodex, your JNI binding would generally hold a pointer to the maths object, and the methods are native).

DP :slight_smile:

#14

But having an interface with a concrete implementation for each library results in exactly the same as using a specific library in JOODE.

We only have to share the data (vectors=float[] and matrices=float[][]).

#15

<<Hey, here’s the “merger guy” comin’ again 8)>>

I proposed recently (although it was before this discussion) a project called OpenMali on dev.java.net. (It’s not an help plan for Africa, I’m not working for any humanity organization ^^) It means Open Maths Library. It’s actually ridiculously small, to say you everything there’s code for computing angle between two vectors (in -2PI, 2PI range which isn’t possible with vecmath), a distance formula (so I don’t have to create a vector when I just want to know the distance between (object1.x, anotherobject.y) and (anotherobject.y, object56.x). It avoids 1 object creation and 1 function call (and 1 garbage collection operation), and a fast point-inclusion test for 2D polygons.
As you see, there’s not much done, but it’s written, and it work, and it’s reusable, and there are both function(float x[], float y[]) and function(Vector2f[]) versions so you even don’t need to use vecmath if you are a guy coming from C which thing “objects are bad” :stuck_out_tongue:
What I’d like to see happening is some people gaining interest for that approach and writing well-known algorithms in a generic, reusable and clean manner in the form of static functions. Special data structures would be used only for return values if it’s more complex than a boolean, a float or an array of floats.
I think we could implement vector & matrix thingies in that and migrate progressively used libs to that. I want it relatively lightweight so it wouldn’t be a great effort for developers to use it.

#16

Yes, I think so: libraries might not want to give away references - to detect changes to their vectors and avoid recalculation of derived values for each step.
And virtual function calls vs. direct attribute/array access still is a performance difference - even in JRE1.6. That’s why I suggested to test the impact first.

true

not necessarily! javax.vecmath -> Vector3f -> no float[]
This is exactly the problem: the math library would have to use the same interface / data class which is not the case, usually.

And regarding the interface proposal with functions: you can’t unify the different math libraries this way as they may have similar signatures but methods behave differently (e.g. javax.vecmath.Vector3f.add(Vector3f) vs. jme.math.Vector3f.add(Vector3f)). So, yes, hdietrich this would be no benefit.

But I don’t see how this ‘common interface’ should work :-\

@BlueSky: it aren’t the calculations/functions that cause the trouble but the data synchronization - so why does another math library help?

#17

No, i disagree. A library might contain listener for other implementation to get notified of changes, but it will not provide hooks for direct data manipulation. Especially for a physics library this would almost always result in unpredictable results. If there are improvements they have to be made in the physcis library.

That’s really bad. So sorry for javax.vecmath :wink: Then I see no way for integrating data from javax.vecmath - unless we do not decide to use kavax.vecmath as underlying math library for JOODE.

You must provide implementations for every math library supported, that hide the math libarary’s signature. A factory could hide the concrete instantiation. But without gaining any benefit from this we do not have to think about this anymore.

What are the most common math libraries we should support?

Java3D = javax.vecmath
Xith3D = javax.vecmath
jME = own math library (does this one use arrays as underlying datastructure?)

#18

Oh, sure it’s completely useless.
We have about 30 different math libraries around for java projects (maybe 5-6 for game projects and one for each geometry/physic/math program)… Now we talk about collaboration, and we realize that everybody’s using its very own math library, there are no standards, some are using 3 floats (float x, y, z), some are using float[] (arrays) function behave differently they are more or less buggy and it’s pretty impossible to support them all without a huge overhead…
So, really, an unique math library is completely useless

And of course, either my point will be objected by 5-6 apostles of non-bloated very own personal optimized solutions, either nobody will have the time/motivation/courage to create this one and implement a correct thing… So saaaaaaaaaaaaaad…

#19

Sure, the ‘one and only’ math library would be nice :slight_smile: - do you expect that library to become the standard?

err, either I misunderstood you, or you didn’t understand what I meant… what do you mean with “hooks for direct data manipulation”? What I meant: many libraries do something like this:

private Vector position;
public Vector getPosition() { return position; }

This is problematic if Vector is not immutable for the public. You can do somePhysicsObject.getPosition().setX( 5 )! And you could even do this while physics is in the middle of some computation etc.
That’s why my suggestion would be to hand out values only not a reference to a mutable object (or hand out immutable objects).

#20

OK, now I understand what you mean :wink: Well, making values immutable requires an interface again. But handing out only values would be fine. Values have to be copied again, if they should be immutable, but if you want to manipulate the returned data again, there is no way around copying values. You also have to be aware that you will be able to manipulate data, if we decide to put there an interface for float arrays. If the reference to the array are kept and data is manipulated outside the physices engine then the physics engine gets corrupted again. But I prefer to put there some best practice adviced over making everything bullet proof.