Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (525)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (594)
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  
  Shall we join effort and make ODE pure Java?  (Read 3681 times)
0 Members and 1 Guest are viewing this topic.
Offline Java Cool Dude

Senior Devvie




Java forever


« Posted 2004-02-19 21:37:21 »

Thoughts?
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #1 - Posted 2004-02-19 21:59:18 »

I'm all for it - though after seeing the trig performance I wonder how much that will effect the overall performance?

The main issue is that it may be hard to convert small bits at a time because of how the data structures must interact with the native code at the low level.

Offline shawnkendall

Senior Devvie





« Reply #2 - Posted 2004-02-20 00:08:59 »

We examined fairly thoroughly for our GDC demos, as we really wanted it all in Java because of the number of platforms we will be running on.

Unfortunately, ODE is not going to be a simple port for several reasons.
1) There is significant use of C function pointers, which of course means an object based model needs to be agreed upon to cover that.
2) There is array manipulations using *gasp* NEGATIVE indices.  i.e. value[-1], value [-2] etc. For those areas the numeral methods need to be completely rewritten.

So that said, I am all for it, the only remaining problem is that the Java imp will always be a version or so behind the C ODE because of that heavy conversion that will need to be done for each version. Undecided

Still...perhaps some custom C to Java processing tools for ODE will help make it happen.

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
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 #3 - Posted 2004-02-20 01:06:14 »

Quote
Unfortunately, ODE is not going to be a simple port for several reasons.
1) There is significant use of C function pointers...

...the Java imp will always be a version or so behind the C ODE because of that heavy conversion that will need to be done for each version.


Function pointers shouldn't be a problem - worst case, pass interface references instead.

How fast is the main ODE development moving?  I would think that once the initial port is done the Java version could keep up with incremental changes (all the basic numerical methods would be ported) or just decide to branch out on it's own and not track the main ODE project so closely.

Offline Jani Laakso

Junior Devvie




Do it with Java!


« Reply #4 - Posted 2004-02-20 04:48:00 »

Quote
We examined fairly thoroughly for our GDC demos, as we really wanted it all in Java because of the number of platforms we will be running on.


Collision part is independent of ODE as the author states. Also, good collision libraries are as complex as ODE itself, at least according to my knowledge but I may be wrong here. So if anyone would wan't to convert ODE's functionality into Java at least it could be divided in two parts. Just a tought but does there exist any good Collision classes for Java that could be extended (haven't seen any)?

In other words, you can plug any collision library to ODE providing that it generates contact points based on collisions, here's a snippet taken from ODE's documentation: "Using ODE's collision detection is optional - an alternative collision detection system can be used as long as it can supply the right kinds of contact information."
In practise this means that the collision library should provide the following information:
class contactGeom {
 Vector3f pos;       // contact position
 Vector3f normal;    // normal vector
 float depth;        // penetration depth
 geom1,geom2;      // the colliding geoms
}

Shawn, have you evaluated ODE's standard collision code, is this a lot simpler than OPCODE? What about OPCODE collision code which supports TriMesh collisions, how complex this would be to convert into Java?


Cheers, Jani!
Offline Bombadil

Senior Devvie





« Reply #5 - Posted 2004-02-20 05:08:08 »

I'd love to see a pure Java ODE version.

Quote
the only remaining problem is that the Java imp will always be a version or so behind the C ODE because of that heavy conversion that will need to be done for each version. :-\

That wouldn't be a big problem I think: we could see it as some kind of quality assurance (we won't have the newest bugs with new ODE versions ;-).
Offline bloid

Junior Newbie




Kiss the ring!!


« Reply #6 - Posted 2004-02-20 10:38:09 »

Quote
I'm all for it - though after seeing the trig performance I wonder how much that will effect the overall performance?


I ran a test, and JDK1.5 seems to be twice as fast with trig (compared to 1.4)...

Still not FAST, but faster Wink
Offline Mojomonkey

Senior Devvie




ooh ooh eee eeee


« Reply #7 - Posted 2004-02-20 11:40:42 »

Seems to me porting ODE would be quite painful? Why not create a pure Java Physics Engine? Maybe use ODE as a model, but don't just do a straight port, design it from the ground up.

Don't send a man to do a monkey's work.
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #8 - Posted 2004-02-20 12:10:46 »

Quote
Seems to me porting ODE would be quite painful? Why not create a pure Java Physics Engine? Maybe use ODE as a model, but don't just do a straight port, design it from the ground up.


Sounds easy enough.  Got a spare half-hour you could slot that in? Grin

Hellomynameis Charlie Dobbie.
Offline Mojomonkey

Senior Devvie




ooh ooh eee eeee


« Reply #9 - Posted 2004-02-20 12:11:50 »

Hehehe, well I didn't say it would be easy.... BUT if it would also be difficult to do a straight port, why not take a little more time and do it right?  Tongue

Don't send a man to do a monkey's work.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline shawnkendall

Senior Devvie





« Reply #10 - Posted 2004-02-20 12:40:43 »

Go for it!
Dynamics is not my specialty but I'll be happy to test version 0.1  Wink

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #11 - Posted 2004-02-20 14:23:06 »

Well porting is essentially not going to be much other than using ODE as a reference and coding most things from scratch, and having the same methods in the API.   I recall that Jani has already done some higher level stuff on top of the basic ODE API though - which will help make it more OO and Java-like I guess..

Offline Jani Laakso

Junior Devvie




Do it with Java!


« Reply #12 - Posted 2004-02-20 16:06:00 »

Quote
Well porting is essentially not going to be much other than using ODE as a reference and coding most things from scratch, and having the same methods in the API.   I recall that Jani has already done some higher level stuff on top of the basic ODE API though - which will help make it more OO and Java-like I guess..


Back referring to the weekend project ehh :-). Odejava's higher level API might be of some help, then again not, they were done in a flash. Low Level API is one to one with ODE's own API, but even the higher level API is somewhat ODE styled (naming conventions), this is on purpose.

But seriously, I think getting any kind of physics engine for pure Java would be great. It can be straight port of ODE or it can be designed from group up, whatever makes the project successfull.

Now we're getting to the definition of pure Java physics engine project. What does one wan't to accomplish with this project, when first version should be ready etc. After the definition is clear, I'd select the least riskiest way to complete the project, drop some functionality if neccessary. Initial versions can be based on anything, it does not have to be too good looking etc..

It might be that ODE codebase would offer quicker way to to complete an physics engine for Java, if this is the case then I'd go for straightforward port.

But if it seems that most things have to be written from scratch, I mean also design new data structures and change the actual architechture, then I would only get ideas from ODE and make totally new API that is best suited for this project. It would sure be nice if someone had good opinion about this. I think "porting ODE" might get to this point pretty easily, it wont be a port anymore..

It all comes to people.. At the minimum, this project needs people that have good knowledge of physics and medium programming skills. If porting is the choice then I suppose there's always lurking some Java coders behind the curtains that can be drafted into another open source project, ehh Grin

Time to open redwine, it's weekend, later!
Offline syrusm

Junior Newbie




Java games rock!


« Reply #13 - Posted 2004-02-21 14:54:00 »

Quote

Shawn, have you evaluated ODE's standard collision code, is this a lot simpler than OPCODE? What about OPCODE collision code which supports TriMesh collisions, how complex this would be to convert into Java?


Jani, as you mentioned, ODE was designed to allow the users to use their own collision library if they really want to. The core collision code that was written by Russell Smith (ODE designer and implementer) is not very large. To get ODE to work, we can go a long way with just Planes, Oriented Boxes, and Spheres. Finding the collision information needed by ODE (collision point, normal, and penetration depth) is not difficult for these primitives. However, to get the entire collision types available in ODE (and contributed code) supported in a Java version, reasonable amount of code will have to be written. Just to give others some Idea, the following collisions will have to be performed/handled to return the "contact info" needed by ODE:
--- core ---
Plane
Sphere
Oriented Box
--- other ---
Cylinder
Capsule (Capped cylinder)
Ray
Triangle Mesh


note that every type needs to be able to collide against every other type. for example, there needs to be Capsule to TriMesh, Oriented Box to trimesh, Sphere to triMesh ect...

It is not that the code is extremly difficult to write. Especially knowing that there are many books published on them and there are plenty of open source collision libraries available (including ODE's source). But the bottom line is that someone has to write it and test it. As it stands today, even ODE doesn't have all types handled properly. basically besides the core types, anyone who needed anything had to write it which then got moved to ODE.

This brings up another point; there are always people who contributed code to ODE. They are destributed in the "contrib" folder of ODE and if people like it, it tends to gets moved to be part of ode. If ODE is ported directly, the other usefull contributions to ODE can also be ported.


Quote

But seriously, I think getting any kind of physics engine for pure Java would be great.


I couldn't agree with you more Smiley. As Shawn mentioned, we would have loved to used it for our GDC demo. Especially since we have to run on multiple platforms.

Quote

It can be straight port of ODE or it can be designed from group up, whatever makes the project successfull.

I think it is far more practical to try to do a straight port. It will still be a lot of work and we will have to do something about the negative indeces Smiley. It only took me 5 seconds of looking at the code before I was convinced that a direct port would not be trivial. In addition, we would have to do without 3x4 matrices (interestingly, the 0,0,0,1 row is left out. In addition, translation vector is *not* used. you have to use a float array of length 12 to set/get rot/scale )

Russell has put a lot of effort into ODE. is certainly didn't get to where it is in 6 months Smiley. Considering he had worked for Math Engine, has looked through other game physics libraries Wink, and understand dynamics issues in the context of games, it is probably good idea to take advantage of his knowledge (basically borrow most/all of the work from ODE). I personally like ODE and I am so glad that is available.  (BTW, I think Jani did a fantastic Job! )

I also want to mention another motivation for those interested in making a Java Physics library. The ODE Low-level API *is* low level. I personally am not a big fan of wrapping an API to make another API. I like to avoid it when possible. However, I don't think someone that uses a Java API should directly allocate a float array in the C heap (not the Java Heap), put data in it one at a time, and then pass it to a function, and make sure to manually free the arrays once he is done. This is what you currently have to do to set the rotation of an object to an array. (however some of these can be fix in the low-level API by using direct ByteBuffers)

I highly recommend not making a new API from the ground up. It will be a difficult task. It will take a lot of time and evolution just to get to where ODE currently is.  Porting is much more practical and safe even though it will require a lot of work.

Regards, Syrus
Offline Jacko

Junior Devvie





« Reply #14 - Posted 2004-02-22 09:29:09 »

I'm currently working on a rigid body sim for my final year project. It's basically an implementation of the material from the siggraph papers by Baraff et al. My tutor said it had to be in C++, but I would be more than happy to port it over to Java once I'm finished, around June. I really cant commit any time to a port at the moment.

If people wanted to start before then, I've got a stack of references to get them started on implementing a simulator from scratch.

Offline Jacko

Junior Devvie





« Reply #15 - Posted 2004-03-11 11:30:34 »

No takers huh?   Wink
Offline johnreynolds

Junior Newbie





« Reply #16 - Posted 2004-03-24 12:48:25 »

A pure Java physics engine is certainly desirable, but we should consider focusing on the interface first.
Jani has got a good start on defining a higher-level Java API for using ODE.  Let's help him flesh out the API and develop tools to help users build higher-level projects on top of the engine...

With proper design and encapsulation, the underlying ODE functionality can be reimplement over time.

Just a thought

John Reynolds
Offline Jani Laakso

Junior Devvie




Do it with Java!


« Reply #17 - Posted 2004-03-24 14:01:59 »

Quote
No takers huh?   Wink


What are we going to accomplish here?-) Sure pure java solution is nice but..

Pure Java physics engine consumes noticeable resources (talented physics people + developers). Realisticly speaking, one could think that if the project is started now, perhaps it's usable in a year or so. Of course it's all up to the people that you can recruite for such an project.

Currently ODE goes further by ODE community and keeping Odejava up to these changes should be pretty simple effort.

I'd like to remind that Odejava has been put out by single person in a couple weeks of effective work (mostly on weekends for couple months). Also, I'd say that Odejava is already ready for "production" use if you are not trying to push it too far. Thanks to William, Higher Level API is getting to a more mature state.

There's a huge difference on creating wrappers to an existing good solution and coming up good solution from ground up.

It's all about the gains and losses. Odejava was brought up with minimum efforts, bad side is that it needs a native linux, win32 or macos library (how bad is this really?).

Ideally (and ideologically) pure Java physics engine is the way and I think that someday a proper Java project is to be started by some physics guru. But I'd say this new engine should (IMHO) solve some fundamentally big issue or offer new features if someone starts such an big open source project. Hardly eliminating single native library justifies all the resources that you have to put into such an project.

Ok, there might be some rare cases where native libraries could be an issue. Biggest issue might become from tiny differences that different platforms have on the native code, this might be a factor if you are trying to accomplish something on non-uniform platforms. Pure Java applications do not have this issue.

Last, I wouldn't say native libraries are too big of an issue. As long as they are tested thoroughly on most platforms. You'll be most probably needing some anyway (like latest lwjgl or jogl library).

To me, multiple same area projects are nice, but I just like to get one working library before starting another. Same goes for scenegraphs, opengl bindings, sound, physics libraries. Most of these are still alpha. Hopefully people would concentrate on getting one library from each area to get into v1.0.
Offline johnreynolds

Junior Newbie





« Reply #18 - Posted 2004-03-24 15:32:14 »

Quote
To me, multiple same area projects are nice, but I just like to get one working library before starting another. Same goes for scenegraphs, opengl bindings, sound, physics libraries. Most of these are still alpha. Hopefully people would concentrate on getting one library from each area to get into v1.0.


I completely agree.

With respect to ODE, what we needed was a way of using it from Java.  Jani did a great job on this.

Where I do think value could be added would be to help define a "standard" Java API for utilizing Physics Engines (not just ODE).  The "reference implementation" could be bound to ODE.

The benefit would be the ability to focus on a higher level in an implementation independent manner.  Assuming that multiple physics engines are implemented, the user could choose the "best" for the task without having to change much code.

Perhaps we need to propose a JSR for this?  Java Physics Engine API, JPEA?

John Reynolds
Offline Jani Laakso

Junior Devvie




Do it with Java!


« Reply #19 - Posted 2004-03-24 16:34:36 »

Quote

Where I do think value could be added would be to help define a "standard" Java API for utilizing Physics Engines (not just ODE).  The "reference implementation" could be bound to ODE.


Perhaps there is such possibility, I do not have strong feelings about this. However different physic engines have different ways of doing things, but most of them share basic functionalities in the same way.

I've checked couple physics engines API's thoroughly and they are somewhat different from each other. Forcing them under same API would be akward idea in this particular case.

When pure Java physics engine project is started, I'd hope that it's based on something completely new and not neccesarily use ODE (or Odejava) as it's example for the interface.

Note that Odejava's Higher Level API is constructed simply against ODE only, bindings to other physics libraries have not been considered. I do not yet know if this is a good or bad thing, time will show.

Odejava's HL API is also quite far away from being finished, currently we try to get the job done with minimum resources. It would be possible to hide ODE away from most of the HL API and separate strictly ODE specific features to own layer, this might be good idea on the long run. This is an interesting idea that should be considered, thanks for pointing this out John!

Quote

The benefit would be the ability to focus on a higher level in an implementation independent manner.  Assuming that multiple physics engines are implemented, the user could choose the "best" for the task without having to change much code.

Perhaps we need to propose a JSR for this?  Java Physics Engine API, JPEA?


I'd like to have an general API for this one, but I for this area it might be quite a task. Engines share common ideas  like position, orientation, angular and linear velocities (add more here), but each have lot's of their unique features. At least general bindings to various renderers should be possible for various physics engines.

Perhaps very general definition would be possible and then use extensions based for each physics engine implementation which is being used. I assume this is something you mean?

Just food for tough..
Offline mlk

Junior Devvie




Muppet!


« Reply #20 - Posted 2004-04-06 22:32:55 »

Might it be possable to use something like Ephedra, C[++]2J or Java backend for GCC to do this? I know none of these are new, or that activly maintined, but it might be worth a shot.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #21 - Posted 2004-04-07 22:08:16 »

this looks like the best path IMHO.

currently we have to do a bit of work keeping odejava up to date with the C library (this is done automatically by swig).  Replacing that automated process with another one would be fine...

As ODE thankfully doesn't use GUI api's, a port of this nature seems feasable.

Certainly more maintanable than hand-porting it.

WIll.

Offline Jani Laakso

Junior Devvie




Do it with Java!


« Reply #22 - Posted 2004-04-08 04:52:04 »

Quote

currently we have to do a bit of work keeping odejava up to date with the C library (this is done automatically by swig).  Replacing that automated process with another one would be fine...


Using Swig is easy and I don't assume we get too big of trouble even if ODE changes a lot.

Swig leaves all native oddities to native side, it just builds an window to native side (simpler). So Swig only handles with API, not C internals. However, the path with native source=>Java source must be a lot more complex as here the task is not only API related, you are now trying to convert pure native source code into something else. I'd say there's bound to be many complex issues that need to be solved manually. The task sounds a bit too bold Smiley

The tools listed previously (native C => Java code) is a no go (IMHO), this is because ODE is full of specific native tweaks (e.g. lot's of pointer arithmetic, the source code is complex, native optimization decisions). Hence, nothing too great cannot be coming out from automatic conversion of such source code into Java.

Even if you get tool X to convert 80% of ODE into Java source code, then what? Probably you are missing the most complex parts of conversion, this is where the work lies. Building 80% ready physics engine with Java from ground up is not big task, it's the collision and other physics math parts that need lot's of work.

Quote

As ODE thankfully doesn't use GUI api's, a port of this nature seems feasable.

Certainly more maintanable than hand-porting it.


It all depends what the magic tool X spits out. I'd say it's hard to get it even to convert it fully, let alone to comprehend the converted Java source.

Last, I'll throw out an disclaimer.. All my comments are plain hunches, I haven't tryed tools like Ephedra myself and I do not know much about projects like Java backend for GCC.

I'd personally select creating Java physics engine from ground up. New design without any ties to existing projects. I'd use ODE perhaps as an example (algorithms, ideas), not much more.
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.

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

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

toopeicgaming1999 (14 views)
2014-11-26 15:20:08

SHC (27 views)
2014-11-25 12:00:59

SHC (25 views)
2014-11-25 11:53:45

Norakomi (31 views)
2014-11-25 11:26:43

Gibbo3771 (25 views)
2014-11-24 19:59:16

trollwarrior1 (38 views)
2014-11-22 12:13:56

xFryIx (77 views)
2014-11-13 12:34:49

digdugdiggy (55 views)
2014-11-12 21:11:50
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!