Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 4 5 [6] 7 8
  ignore  |  Print  
  Pure Java Port of ODE - planning/feasibility  (Read 43235 times)
0 Members and 1 Guest are viewing this topic.
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #150 - Posted 2005-11-08 19:12:10 »

Yes. Jars should be binary. sorry, I was being sloppy when I first put everything in the repository. It should be ok now.
 

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

Junior Devvie




Java games rock!


« Reply #151 - Posted 2005-11-08 21:25:21 »

Regarding the error handling in Mass:

The way the original code is designed, it needs to check a post condition to ensure that the computed matrix is valid.  Because this is a post condition rather than a more typical error, it makes sense to check it using an assert statement rather than throw an exception. 

Enums are very similar to classes.  When you write

<code>
enum MyEnum { FIRST, SECOND, THIRD}
</code>

You're pretty much creating three classes called FIRST, SECOND and THIRD.  You can then compare these against each other using the == and != operators, or even as arguments to a switch() statement.  They're actually pretty simple.  You can read more about enums here:

http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/index.html


I was chatting with t_larkworthy over email last night, and I think both of us would really rather program in Java 5.  Java 5 has lots of nice features (like generics and foreach loops) that make it easier and much more clear to code.  The new additions to 1.5 aren't that difficult to learn.  If you read thorugh the page that I posted, that will give you a pretty good introduction to all the new features.

Also, does it makes sense to develop for 1.4?  In a year's time, Java 6 will be released, and 1.4 will be ancient history.  I think it makes more sense to program to the current standard.
Offline arne

Senior Devvie




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


« Reply #152 - Posted 2005-11-08 21:59:29 »

ok 1.5 then

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #153 - Posted 2005-11-09 01:01:26 »

OK if we are going 1.5 then a refactor is needed on the pointer types. I will do this at a later stage.
I am investigating arbitary trimesh collisions but it is not that simple. OBB papers I have read are fairly straight forward to implement but do not provide a measure of penitration or surface normal required for the collision system to work. Reading up on working that out is pretty heavy. Guass maps etc. all-in-all fairly horrific.
I am wondering if we can cheat and use the change in relative positions of the two colliding obects. That could then be used for an estimate for penetration depth and surface normal. The contact point also needs to be estimated ... hmmmm. I cannot think of how to do that. Maybe I am too tired (1a.m.), I will go home and rest....

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

Junior Devvie




Java games rock!


« Reply #154 - Posted 2005-11-09 02:33:15 »

Isn't it a simple matter of calculating the distance from the penetrated point to the point of colliision on the surface?  I remeber implementing an engine a while ago, and solved it by doing something like this.

Also, how easy is it to simply copy the existing ODE code?  Or is this something better rewritten?
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #155 - Posted 2005-11-09 13:00:43 »

The OBB tree calculations as they stand don't tell you the penetration point. The existing ODE code doesn't work (for arbitary trimeshes). I have realised this morning that last nights guestimate won't work if more than one body is in contact at the same time (as is in the case when things are stacked on top of each other and under the force of gravity, a very common situation).

So an OBB tree will tell you very fast when there is a collision but does not tell you much about the nature of the collision. Minkowski sums can tell you the penetration depth and other info bu take something like O(n^6) to calculate (with a good implementation). For convex hullks you can calculate the minkowski sums in O(n^2) using clever guass map manipulations which are hard to understand. You can get better than that but with even more cryptic sums.



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

Senior Devvie


Projects: 1


Java games will probably rock someday...


« Reply #156 - Posted 2005-11-09 13:12:27 »

Couldn't you keep 1.4 compatibility ?

At least on Mac OS, most users are still using this JRE, and as a pure java physics lib would be a great gift for applet development, tt's too sad (and alienating) to force users into 1.5.

My 2c (If you go this way, I'll try to backport it to 1.4).

Lilian

Offline arne

Senior Devvie




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


« Reply #157 - Posted 2005-11-09 15:13:07 »

so what now? 1.5 or 1.4 ? I'll start a poll and then we'll see ( I hope you haven't changed major parts to 1.5 yet)

About the trimesh business: we sure need TreeMeshes, but I think trimeshes can also very good be replaced by other things: e.g. Terrain, ConvexHulls or simply a triHull, where you specify where the inside and where the outside is. These will maybe also be very hard to implement, but they could run with faster speed. Normal trimeshes would then only have to be used in cases, where there is no replacement, making the problem not that urgent.

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #158 - Posted 2005-11-09 15:24:11 »

I would go with 1.5.  You have to think about the target market for the API.  I don't think applets make a significant part of that market, and that is really only place where you would probably want to remain backward compatible.

Mac OS X has had Java 5 for download for some time now, and according to Apple engineers on their forums, Java 5 will become an automatic OS upgrade as part of the standard "Software Update" feature of the OS reasonably soon.


I suppose you could also have a build target in your ant script that uses retroweaver to make a 1.4 compatible version too.

Offline cylab

JGO Ninja


Medals: 55



« Reply #159 - Posted 2005-11-09 16:10:43 »

Good God!!! That (http://retroweaver.sourceforge.net/) seems to be the perfect solution, not only for this project ;-) Thanks swpalmer! I didn't know..

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline t_larkworthy

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #160 - Posted 2005-11-09 16:36:38 »

OK. 1.5 ! hurrah!

I actually wasn't going to aim for trimeshes quite yet anyway. Convex polyhedra first. We could stitch a load of convex polyhydra together with fixed joints to form arbitary shapes. anyway. I am thinkning I am getting there now...

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

Junior Devvie





« Reply #161 - Posted 2005-11-09 18:43:26 »

OK. 1.5 ! hurrah!

I actually wasn't going to aim for trimeshes quite yet anyway. Convex polyhedra first. We could stitch a load of convex polyhydra together with fixed joints to form arbitary shapes. anyway. I am thinkning I am getting there now...

what is better anyway, multiple bodies tied together with fixed joints or a single body with multiple geometries encapsulated in GeomTransforms?
Offline arne

Senior Devvie




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


« Reply #162 - Posted 2005-11-09 20:38:26 »

OK. 1.5 ! hurrah!

I actually wasn't going to aim for trimeshes quite yet anyway. Convex polyhedra first. We could stitch a load of convex polyhydra together with fixed joints to form arbitary shapes. anyway. I am thinkning I am getting there now...

what is better anyway, multiple bodies tied together with fixed joints or a single body with multiple geometries encapsulated in GeomTransforms?
In current ODEJava the second version is better - but lets see how it'll be with JOODE.

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

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #163 - Posted 2005-11-10 13:38:48 »

Oh yeah. Of course. Multiple geometries on one body. I am not really worrying about the details yet...

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 Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #164 - Posted 2005-11-11 16:54:03 »

Would developers like me to use the requests-bug-assignment-thingamyjig and assign work? I think it would help greatly with making sure people don't attack the same problem, and also be a great way for people to see what needs to be done. The drawbacks are it is a bit heavy weight and the pages take a long time to load.
There is no point me spending ages filling it up with tasks if people are not going to spend the time crossing out the tasks as they are done. I personally think it would be a good idea.
Things that I think need doing next currently are:
Box-Box collisions
Slider joint, Ball joint then hinge joint (these should be very easy to fill in, also make sure each joint is not requesting feedback by default)
Refactor out the vtable nonsense in the joints (not urgent, medium difficulty)
Quickstep (big task!)
FastLCP(bigger task, also requires refactoring the common interface between it and SlowLCP, very useful to do becuase only the FastLCP algorithm can provides joint feedback functionality)

We need a test that also destroys bodies and geometries becuase that code is untested at the moment.

I am working on convex trimesh collisions. I have the outline of the implementation sorted now. I know how to do the problem and I have just started implementing it. I think I will manage approximatly O(n^2) where n is the number of vertices involved. I have read papers that can do it in almost linear time but they are *way* complicated.

I am away this weekend.
 
 

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 Devvie




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


« Reply #165 - Posted 2005-11-11 19:41:36 »

Good idea, I'll fill in tasks now...
and then I'll see, what I'll tackle next.

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

Senior Devvie




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


« Reply #166 - Posted 2005-11-11 21:57:33 »

I'm currently trying to implement Box to Box collisions and I have to implement a collision specific function that's probably also needed by other Collisions (I don't know), I've now implemented it into Colliders, but it actually does math and should from that context belong to MathUtils. So: should I keep it in Colliders, or should I move it to MathUtils?

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Devvie




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


« Reply #167 - Posted 2005-11-12 12:44:36 »

Here's just one thing we could do better than ODE.
May we do something like :
 - Body can "move/control" either a Geom, either a GeomGroup
 - GeomGroup is a class and not an ugly system like in ODE
It's a minor change, but it seems a way more natural to me.

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




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


« Reply #168 - Posted 2005-11-12 13:23:05 »

Can you explain it a bit more, I haven't understood it yet, what you're talking about.

Are you saying, that it should be more build like a scenegraph? Like the position of the Geom doesn't have to be the position of the Body, it can e.g. be translated like with GeomTransform relative to the BodyS origin, and you can have GeomGroupS that contain different GeomS?
Should GeomGroup extend Geom?

:: JOODE :: Xith3d :: OdeJava ::
Offline kitfox

Junior Devvie




Java games rock!


« Reply #169 - Posted 2005-11-12 17:51:12 »

I think posting a TODO list would be quite useful.  I wasn't sure where to go next after working with the Mass class. 

I'm not sure when I'll have time to work on it again, but I'll take another look when I can.
Offline arne

Senior Devvie




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


« Reply #170 - Posted 2005-11-12 20:07:41 »

I made one: https://sourceforge.net/tracker/?atid=782659&group_id=151965&func=browse
I think this is the best place, because then it's easy to extend.

I tried to do BoxBoxCollisions, but it doesn't work yet (I hate pointers, grr...) I'll commit the code anyways, maybe someone does find the error. The error seems to be in the new by me implemented Colliders.intersectRectQuad

:: JOODE :: Xith3d :: OdeJava ::
Offline Amos Wenger

Senior Devvie




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


« Reply #171 - Posted 2005-11-13 15:56:34 »

Can you explain it a bit more, I haven't understood it yet, what you're talking about.

Are you saying, that it should be more build like a scenegraph? Like the position of the Geom doesn't have to be the position of the Body, it can e.g. be translated like with GeomTransform relative to the BodyS origin, and you can have GeomGroupS that contain different GeomS?
Should GeomGroup extend Geom?

Yes, a bit like a scenegraph, but maybe GeomTransform isn't necessary, if we have static joint.. I don't think GeomGroup should extends Geom

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




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


« Reply #172 - Posted 2005-11-14 15:24:06 »

but how should static joint be implemented, so it doesn't show the behavior we've now got in ODEJava?

We wouldn't be able to use the joint system that's currently used by odejava (simply applying forces to correct the joint), because then a change of one geom of such a static joint will only influence the other geom in the next step. I believe this is different with GeomTransforms - making GeomTransforms better.

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

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #173 - Posted 2005-11-15 23:12:15 »

I do not really understand this debate.

By static joints do you mean joints that can be attached to other joints so that you can link one body to another body via a chain of multiple joints?

Geometry has nothing to do with the joint system.

Geoms are classes at the moment.

I was thinking myself when I have used ODE that GeomTransform is a bit of a naff way of dealing with indirection. I am not sure how much work it would be to do it properly and whether there would be all that much benifits.

Quote
Body can "move/control" either a Geom, either a GeomGroup
So you want the geom transforms to be mallable? I think that is a no brainer to implement, and would be very useful functionality.
As for GeomGroups I don't think it is really fundamental functionality. If we made GeomTransforms changeable then it would not take a user much to alter multiple geomTransforms themselves in one go, to me the functionality looks like a convenience method. Which is no bad thing, but I don't think convinience should be catered for until the API is stabalized.

I will add GeomTransforms to the todo list...

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 Devvie




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


« Reply #174 - Posted 2005-11-16 10:16:50 »

Quote
I do not really understand this debate.

By static joints do you mean joints that can be attached to other joints so that you can link one body to another body via a chain of multiple joints?

Geometry has nothing to do with the joint system.

I think we were talking here about JointFixed. So it would be an alternate way of dealing with multiple Geoms inside one Body. And then it has to do with Geometry.


Quote
So you want the geom transforms to be mallable? I think that is a no brainer to implement, and would be very useful functionality.
Now I don't understand that.

Quote
As for GeomGroups I don't think it is really fundamental functionality. If we made GeomTransforms changeable then it would not take a user much to alter multiple geomTransforms themselves in one go, to me the functionality looks like a convenience method. Which is no bad thing, but I don't think convinience should be catered for until the API is stabalized.
You want to change the Body during Runtime? Is that wise? Joints should be used for such things!

But to get over the GeomTransformBusiness - until now it's something like this: The Geom's position is the same like the Body's position. Why don't we save the Geom's position relative to the Body and if this relative position and rotation is inequal to (0|0|0) and Matrix.Identity we deal with it as if there were a GeomTransform.

We would then ofcourse have to change all the direct acessing of the Geom's position and rotation.

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

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #175 - Posted 2005-11-16 13:58:45 »

Quote
I think we were talking here about JointFixed. So it would be an alternate way of dealing with multiple Geoms inside one Body. And then it has to do with Geometry.
Joint fixed is implemented in ODE and ODEjava (and it works in ODEjava), it allows bodies to be fixed relative to one another. If a set of geoms are attached to one body then they are automatically fixed relative to one another. Joints have nothing to do with geometry.

Quote
Quote
So you want the geom transforms to be mallable? I think that is a no brainer to implement, and would be very useful functionality.
Now I don't understand that.
That was in response to:-
Quote
- Body can "move/control" either a Geom, either a GeomGroup
At the moment you can set a Geoms position relative to a body using a GeomTransform, but I am not sure you can change it once it is up and running. MagicSpark seems to want to be able to move a geom relative to a body a sim time.

Quote
But to get over the GeomTransformBusiness - until now it's something like this: The Geom's position is the same like the Body's position. Why don't we save the Geom's position relative to the Body and if this relative position and rotation is inequal to (0|0|0) and Matrix.Identity we deal with it as if there were a GeomTransform.

that is fine for the case when geoms are attached to bodies, but what about when geoms are static?



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 Devvie




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


« Reply #176 - Posted 2005-11-16 14:58:14 »

Quote
I think we were talking here about JointFixed. So it would be an alternate way of dealing with multiple Geoms inside one Body. And then it has to do with Geometry.
Joint fixed is implemented in ODE and ODEjava (and it works in ODEjava), it allows bodies to be fixed relative to one another. If a set of geoms are attached to one body then they are automatically fixed relative to one another. Joints have nothing to do with geometry.
Yes. It works, but how well - wasn't there once a topic, where Bodies attached with fixed joints started to oscilate. See http://www.java-gaming.org/forums/index.php?topic=9822.0
Quote
Quote
But to get over the GeomTransformBusiness - until now it's something like this: The Geom's position is the same like the Body's position. Why don't we save the Geom's position relative to the Body and if this relative position and rotation is inequal to (0|0|0) and Matrix.Identity we deal with it as if there were a GeomTransform.

that is fine for the case when geoms are attached to bodies, but what about when geoms are static?
Then you can set the position directly for the geom. I've never had issues with that.

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

Senior Devvie


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #177 - Posted 2005-11-17 11:15:10 »

Quote
Yes. It works, but how well - wasn't there once a topic, where Bodies attached with fixed joints started to oscilate. See http://www.java-gaming.org/forums/index.php?topic=9822.0

Well I have had situations like that in my simulation. Its normally a  matter of scaling the mass or fixing the joint at the right time or tons of other things. I have used fixed joints before quite well in my simulations. It is not advised becuase it takes extra  computation to enforce the joint integrety and gives more possibilities for the LCP algorithm to fail. But JointFixed do have their uses in enforcing temporary constraints on bodies. To do this without JointFixed would be quite tricky. If two bodies are to be joined with a virtual jointFixed you would need to
1. record the positions of the bodies and their geoms
2. remove one body from simulation
3. adjust the remaining bodies mass by the removed mass (we can actually do that now with the new mass functions!)
4. moved the goems of the one body to the other (possibly having to create GeomTransforms to do so)

Then when you would want to release the body you would need to go back to the prerecorded situation. 
This is alot more complex when you imagine that this could happen multiple times and could be undone in any order. 

I spose the introduction of a CompositeBody might be the answer. If a Body is JointFixed to another body, create a CompositeBody from the two (that has 2 parts). If a Body is JointFixed to another CompositeBody  the add the Body to the Composites primatives etc.

Still.... you have all the Joints to deal with as well as the Geoms.




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

Senior Devvie




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


« Reply #178 - Posted 2005-11-17 17:52:14 »

I spose the introduction of a CompositeBody might be the answer. If a Body is JointFixed to another body, create a CompositeBody from the two (that has 2 parts). If a Body is JointFixed to another CompositeBody  the add the Body to the Composites primatives etc.

Still.... you have all the Joints to deal with as well as the Geoms.
This is what I wanted to introduce when I talked about "GeomGroup", but, err... it's a bit more logic to do "BodyGroup(s)", you're right (or CompositeBody if you want).

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




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


« Reply #179 - Posted 2005-11-17 17:55:47 »

Ahh now I understand Smiley

:: JOODE :: Xith3d :: OdeJava ::
Pages: 1 ... 4 5 [6] 7 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.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (58 views)
2014-11-29 21:32:03

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

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

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!