Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
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  
  jME Physics 2 - collaboration between projects  (Read 4562 times)
0 Members and 1 Guest are viewing this topic.
Offline irrisor

Junior Member





« Posted 2006-05-16 08:49:43 »

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.
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.
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #1 - Posted 2006-05-16 10:39:49 »

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.
Offline irrisor

Junior Member





« Reply #2 - Posted 2006-05-16 11:11:15 »

So I am interested in what are goals of jME Physics 2 if it wants to everything agnostic?
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.

Quote
As stated above I think JOODE can contibute only very few things to this dicussion.
I think the developers on this forum can contribute a lot to this discussion Smiley (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?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #3 - Posted 2006-05-16 11:35:04 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #4 - Posted 2006-05-16 11:48:41 »

So I am interested in what are goals of jME Physics 2 if it wants to everything agnostic?
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.
My fault, I mixed up the response from MagicSpark with the jME Physics goals. Sorry.

Quote
As stated above I think JOODE can contibute only very few things to this dicussion.
I think the developers on this forum can contribute a lot to this discussion Smiley (and that's not only JOODE developers)

That's why I said JOODE Wink

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.

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.

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?

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.
Offline Amos Wenger

Senior Member




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


« Reply #5 - Posted 2006-05-16 15:14:00 »

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

"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 irrisor

Junior Member





« Reply #6 - Posted 2006-05-18 05:46:03 »

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?
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #7 - Posted 2006-05-18 08:59:11 »

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)

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

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?

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.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #8 - Posted 2006-05-18 09:24:26 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #9 - Posted 2006-05-18 12:36:09 »

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?

1  
2  
3  
4  
5  
6  
7  
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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Member




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


« Reply #10 - Posted 2006-05-18 14:38:12 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #11 - Posted 2006-05-18 15:52:09 »

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

The frontend requires us to have:

[ul]
[li]position vectors[/li]
[li]rotation matrices and/or quaternions[/li]
[li]force vectors[/li]
[li]torque vectors[/li]
[li]maybe the moment of inertia matrix[/li]
[li]vectors for the definition of geometries[/li]
[/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.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #12 - Posted 2006-05-18 16:22:42 »

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 Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #13 - Posted 2006-05-18 17:15:59 »

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[][]).
Offline Amos Wenger

Senior Member




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


« Reply #14 - Posted 2006-05-19 14:29:36 »

<<Hey, here's the "merger guy" comin' again  Cool>>

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

"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 irrisor

Junior Member





« Reply #15 - Posted 2006-05-19 14:36:21 »

[...] 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 ?
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.

We only have to share the data
true

(vectors=float[] and matrices=float[][])
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 Undecided

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

Junior Member




Harald Dietrich


« Reply #16 - Posted 2006-05-19 16:33:03 »

[...] 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 ?
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.
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.

(vectors=float[] and matrices=float[][])
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.
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.

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 Undecided
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?)
Offline Amos Wenger

Senior Member




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


« Reply #17 - Posted 2006-05-20 10:42:30 »

@BlueSky: it aren't the calculations/functions that cause the trouble but the data synchronization - so why does another math library help?
<ironic>Oh, sure it's completely useless.</ironic>
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...
<ironic>So, really, an unique math library is completely useless</ironic>

<pessimistic>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...</pessimistic>

"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 irrisor

Junior Member





« Reply #18 - Posted 2006-05-22 08:50:48 »

Sure, the 'one and only' math library would be nice Smiley - do you expect that library to become the standard?

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.
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:
1  
2  
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).
Offline hdietrich

Junior Member




Harald Dietrich


« Reply #19 - Posted 2006-05-22 09:52:05 »

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.
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:
1  
2  
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).
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.
Offline Amos Wenger

Senior Member




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


« Reply #20 - Posted 2006-05-22 16:20:07 »

Sure, the 'one and only' math library would be nice Smiley - do you expect that library to become the standard?
It could be. But only if every game library lead developer find it useful, use it and contribute to it...

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
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.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!