Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (601)
Games in Android Showcase (171)
games submitted by our members
Games in WIP (649)
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  
  A few friendly suggestions for JOODE  (Read 2294 times)
0 Members and 1 Guest are viewing this topic.
Offline lhkbob

JGO Knight

Medals: 32

« Posted 2007-04-27 02:44:48 »

I figure that since joode is still a work in progress and that the authors actually frequent and respond on this forum, that it's a good place to post some suggestions that I thought would be nice to include in physics engine.

1) Quickly scanning through the api for joode, I was unable to find a heightmap shape.  I think that it is a key feature in order to implement large scale terrain maps and still perform well.  I know ODE has some plugins (not sure if it's been moved to a core feature)

2) I haven't looked at the exacts of joode's new step functions, but with the euler integration fast moving objects (ie bullets) could easily jump over the player's intended target and they'd be none the wiser.  I had a thought of implementing it with rays to get more continuous collision.  Set the ray's length to the approximate distance that the object would travel in a time step, and at each time step move it's position to the tip of the previous ray and angle slightly down according to gravity.  This would give an approximate path of the bullet while not skipping over anything, but it would be a nice feature if this were automated or somehow done more elegantly.

3) I was sure I had another idea, but now I forgot it, so maybe I'll post it once it comes to me again.

Offline t_larkworthy

Senior Devvie

Medals: 1
Projects: 1

Google App Engine Rocks!

« Reply #1 - Posted 2007-04-27 09:06:58 »

Cheers for the suggestions.
1. New collision shapes are not something I would like to prioratize at the moment. Its an incredible amount of work. Maybe heighmaps could be faked by putting lots of trimeshes together. However, trimesh-to-anything else colliders are not written either :/

2. I have a plan for this actually. At some point I intend to implement apriori collision detection using the existing collision infrastructure. Each time step the last AABB is combined with the new AABB to form a space-time axis aligned bounding box. If intersections occur between these boxes we search for the first point in time the two objects intesect (if one exists). Some heuristics may be necissary to guide the search intelligently (eg, veloctity and size of geoms), and perhaps the routine will not be gauranteed to find a solution in every case, but it will solve the problem you mention (and for me it will solve lots of approximated dynamics related problems)

3. Please do.

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 #2 - Posted 2007-04-27 15:18:59 »

Oh and as for your actual bullet problem, I think the better solution for now is:-
Create a ray that is velocty * 1/timestep * safteyFactor (e.g. 1.1)  in size and attach it to a body. Then simulate as normal. The gravity will affect the body as normal, and the ray should never pass through anything. Rays are placable, so you do not need to manually move them every time step or calculate the effect of gravity on them.

actually I don't think that will work. The bullet will remain horizontal throughout its trajectory, while the path through space will be curved becuase of gravity. The ray direction is defined by the bodies rotation matrix which will remain constant. So the ray will not actually point in the direction of the path taken. Hmmm, I can think of various solutions but none of them elegant. It would be nicer if rays in JOODE were defined by a vector, so that they did not have to point in the Y axis direction (I think it is y). Hmmmmm, maybe that should go on the todo.

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 lhkbob

JGO Knight

Medals: 32

« Reply #3 - Posted 2007-05-04 15:41:28 »

The actual solution is not so important, since that part of the physics engine is not needed right now.  However I did finally remember the 3rd idea, and I'm fairly sure that it's been brought up before:

Switch to using javax.vecmath instead of using your own defined vector math classes since it would seem to allow for more portability. 

And I have one other question, in the documentation for the util class Real, it says to use object pools instead of constantly creating new instances.  I was wondering if all of the code you've written for your steppers and whatever else uses Real follows that guideline?


Offline t_larkworthy

Senior Devvie

Medals: 1
Projects: 1

Google App Engine Rocks!

« Reply #4 - Posted 2007-05-04 16:00:01 »

Switching over to using pools is not complete. Last time I profiled though with java 1.6 there was no garbage once the simulation was up and running. This probably means what garbage is created, is able to be tidied up with the new features of 1.6.
I don't often work on Collision detection, but I expect that has alot of departures from the project coding standards.

The use Vector math argument has gone backwards and forwards. Basically Vecmath is not sophisticated enough for our usage. Standard vecmath also creates garbage. We do use a bit of Open mail, but really we are looking for a really good vector library, something like MTJ, but with floats.

I think everyone agrees that having every game engine with its own vector implementation is bad for all of us, but there doesn't seem to be an implementation that yet suits everyone. There are other reasons which mean that switching vector implementation is very hard for JOODE to actually do, and the benifits are not much other than its slightly nicer to interface with.

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 #5 - Posted 2007-05-07 13:09:47 »

@t_larkworthy : may I mention (since I'm the project owner of it Smiley ) that OpenMali is open-source, welcome contributors and is open to changes ! As long as it's backward-compatible with sun-vecmath (which mean don't delete/rename methods/fields), you can add whatever is missing. We could even think about further change but then supporting Java3D would need an additionnal data-structure-conversion layer.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Riven (24 views)
2015-07-27 16:38:00

Riven (14 views)
2015-07-27 15:35:20

Riven (19 views)
2015-07-27 12:26:13

Riven (9 views)
2015-07-27 12:23:39

BurntPizza (24 views)
2015-07-25 00:14:37

BurntPizza (36 views)
2015-07-24 22:06:39

BurntPizza (20 views)
2015-07-24 06:06:53

NoxInc (23 views)
2015-07-22 22:16:53

NoxInc (15 views)
2015-07-22 22:13:39

Jesse (36 views)
2015-07-22 03:10:36
List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30

Intersection Methods
by Roquen
2015-05-29 08:19:33

List of Learning Resources
by SilverTiger
2015-05-05 10:20:32

How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21 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‑
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!