Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 8
  ignore  |  Print  
  Pure Java Port of ODE - planning/feasibility  (Read 41612 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2005-09-28 04:06:13 »

Is this feasibible?  Who's with us on this project?

How are we going to tackle this task?  Each volunteer to port certain files/sections?  What are the overall design implications?

Should we create a new Java.net project to manage the port (probably not a bad idea)?  What name?  "pureode" or something?  Are there any other resources we need?  The Odejava.org website/wiki is available for use.

Should we appoint a single manager for the project?  BlueSky are you interested in that role?

The objective as I see it is to do a 1:1 Java port of the ODE sources such that we can sub-out the native interface of Odejava and sub-in the java one.  Current and future changes to the functionality or areas where the code is for some reason quite different (so much so that you can't recognise the 1:1 relationship) should be well documented I believe.

Will.

Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #1 - Posted 2005-09-28 06:07:04 »

I'm used to porting C to java code (I have done so professionally on two projects in the past) but I'm not sure yet I can commit to this porting.

In a week or two I should have more visibility on my schedule (currently working on my own software renderer) and if I can help, I will.

Overall I think it's a good idea if  we manage to avoid too many objects instantiation (or keep them short lived). At least it doesn't require full understanding of physics...

I'd vote for a  java.net project (or an extension/plug-in of odejava ?).

Lilian

Offline Bombadil

Senior Member





« Reply #2 - Posted 2005-09-28 06:31:20 »

Great idea.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




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


« Reply #3 - Posted 2005-09-28 13:54:04 »

Is this feasibible?
Nothing's impossible.. But from what I heard about ODE code, it will be very difficult..

Quote
Who's with us on this project?
Talking of myself, I'm not sure if it's better :
 - To port ODE
 - To make a proper binding of Newton Dynamics or to port it
I'd wish that ODE was OO..

Quote
How are we going to tackle this task?  Each volunteer to port certain files/sections?  What are the overall design implications?
I should look at how the code is organized before answering that question.

Quote
Should we create a new Java.net project to manage the port (probably not a bad idea)?  What name?  "pureode" or something?  Are there any other resources we need?  The Odejava.org website/wiki is available for use.
If it's a good idea, yes we should create a new Java.net project. I propose the name : JODE or JDE (standing for Java Dynamics Engine, assuming when a project name has Java in it, it's open-source..)

Quote
Should we appoint a single manager for the project?  BlueSky are you interested in that role?
I can't say right now. If it's a good idea why not..

Quote
The objective as I see it is to do a 1:1 Java port of the ODE sources such that we can sub-out the native interface of Odejava and sub-in the java one.  Current and future changes to the functionality or areas where the code is for some reason quite different (so much so that you can't recognise the 1:1 relationship) should be well documented I believe.
IMHO, it's a pretty reasonable way to do that. But maybe later we can completely throw out the non-OO design. Isn't it possible to put ported Java code into actual ODEJava OO classes instead of interfacing as it's made actually ?

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




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


« Reply #4 - Posted 2005-09-28 20:40:50 »


Quote
The objective as I see it is to do a 1:1 Java port of the ODE sources such that we can sub-out the native interface of Odejava and sub-in the java one.  Current and future changes to the functionality or areas where the code is for some reason quite different (so much so that you can't recognise the 1:1 relationship) should be well documented I believe.
IMHO, it's a pretty reasonable way to do that. But maybe later we can completely throw out the non-OO design. Isn't it possible to put ported Java code into actual ODEJava OO classes instead of interfacing as it's made actually ?

+ the physics would stay the same, so no argument like "yeah, but we don't understand the physics, so we can't do that..." In Odejava there is soch much effort spend on making a good OO interface for the non OO ODE, so it would be performance throw-out to make it non OO, so we can use all the overhead of having extra classes that map these.  Roll Eyes
If we port it I'd say we should try to make it OO right a way, because everything else makes it only less readable and much more error addicting.
just my 2 cents...

Arne

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

JGO Coder




Where's the Kaboom?


« Reply #5 - Posted 2005-09-29 00:42:18 »

The other optionis to simplement the public (non-OO) interface to ODE, but where possible ignore the C implementation entirely and jsut do what is right for Java.

Since OdeJava already has an OO layer that is implemented via the C-style ODE bindings it makes sense to use the OO work that was already done.  Then if needed you can gradually blur the line between the original ODE API and the OO API (possibly with significant performance benefits?) until it really is just a pure OO physics framework..

Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #6 - Posted 2005-09-29 08:38:44 »

I would personally like to drop ODE all together and get the community to make our own physics engine. There are alot of papers out there that describe, in glorious detail, how to make a 3D physics engine.

Physics does involve alot of maths, but its good maths, the concepts are more difficult to absorb. Thats just my opinion...

But if you are insisting to make a complete ODE port, i'l maybe, possibly, help out a little bit as a contributor, but definetly not as a developer as I already have alot on my plate. But you need to start now, because the more people that voice in with their views on how to go about this, the more difficult it is for the project to satisfy more people.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #7 - Posted 2005-09-29 15:41:12 »

Well alot of ODE is object orientated when you look at the source. They just exposed it in a C library so it could be used for more things. When you read the C library you can see an OO structure to it.

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #8 - Posted 2005-09-29 15:43:40 »

Oh yeah and I think the name JDE is great

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #9 - Posted 2005-09-29 15:49:55 »

Yeah I will contribute 5 hours of my time (min!) a week on this project as a straightforward port. As mentioned before ODE does have an OO layer. Thus porting it all the way to the exposed layer will not mean that OO concepts won't be able to be used. Those parts that sit just behind the C layer will still of course be public and usable.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




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


« Reply #10 - Posted 2005-09-29 16:44:09 »

I would personally like to drop ODE all together and get the community to make our own physics engine. There are alot of papers out there that describe, in glorious detail, how to make a 3D physics engine.

Physics does involve alot of maths, but its good maths, the concepts are more difficult to absorb. Thats just my opinion...
I would be very interested if such an initiative would be started. But it seems to be a lot of work.
Because apart from native crashes due to JNI bindings (when using ODEJava), ODE suffer of some bugs :
 - Approximative (too much!) collision detection (ex : objects fall down through terrain trimeshes)
 - Non-deterministic & iterative simulation (Newton Dynamics has a deterministic solver)

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




Go Go Gadget Arms


« Reply #11 - Posted 2005-09-29 17:15:57 »

Its not a painful task to create a *simple* physics engine if you understand the basics, all you need to is integrate the acceleration of the object twice between 0 and the time difference to obtain the position, and using F=ma to relate force to acceleration. For rotation, integrate the torque twice to obtain omega which is the rotation angle between the local body axis and the world axis. Probably using a simple iterative solver to solve the differential equation.

All the above is nice for 2D, but for 3D, it gets harder for rotations as you have to deal with matrices or quaternions. But the basics stay the same.

I think if we build a solid foundation, we can add other things to it, like shock propogation from Kenny Ereleben's thesis, and we can use ODE as a reference instead of a base...

Thats just my opinion.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




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


« Reply #12 - Posted 2005-09-29 17:17:34 »

maybe we can fix the ODE bugs with our ODE port Wink Port it and make it better Smiley
Yeah, as darkprophet said, we really should start now else it will get buried next to alot of other unfinished projects.

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #13 - Posted 2005-09-29 17:23:52 »

ODE is advanced, its a mature product...so fixing things by our port is probably not likely....

Also, most visible bugs in ODE are due to the collision system (boxes going through mesh), and thats because its not exactly easy doing a trimesh-trimesh collider, otherwise, all the engines would have arbitrary trimesh's colliding with others with spectacular physics, although the inertia tensor might make it difficult if not nearly impossible to do that on a concave object...

Bluesky, do you know the difference between the two solvers for the differential equations imposed by the simulation? I tried googling for it, but couldn't find anything...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




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


« Reply #14 - Posted 2005-09-29 20:43:42 »

sure, but we could at least improve datastructures...something that goes lots easier with OO

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

JGO Coder




Where's the Kaboom?


« Reply #15 - Posted 2005-09-30 01:10:06 »

It probably makes sense to approach the port from a very high level.  Use proper OO to model the concepts in ODE (world, bodies, joints, etc...) then look to the ODE source to extract the math bits and apply the same equations to our OO data model.
Having not yet used ODE I really can't comment further..  I've got two game ideas brewing that need a good physics engine though Smiley

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #16 - Posted 2005-09-30 09:32:04 »

I agree its the collision system that is buggy, but ODE is made so that the collision system can be changed, hence a straight forward port would provide a working physics system quickly, and could be upgraded later easily with a  better collision system (I have one in mind).
The hard bit of the system is not the math, its how you solve the math. And ODEs quicksolve and stuff is pretty good.
I am all for a straight forward port, skipping uneccissary bits (like fastStep or whatever the outdated method was), becuase ODE does have a certain amount of design flexability built in. 

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

JGO Coder


Projects: 2


Fire at will


« Reply #17 - Posted 2005-09-30 10:13:49 »

Interesting points - ODE deos have an O-O layer under the hood which we can use.  It is quite a mature API, and I think a better starting point than starting with nothing.  t_larkworthy, your comments about the collision are interesting, it is certainly good that we can change the collision system -- certianly that is something that would be far easier when it's all in Java than messing around with the C and JNI wrapper.

So it sounds like we have t_larkworthy, BlueSky, myself and possibly darkprophet prepared to commit some time per week into this idea.  It certainly sounds like it is worth giving it a shot and seeing how we go.  There is no shame in deciding once we look deeper that it isn't feasable after all.

Who is the most qualified to lead us?  I would think whoever has the most C/C++ knowledge would be best.  I have a decent enough working knowledge, but my use of C has not really spread beyond university and toy projects unlike my Java so I don't believe this would be me.

Cheers,

Will.


Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #18 - Posted 2005-09-30 14:50:58 »

I know that this is not a priority for you guys right now, but what about the possibility of having the physics engine you're building detect the presence of a PPU and take advantage of it?  When one is not present, it just uses the CPU.

Jeffrey F. Elrod
Complexsive Systems
Offline arne

Senior Member




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


« Reply #19 - Posted 2005-09-30 17:31:17 »

I know that this is not a priority for you guys right now, but what about the possibility of having the physics engine you're building detect the presence of a PPU and take advantage of it?  When one is not present, it just uses the CPU.

If we want to do that one of us would have to have a PPU to test it :/ Nice idea though Wink

:: JOODE :: Xith3d :: OdeJava ::
Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #20 - Posted 2005-09-30 19:27:32 »

I know that this is not a priority for you guys right now, but what about the possibility of having the physics engine you're building detect the presence of a PPU and take advantage of it?  When one is not present, it just uses the CPU.

If we want to do that one of us would have to have a PPU to test it :/ Nice idea though Wink

Okay arne!  Smiley  That was kinda cute there, but my real question is the feasibility and would it be of any real value to do.

Jeffrey F. Elrod
Complexsive Systems
Offline arne

Senior Member




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


« Reply #21 - Posted 2005-09-30 20:15:28 »

If we are going to implement the use of PPU, we would first have to clear out, how such a PPU works and then we would have to acess it some way (JNI Sad ).

we could simply write the code with that idea in mind, so we can change that later on, when somebody needs it. Another advantage of having it directly in Java.

So my conlusion: "Ignore" that first and implement it later on.

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Member




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


« Reply #22 - Posted 2005-09-30 20:34:16 »

Is there a tool that generates an UML-diagram for the ODE source? Or has somebody created such a diagram? I think this would be a good idea for a starting point. I believe there's loads of stuff, we don't have to recode (e.g. Quat-multiplication), we could use javax.vecmath for that.

:: JOODE :: Xith3d :: OdeJava ::
Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #23 - Posted 2005-09-30 20:39:01 »

A UML diagram would be an excellent way to start.  There are some UML tools that reverse engineer the code to a UML diagram.  But I don't know about C++.  IMHO C++ is not really a true OOPL anyway.  Shocked

Jeffrey F. Elrod
Complexsive Systems
Offline arne

Senior Member




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


« Reply #24 - Posted 2005-09-30 22:00:04 »

made one Smiley


:: JOODE :: Xith3d :: OdeJava ::
Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #25 - Posted 2005-09-30 22:14:24 »

Which tool did you use?

Jeffrey F. Elrod
Complexsive Systems
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #26 - Posted 2005-09-30 22:15:19 »

Damn you arne! I was just doing one before you posted that! Great stuff though, this needs to be analysed to see how it converts pointers and things.

What did you use? I was going for boUML. Can that model be transported into a JAVA freindly UML tool? Can you generate java stubs for that?
Can you supply a list of the C stubs it missed out (so we can create a static class with stubs)


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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #27 - Posted 2005-10-01 00:34:20 »

Wow! BoUML is the new greatest open source UML tool on the market! It is very much like rational rose. Its a bit quirky still but it seems like its pretty powerful. I have a reversed engineered a very powerful c++ model. I think the class image is too big to fit on these forums. It is 360Kb.
The UML tool has used UML stereotypes to preserve the typedef struct and even template declarations. It has basically managed to preserve so much information its amazing. There are about 70 class like concepts it has managed to preserve after reverse engineering.


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

Senior Member




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


« Reply #28 - Posted 2005-10-01 09:56:39 »

Your UML diagram seems to be corrupted.

I used umbrello to generate mine.

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #29 - Posted 2005-10-01 13:07:31 »

Yeah. Its coz the image is too big to upload into the forums. I have only just arrived at my new university. I do get webspace so I will use that once I work out the finer details of using it.
Won't be till 2morrow though.

On another note, I don't think we should worry about extra features such as PPU. If anything we should be discussing what features we do not need.

My list at the moment is:-
Trimeshes -- they don't work
FastStep -- it is depricated
QuadTreeSpace -- its a 2D datastructure, should be an OctTree if anything

Then I think we should talk about priorities.
The first thing to do is a skeleton implementation so we can actually run something.

Geometries: Sphere, then box and maybe nothing else
Space: SimpleSpace maybe HashSpace.
Joints: Slider, Hinge (becuase with those two you can more or less create any of the other types, one is for a linear degree of freedom and the other is rotational)
For the world the normal step should be implemented first. Quickstep can come later.

Obviously there are alot of gubbins that need to go under all that. When I look at the ODE code I see alot of things that have JAVA equivelents like the dStack, and dMatrix etc. I would suggest that we don't do a straight forward port of their implementations, but do not try to substrituite either. We should go for the adapter pattern and recornstruct the equivelent methods that  then delage to the JAVA version. 

I really really like the BOUML tool. I think it will be able to provide a pretty comprehensive java skeleton to be filled in. UML lovers should check it out, I have used lots of open source UML tool like Argo now Poisiden, Eclipse etc and commercial ones like rational rose, Together. Never used Umbrella. Anyway this tool is really powerful despite being pretty new. Its a bit of a UI nightmare to control, but its more than made up for in power.

So these are my thoughts at the moment. They are just thoughts. Please feel free to criticize my ideas and put forward alternative ideas.


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] 2 3 ... 8
  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.

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

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

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

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

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

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

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

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

BurntPizza (42 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
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!