Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
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  
  JOODE love  (Read 4583 times)
0 Members and 1 Guest are viewing this topic.
Offline neveragain

Junior Newbie





« Posted 2007-01-11 17:09:57 »

Well, I've been trying off and on to get java-gaming.org to allow me to log in, and I still haven't gotten any emails. Obviously I have gotten around it, but as you see I used a different id.

Anyway, I have a large patch for JOODE that increases performance and reliability (and making it easier to port directly from ODEJava), but I'm not sure how it should be submitted.

The patch is roughly 1400 lines worth of changed/added/deleted code.

I also have a question: why isn't JOODE using javax.vecmath, instead of what appears to essentially be WildMagic geometric classes?

This is biggeruniverse, but I can't get the forum to email me my password!
Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #1 - Posted 2007-01-12 17:35:01 »

Ok, ChrisM got my account straightened out. I'm back to my old self!
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #2 - Posted 2007-01-15 07:22:58 »

Maybe you want to talk to Amos Wenger. Even if he doesn't have admin privs and won't be able to give you dev rights. He has dev rights on the JOODE project and could commit your work. I personally would love to see your stuff committed.

Marvin
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 2007-01-15 17:02:46 »

As Marvin said, I'd also love to see your stuff committed.
The thing is regular devs seems to have disappeared and I don't know... well I don't know what they think of it.
Whatever, just send it to me (check your PMs)

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

Senior Newbie




That's just peanuts to space.


« Reply #4 - Posted 2007-01-16 11:31:43 »

Well, and so I have.

Here is a list of what I have changed:
  • Most temporary calculation variables (Vector3, Matrix3/4, Quat4) are now class-level static, for much nicer memory usage
  • static-static collisions are ignored
  • dxBodyGravity flag for toggling effect of gravity on a body
  • dxBodyDisabled is honored
  • DOS CR/LFs removed
  • Added many "convention" methods to Body to make porting from ODEJava easier
  • You can now cap the number of interactions per step (World.maxStepInteractions)
  • Overall per-step memory usage is significantly reduced
  • Sphere colliders now jitter the contact so that spheres dropped straight down onto flat objects to not bounce up and down there forever.
  • Contact is now a ContactGeom, thus merging functionality (contact.geom. becomes contact.)
  • The basis class for TriMesh is added
  • The net.java.dev.joode.test.CollisionManager now uses simple JointContact caching

Here's my TODO list, if people voice an interest in me making further changes:
  • Finish staticising temp variables
  • Migrate to javax.vecmath
  • TriMesh collisions

On the point of using static rather than temporary variables, I realize a debate could rage forever. I've found it useful at other times in maintaining light overhead, and reducing the necessity of GC cycles. For me, a physics engine should be as memory-transparent as possible.
Offline Amos Wenger

Senior Member




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


« Reply #5 - Posted 2007-01-16 14:53:39 »

the fact that static-static collisions are ignored is most annoying for me... first I thought it was a bug, then I found out why in the code and I saw your post.

The issue is, I'm using JOODE Geoms without Bodies but I *want* collision detection because they are dynamic in my world (say, I use JOODE collision detection but not physic simulation here).

So this should be adjustable somewhere.

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

Senior Newbie




That's just peanuts to space.


« Reply #6 - Posted 2007-01-16 16:28:59 »

the fact that static-static collisions are ignored is most annoying for me... first I thought it was a bug, then I found out why in the code and I saw your post.

The issue is, I'm using JOODE Geoms without Bodies but I *want* collision detection because they are dynamic in my world (say, I use JOODE collision detection but not physic simulation here).

So this should be adjustable somewhere.

Hmm. Ok. Would adding something like World.ignoreStaticContacts (default value true) suffice?
Offline Amos Wenger

Senior Member




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


« Reply #7 - Posted 2007-01-16 17:08:06 »

For now I use the (previously unused) skip parameter.
When 0, it does static-collisions. When 1, it skips static-static collisions.

"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 Amos Wenger

Senior Member




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


« Reply #8 - Posted 2007-01-16 17:08:42 »

Sphere/Box collider should be fixed : depending on which side the sphere collide with the box, it goes through it..
biggeruniverse, if you have any idea...

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

Senior Newbie




That's just peanuts to space.


« Reply #9 - Posted 2007-01-16 17:53:44 »

I'll work on it.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #10 - Posted 2007-01-18 06:02:09 »

Probably the quickest thing to do is make your step size half as big, and step the simulation twice per frame. That should help a lot of cases, though of course it will not help when the sphere still ends up within the box on the far side from where it entered. The problem is that the collider has no idea about the velocity of the body, and therefore cannot do tests a priori.
Offline Amos Wenger

Senior Member




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


« Reply #11 - Posted 2007-01-18 16:48:14 »

The problem is that the collider has no idea about the velocity of the body, and therefore cannot do tests a priori.
Do the collider really need to know something about velocity to detect collisions correctly ?

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

Senior Newbie




That's just peanuts to space.


« Reply #12 - Posted 2007-01-18 18:48:39 »

No, it can detect the collisions, but it won't know how to "fix" them correctly. If it sees that a sphere is inside a box, all it knows is exactly that. It doesn't know where the sphere or box came from, or where they are going, hence how can it know which side of the box the sphere entered from?

EDIT: I wish JOODE devs were around to talk to about this. Sad
Offline apope

Junior Newbie





« Reply #13 - Posted 2007-01-18 23:28:09 »

biggeruniverse,

I've just completed basic JOODE support for finding trimesh/trimesh collisions, and was about to commit the changes when I ran into your commits of two days ago. I'll merge with your changes before committing. One conflict: we've both defined a TriMesh class.

The trimesh implementation I've done is based on GIMPACT, which is available under a BSD-like license. So far, the implementation maintains per-triangle and per-mesh AABBs, finds tri/tri collision candidates by testing these, and goes on to detect any contact points between tris. Yet to be ported are GIMPACT's sort-based AABB colliding and merging of nearby contact points. I've used javax.vecmath for point and vector representations, and created unit tests.

Please let me know what plans you have for the TriMesh class you've already committed.

   Art
Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #14 - Posted 2007-01-19 03:09:59 »

Go ahead get rid of mine- it's a stub. I like that you used javax.vecmath, I've been planning to convert all of JOODE to using it. I found from traces that the slowest part of the collider was lookups of indices in the Matrix3/4 classes.

Anyway, I'm excited to see some trimesh collisions!
Offline Amos Wenger

Senior Member




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


« Reply #15 - Posted 2007-01-19 14:53:26 »

Anyway, I'm excited to see some trimesh collisions!
SURE ! @apope : great !

@biggeruniverse : Yeah I see what you mean with collision detection and how to "solve" a collision. But the step size is really small and it should be able to know from which side it comes !

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

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #16 - Posted 2007-01-19 16:10:33 »

Hello. Phew I have had quite a hectic last 6 months. Anyway, I have passed my masters now and am moving onto my PhD. It is in reconfigurable robotics research and it requires physics simulation which was rather my motivation for JOODE in the first place.
A. Pope contacted me over christmas regarding JOODE submissions, he now also has developer access.
Amos, sorry I have been away so long. I did change your privalidges to Admin, you should be able to do anything I can.
Not sure when when I will be committing code into JOODE again. At the moment I am doing probabalistic stuff and I need that sorted before I get into simulation. It is looking like I am going to have to implement some non-linear constrained optimization algorithms, there may be some use in JOODE for that but I am not sure. Anyway, alot of reading to do.....

Speak to you all soon

Tom

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 #17 - Posted 2007-01-19 16:14:12 »

Oh sorry Amos, you don't have admin privalidges....
Anyway I am about again 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 Amos Wenger

Senior Member




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


« Reply #18 - Posted 2007-01-20 13:51:45 »

Oh sorry Amos, you don't have admin privalidges....
Anyway I am about again now.
*So* cool to hear about you again !

Welcome back  Cool (and thanks for admin access, we never know if you're unavailable again for some months..)

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

Senior Newbie




Hopefully this works out.


« Reply #19 - Posted 2007-01-21 17:45:23 »

I recently downloaded the JOODE source from sourceforge.net (using SVN).  I understand this to be the active development repo.

I integrated it into a game framework I use with little problem.  I ran an existing game with a couple of physics Body(s) added with the Java Interactive Profiler profiling the code.  I noticed that getX() and getY() for Vector3 were eating up lots of CPU time due to the vast number of calls to them.  I removed the getters and setters that simply access m[] underneath and replaced those calls with direct access to m[].  This significantly improved performance and thus the framerate.  However, it is key to note that the I updated the game framework I am using refers to the Body (now .pos.m[]) to determine some things (e.g. whether or not to render in a view).  So, the framework adds quite a few more calls to these getters than you would normally see in JOODE alone.

I wanted to mention this to see if this is something a developer for the project can refactor and checkin in SVN.  I understand if its not a big deal for others, just an observation and something I had to change to keep using JOODE and it would be nice if it were checked in the repo too so I can keep up with the updates.
Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #20 - Posted 2007-01-22 01:43:29 »

Actually, what I had planned (not sure if this is concensus) is to replace the internal geometry classes with javax.vecmath classes. This will take a little time to get changed and tested.
Offline irrisor

Junior Member





« Reply #21 - Posted 2007-01-22 08:07:26 »

shasheppard, did you use a new JDK? (e.g. 1.5 or 1.6) It should do these optimization on it's own after a high number of invocations. Additionally: did you compare the framerates without profiling enabled? (profiling instrumentation/listener really distorts the measurements)
Offline Amos Wenger

Senior Member




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


« Reply #22 - Posted 2007-01-22 18:27:45 »

There are compile errors with a "RadixSortedSomething" not found... anybody knows what is 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 biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #23 - Posted 2007-01-22 18:53:42 »

I'm not seeing any compile errors. Can you post some compiler output, or line numbers or something?

EDIT: looks like Art already uploaded it.
Offline apope

Junior Newbie





« Reply #24 - Posted 2007-01-22 19:36:36 »

I've committed code for representing trimeshes and finding trimesh/trimesh collisions based on code from GIMPACT (used under a BSD-like license).

The trimesh representation uses vecmath's Point3f's for vertices, indices to identify the vertices in each triangle, an AABB for each triangle, and Geom's usual AABB for the entire mesh. Trimesh/trimesh collision detection, which is invoked once whole-Geom AABBs have been found to intersect, first finds intersections among per-triangle AABBs, then among their associated triangles. To find intersections among per-triangle AABBs, GIMPACT uses brute force testing of all possible pairs for small numbers of triangles, and sorting for large numbers; I've implemented only the brute-force search.

I've included a trimesh/trimesh collision test, plus unit tests for some low-level geometric operations.

Note that other types of collisions (trimesh/plane, trimesh/box, trimesh/sphere, etc.) are not yet implemented; only trimesh/trimesh collisions are detected.

GIMPACT and my port of it both suffer from a problem that occurs particularly often among trimeshes with sharp (i.e., acute-angled) creases. Such geometry can allow one triangle to approach another one from the back and then, with only a small change in position, intersect it with one triangle still lying larger behind the other. This is then reported as a deep contact yielding a large repulsive force.

Btw, Vector3.normalize() is a bit odd in that it doesn't normalize the vector in the usual sense (i.e., leaving it with unit length). I've committed a comment noting this, but haven't changed it. Perhaps someone ought to look at it.

   Art Pope

P.S. RadixSortToken was a late checkin, but should be there now, too.
Offline shasheppard

Senior Newbie




Hopefully this works out.


« Reply #25 - Posted 2007-01-23 03:32:37 »

irrisor,

Yeah. I am using Java 1.6.  I ran a few tests with JIP turned off, and I experienced some very similar results (actually, the difference was unnoticeable almost).  After going back and removing all the calls to getX() and getY() from Vector3, I replaced the JIP settings to on.  I then noticed that Matrix.get() is called several hundred thousand times in a short (<30 seconds) test run.  The overall time spent in Matrix.get() was slightly higher (other times slightly lower) than what was spent in the rendering/drawing methods.

I do not want to go through and the types of changes required to remove references to this method.  I am beginning to feel like there is something wrong with the way I am doing business, because why would I be the only one making these types of statements?

The only thing I am doing that I do not gather others are doing is using a home-grown game framework in pure Java.  So, the sad fact may be that the framework is an inefficient hog, which brings out the JOODE shortcomings (well, perhaps they're not really shortcomings).
Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #26 - Posted 2007-01-23 08:29:43 »

Actually, you are on the right track. I'm working on an entire fix for this but, as I'm sure you have seen, it will take time. There will also be time to test, and verify that the conversion has happened correctly. It is being worked on.
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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (45 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (33 views)
2014-09-21 01:30:30

moogie (41 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
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!