Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
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]
  ignore  |  Print  
  joode performance  (Read 2564 times)
0 Members and 1 Guest are viewing this topic.
Offline lhkbob

JGO Knight


Medals: 32



« Posted 2007-11-10 00:07:46 »

I decided to check back in on the progress of joode since my project is almost ready to begin using physics (ooh exciting!) and I ran the demos to see how well they performed.  On average I was only getting between 30-60 fps depending on the test.  When I was using odejava, I could easily get 200 objects at around 100 fps but now 20 objects crawls in comparison.

 I'm wondering if this performance decrease is a temporary bug, something that everyone has experienced, or a throttling caused by joode's coupling with xith.

As a side note, you have an incorrect svn access listed on one of your pages:

The correct one to use is:
 svn co https://joode.svn.sourceforge.net/svnroot/joode joode, which can be found  http://sourceforge.net/svn/?group_id=151965
but on the page: http://joode.sourceforge.net/download.html, it still says to use:
svn co https://svn.sourceforge.net/svnroot/joode joode

Offline lhkbob

JGO Knight


Medals: 32



« Reply #1 - Posted 2007-11-13 17:27:10 »

Is joode dead? Where are the developers with the generally timely responses?

Offline irrisor

Junior Member





« Reply #2 - Posted 2007-11-14 08:18:02 »

At least some of them can be found on xith.org, I believe.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #3 - Posted 2007-11-28 11:48:33 »

JOODE is asleep (from my perspective) while I write the "other" bits of code relating to my work. Expect a reserection at some point over 2008, but for now I can't really work on two big libraries.

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 lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2007-11-28 17:56:15 »

Good to know, since it's asleep, what else has to be done before you'd call it a finished project?

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #5 - Posted 2007-11-29 18:22:44 »

1. Well there is a problem that a ball rolled along the ground when it touches a wall it will become stuck. The two contacts iteract incorrectly (a well known ODE effect for some of its params, see box friction vs cone friction). This has its roots in that our LCP is not sophisticated enough to handle friction properly, i.e. the maximum tangital effect of friction is proportional to the downward force on an object. The work around is a low coeffecient of restitution.

2. I think our intergrator is not working properly. I have had 4 stabs at recoding it but I can't seem to get what it computes to relate to the physics equatons. I simply don't understand what it does at the moment, but when i code it the way I think it should work the system blows up. This is the biggest hole in my opinion. I would ideally like a range of intergration options available for different accuracies.

3. trimesh collisions. I don't see this as too important, spheres and boxes work lovely.

4. I think the scalability of JOODE is limited by our range of spatial partitioning algorithms. We have a psuedo octree but a proper octree would be nice. I think a frame coherance system would also be easy to implement and would perform well in most situaions (low hanging fruit I reckon).

5. serialization.
 

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

Senior Member




May the 4th, be with you...


« Reply #6 - Posted 2007-11-29 19:33:16 »

3. trimesh collisions. I don't see this as too important, spheres and boxes work lovely.

I guess, the solution for trimeshes is pretty simple. I wanted to fix that on my own, but never found the time to do so. The problem for trimeshes (that I see) is, that the algorithm doesn't care about the vertex winding. When the winding makes the algorithm think, that impacting collider is coming from direction V, but the actual direction is -V, it can be detected pretty simply. Well, I don't know the way to do this, which I had in mind, but you may get it. It was something about normal/penetration angle.

...I think a frame coherance system would also be easy to implement and would perform well in most situaions (low hanging fruit I reckon).

I guess, you're talking about something like we have in XPAL. There's a max-step-size setting, that allows for precise collision detection, while the "outer" step-size is frame-time dependent. The step size must be frame dependent to make the simulation run just as fast as it would do in reality. And the max-step-size must be used to guarantee a sufficient amount of preciseness.

One other serious task to be handled is the bounciness of simulation objects. There doesn't seem to be a way to adjust bounciness (the "bounce" parameter has no effect). The way it is now makes the bodies gain energy from a collision, while it should actually loose energy with the collision and either don't bounce at all or bounce only slightly, just as you would expect it in reality. Think of a wooden box crashing on the ground (without getting broken). It would not bounce (especially not higher than it came from), but just slide and roll over its edges.

If this is possible with the current JOODE, I would appreciate a testcase very much.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #7 - Posted 2007-11-29 19:57:20 »

Ah, I think, I remember the idea to solve the trimesh collision direction problem. You can calculate the face normal for the colliding triangle. And if the angle between the face-normal and the collision direction is >90°, the collision direction has to be inverted. That should perfectly do the trick. And it is not too expensive, since the calculation would only have to be done in case of a collision and for only one triangle.

Marvin
Offline lhkbob

JGO Knight


Medals: 32



« Reply #8 - Posted 2007-11-30 05:33:07 »

I'm pretty sure the bounciness (the part where it bounces even higher) is a known problem with ODE.  I remember reading something about the way they solved some of their equations for this situation that doesn't respect momentum and adds energy to the system.

Since joode is taking a nap, I've had this horribly (and potentially wonderful) idea to port bullet since it seems to work very well and consistently according to the web.  If there are any specific reasons why this is illegal (pretty sure it's not since it's open source) or if it's been tried and failed for some good reason, I'd like to know before I start.

Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #9 - Posted 2007-11-30 15:18:43 »

Yeah go for it. I really like some of the features of bullet, esp. the collision system.

The frame coherance system I was talking about was for the broad phase collision sweep (from wikipedia):-
Quote
In many applications, the configuration of physical bodies from one time step to the next changes very little. Many of the objects may not move at all. Algorithms have been designed so that the calculations done in a preceding time step can be reused in the current time step, resulting in faster algorithms.

At the coarse level of collision detection, the objective is to find pairs of objects which might potentially intersect. Those pairs will require further analysis. An early high performance algorithm for this was developed by M. C. Lin at U.C. Berkley [1], who suggested using axis-aligned bounding boxes for all n bodies in the scene.

Each box is represented by the product of three intervals (i.e., a box would be .) We observe that two such boxes,  and  intersect if, and only if, I1 intersects J1, I2 intersects J2 and I3 intersects J3. We suppose that, from one time step to the next, Ik and Jk intersect, then it is very likely that at the next time step, they will still intersect. Likewise, if they did not intersect in the previous time step, then they are very likely to continue not to.

So we reduce the problem to that of tracking, from frame to frame, which intervals do intersect. We have three lists of intervals (one for each axis) and all lists are the same length (since each list has length n, the number of bounding boxes.) In each list, each interval is allowed to intersect all other intervals in the list. So for each list, we will have an  matrix M = (mij) of zeroes and ones: mij is 1 if intervals i and j intersect, and 0 if they do not intersect.

By our assumption, the matrix M associated to a list of intervals will remain essentially unchanged from one time step to the next. To exploit this, the list of intervals is actually maintained as a list of labeled endpoints. Each element of the list has the coordinate of an endpoint of an interval, as well as a unique integer identifying that interval. Then, we sort the list by coordinates, and update the matrix M as we go. It's not so hard to believe that this algorithm will work relatively quickly if indeed the configuration of bounding boxes does not change significantly from one time step to the next.

In the case of deformable bodies such as cloth simulation, it may not be possible to use a more specific pairwise pruning algorithm as discussed below, and an n-body pruning algorithm is the best that can be done.

If an upper bound can be placed on the velocity of the physical bodies in a scene, then pairs of objects can be pruned based on their initial distance and the size of the time step.


As JOODE is an axis aligned system this would work well with our current code base

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 Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #10 - Posted 2007-11-30 17:50:02 »

Since joode is taking a nap, I've had this horribly (and potentially wonderful) idea to port bullet since it seems to work very well and consistently according to the web.  If there are any specific reasons why this is illegal (pretty sure it's not since it's open source) or if it's been tried and failed for some good reason, I'd like to know before I start.

Sounds really interesting? Do you plan to actually port it to Java or just use a JNI wrapper? Which math lib do you plan to use? May I kindly suggest to use OpenMaLi's vecmth2? Smiley

The frame coherance system I was talking about was for the broad phase collision sweep (from wikipedia):-
...
As JOODE is an axis aligned system this would work well with our current code base

Sounds interesting, too Smiley.

Marvin
Offline lhkbob

JGO Knight


Medals: 32



« Reply #11 - Posted 2007-11-30 22:45:27 »

I would do an actual port to java.  I'm not a fan of swig (as may have been obvious from previous posts Smiley) and don't like messing around with command-line tools all that much.  From looking at bullet's source code, they made it very modularized which should help the porting. 

I've been thinking of doing openmali's since it's the one for my homebuilt graphics engine.  What are the benefits of vecmath2?

Also, the porting may go slowly and be a while before anything is available that I'm happy enough with to show the world (college and all that is a drain on time).

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #12 - Posted 2007-11-30 23:07:05 »

I've been thinking of doing openmali's since it's the one for my homebuilt graphics engine.  What are the benefits of vecmath2?

Benefits over other math libs or over vecmath1? Well, the reason, why I created vecmath2 was, that I never liked the way sun implemented vecmath with all those public fields. I like to have setters and getters (which are inlined by the JIT compiler) to have real control over what to do when a value is changed. This way you can track changes in a vecmath2 object. One general benefit is, that you can always ask me to do changes or add featuers (or do it yourself), which you cannot do with most other math libs. Another benefit may be subjective. Bit I believe vecmath2 has a very nice interface, which makes it a lot easier to code with.

Marvin
Offline lhkbob

JGO Knight


Medals: 32



« Reply #13 - Posted 2007-12-01 01:49:32 »

have you done performance tests comparing vecmath2 and vecmath1 (openmali.vecmath not javax.vecmath released with java3d)?

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #14 - Posted 2007-12-01 11:28:40 »

have you done performance tests comparing vecmath2 and vecmath1 (openmali.vecmath not javax.vecmath released with java3d)?

Yes. And they are about equally fast. It depended a little on my computer's mood, if the one lib was faster or the other, but the difference wasn't big.

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

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

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

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

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

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

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

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

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

BurntPizza (33 views)
2014-08-08 02:01:56

Norakomi (42 views)
2014-08-06 19:49:38
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!