Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 6
1  Game Development / Game Mechanics / Re: Odejava with custom collision detection on: 2004-10-06 16:58:58
I'm trying to work out how to integrate a custom collision detection routine into the Java bindings to ODE. In the C-world, I would just make sure I have the right callback defined for my body geometry (dGeomMoved()).

Do you actually mean that you do not wan't to use ODE's internal collision detection and use e.g. Java side collision detection library (this means that you must know ODE very well)? ODE's own collision library is quite good and it works nicely with ODE itself so I suggest you use it.

Or do you mean that you would like to handle ODE's callbacks (e.g. nearCallback) on the Java side? Easiest way currently is that you do your callback routine on the C side, they are simple routines in any case. I might add support for Java side callbacks later but I dont know when.

I'd really wan't to clean up Odejava's C side and better up the API for Java side. Also I got nice optimizations (JNI directbuffers) still pending (didn't commit them half a year ago). Have to wait and see if I get spare time any time soon now.

2  Game Development / Game Mechanics / Re: [Odejava] Java3D binding! on: 2004-09-11 04:34:24

If needed we can move the files into version control.

Thanks Paul!

I suggest adding these to the CVS and giving Paul developer access so he can commit future changes, if Paul (or anyone else) feels up to keeping it up to date with Odejava.

Cheers, Jani!
3  Game Development / Game Mechanics / Re: [ODEJava] QuickStep Solver on: 2004-05-19 02:40:01
I'll be checking out JavaODE soon.. I am real interested in being able to use the new QuickStep solver that was added to ODE in CVS by Russ Smith recently.

How difficult is it to update JavaODE for QuickStep?

Yes, I've seen the performance, for games this means an huge speed improvement.

I'd expect adding latest ODE (CVS Head) to Odejava takes less than one working day. Using Swig makes things considerably easy. This CVS Head should be for testing only at least for some time before it get's more mature.

Again, have to check my calendar Lips Sealed when I can add latest ODE to Odejava..
4  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-04-19 16:20:59
This thread is a little bit disturbing!  ODE documentation (at least for ODE 0.039) implies that trimesh collision works, but I'm experiencing some odd things.  My small trimesh falls straight through an ODE box, a sphere, and a plane, which is a little weird.

By the way, please do another CVS update. If you are using linux, then linux native library had too high optimization level for OPCODE (this brokes TriMesh support) for a while. William committed new version couple weeks ago.
5  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-19 16:15:34
As I looked at the code, I also realized the problem with removing bodies from a world, but I decided for my purposes, I could just disable/enable the body, I think. As I understand it, a disabled body isn't "processed" by ODE, so it doesn't take up any CPU. As long as I also remove the associated geometry from the space, then ODE won't auto-enable the body during a collision, since there's no geometry to collide with. If my understanding of this is flawed, please correct me.

This is wrong, because ODE automatically enables any disabled body that comes in contact with another enabled body. Hope you got it?

Here's part of ODE's own documentation:
Enable and disable a body. Disabled bodies are effectively ``turned off'' and are not updated during a simulation step. However, if a disabled body is connected to an island containing one or more enabled bodies then it will be re-enabled at the next simulation step.

Remove it from space would do the trick you are looking for.


Related to 3): when I implemented my own version of the removeGeom method and tried to use it, I got an JNI exception at line 335 of I had to comment out the call to Ode.dSpaceAdd to get it to work:

I assume the HL API Geom.removeFromSpace now works?

6  Game Development / Game Mechanics / Re: odejava missing functionality on: 2004-04-19 16:09:20
This post isn't meant to pressure Will and Jani, but meant as a place to document obvious missing functionality in the odejava binding. On a personal note, these items are holding me up, but hey, no pressure  Smiley

Hey, ideas are always welcome!  Grin


1) Multi-geom support within a body. Need the ability to add mulitple geometries to a body, each with their own translation/rotation relative to the body's reference point.

This should already work on Odejava, although only on Low Level, William is doing work with High Level API.


2) Ability to remove a Body from a World. There is, of course, a way to add a body, but no way to remove one.

This is because how ODE works, and may I say ODE's own API is pretty wierd from some places. There is no way to remove body from a world. Also when creating a body you have to add it into a world same time which later cannot be changed, in other worlds when you create an body on ODE, worldId is required parameter.


3) Ability to remove a Geom from a Space. Like bodies in a world, I need to way to remove geometries from collision space.

This already works, however I do not remember if it's added to Higher Level API? Now that I checked the source code I see that William has already added this method to Higher Level API also.


4) DisplayTransformable.setTransform method should probably have an additional parameter: the OdeTransformable the DisplayTransformable is associated with in the DisplayBin. This would allow a single class implementing the DisplayTransformable interface to handle multiple objects. This isn't important for me now, but more a matter of Java form.

I'll let William to handle this, perhaps now it's already fixed?


On a related note, I'd be happy to contribute to the odejava project (instead of just whining). Should I get CVS write access or should I just post diffs to this forum?

You can post patches here first, then ask for developer status if it seems that you really want to participate and do commits every now and then.
7  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-04-19 15:32:29
This thread is a little bit disturbing!  ODE documentation (at least for ODE 0.039) implies that trimesh collision works, but I'm experiencing some odd things.  My small trimesh falls straight through an ODE box, a sphere, and a plane, which is a little weird.

Stationary TriMesh is supported, not moving TriMesh objects.

Does the CarTerrain test work for you? It has a big TriMesh terrain on it, one car and several boxes + spheres on it.


What version of ODE is incorporated into odejava?  Is it one with the "old" collision code, which apparently doesn't support TriMesh?

ODE release 0.39 which is very little tweaked (API changes only) so it compiles nicely under Swig.

Odejava has always supported TriMesh. It does not use "old" collision code, it uses OPCODE and "new" collision code.

New ODE (straight from the ODE's own CVS)  is something that I need to test before adding it to Odejava. I try to add it as "experimental" so people can use both older ODE 0.39 and newer ODE same time with Odejava.
8  Game Development / Game Mechanics / Re: [Odejava] future enhancements on: 2004-04-19 15:24:12

Currently Bodies can only be added to a world on creation.

Idealy they would be able to be created - then added to a world later.  This
means the contstructor arguments must be stored locally.  Unlike with Geom and
Space - I don't think they can easily be removed and added but can only be
created and destroyed.  This isn't a large issue except that their values will
need to be cached locally on creation and destruction.

ODE itself creates bodies with a World parameter which is mandatory. ODE public API does not support moving Bodies from a world into another.

You could defer object creation at the Odejava lowlevel side and separate Body creation from body.setWorld(worldId), but then you hit the problem that setWorld cannot be called another time.

So inheritly I'd go with ODE's own way in these cases. It's not pretty but it's simple. I wouldn't try to abstrahate ODE's own pecularities, ideal solution is something that ODE does not support. It's API is pretty wierd from some places (imho).


Currently, people using the High level API must still include the low level Ode
class for use setting and getting attribute of some Odejava objects (such as
Body).  Idealy these attributes would all have dedicated setters and getters.

This is not an API breaking change - legacy support can be kept (and possibly
deprecated).  A fair deal of refactoring is needed however.

Yep, this would be good to do. Also there's some obsolete SWIG classes that need to be removed.
9  Game Development / Game Mechanics / Re: Collision detection on jointed objects on: 2004-04-19 15:00:41
I'll resolve this "problem" the next time I compile new Odejava library. Probably I'll throw in one or couple switch that affect to the callback.

Also autodisabling needs to be committed and new collision classes, these have been waiting on my Eclipse project for a month now..
10  Game Development / Game Mechanics / Re: [odejava] GeomCone and GeomCylinder Bug? on: 2004-04-19 14:58:22
I had this problem with a cylinder as well.   Any one know why?

Huh, have to spend some time with Odejava again, I've been  away from this project for a while. I added testing Cone and Cylinder to my todo list. Both Cone and Cylinder are contrib modules that are not in ODE core.
11  Game Development / Game Mechanics / Re: [Odejava] *new* XML ODE format on: 2004-04-19 14:53:49
I looked at the XODE source code, top stuff! This is superb addition to Odejava. I'm very interested to see how it develops!
12  Game Development / Game Mechanics / Re: [Odejava] setting the Body mass before adding on: 2004-04-19 14:51:49
btw - if the problem lies with ODE then I shall raise it in the appropriate ODE forum - I just want a sanity check first Smiley

Is this "mass must be set after geoms are added" clause an Odejava or ODE limitation?

I'm quite sure that the cause is ODE itself. Roughly sayed, it's a typical C styled project that misses a lot of checks, no exceptions, anything goes styled programming is allowed. Even I have found various oddities from ODE, you just have to do things in certain order, best is to see example files and follow their style.
13  Game Development / Game Mechanics / Re: [Odejava] OO Issues Reloaded (4) on: 2004-04-19 14:48:22
thanks Smiley

Anyone else?  I've filed an Issue.  It's actually a very minor change - but I think it's needed.


You can move the suggested classes to package org.odejava.
14  Game Development / Game Mechanics / Re: Physics performance challenge to J.Kesselman.. on: 2004-04-19 11:56:42
In short: "get the job done faster, cheaper or quicker".
1. I'd say C wins this because it has huge amount of resources (free / commercial libraries) on behind it.
2. If you do not need any additional libraries (scenegraph, physics..) then Java definately wins.

Here's the important comment:
IMHO Java is not ready for serious gaming business (except server side). This is because we do not yet have 3d renderer, 3d scenegraph, sound, physics + bunch of other tools and libraries ready. Some alternatives are coming up, but nothing is production quality (yet). This is the problem, not Java's slowness (it's fast enough). Still, the proof of concept is missing.

Let's see after a year or so if Java then has any excellent gaming libraries available. If this is the case, I see no reason why Java gaming industry wouldn't get started. Currently there's problems with even the 3d renderer libraries (lwjgl, jogl).

Speed: assembler < C < Java, what's the point?

I do not see much point making this kind of contest or debate. It's the whole package that counts, hence you can't never justify any software project with only raw execution speed.

The language itself is good but this is not sufficient alone. Community and Sun's participation is important, jogl is a good start. Community is the "ice breaker" which acts as an critical mass.

The Java language itself simply outperforms assembler or C++. Sure it's somewhat slower but who thinks that this is an real issue? The benefits on all other areas (except raw speed) are huge. C's time is slowly running up while Java  (and other higher level languages) are coming.

Take best parts of any technology at any given time. Don't ever be an idealist (or evangelist) when making technological decisions for commercial products, too bad objectivity can't be bought Smiley

There it was, my ten bucks..

15  Game Development / Game Mechanics / Re: Collision detection on jointed objects on: 2004-04-14 08:38:20
I'm new to Ode & OdeJava (Hi Level API), and I notice that the collisions between 2 jointed bodies are not reported.

This is the current behaviour of Odejava.


following code in the nearCallback function of odejava.cpp:

// ignore if the two bodies are connected by a joint
if (b1 && b2 && dAreConnectedExcluding (b1,b2,dJointTypeContact)) return;

Current nearCallback is an example, it won't work on all simulations. It does however suit fine for many simulations. The biggest questionable nearCallback 'feature' is this "ignore jointed bodies" part that you have found. Easiest way is to offer two different callbacks on Odejava in order to satisfy most users needs.

Some people like to ignore bodies that are connected to each other with a joint, e.g. a car wheel should not hit to chassis at any case when wheel is connected to the car chassis with an joint.  This is how current Odejava nearCallback acts.

Some people would like to handle also these kind of collisions, this is your case and Odejava does not work this way.

Fast fix would be for me to add various nearCallbacks to Odejava but this is not too sound solution. I would have to think this a bit before implementing anything. Pure java collision class on Odejava (java nearCallback) is most flexible way to define your callback but it's also the slowest. Also it's not quite yet finished, even though it's easy to finish.

16  Game Development / Game Mechanics / Re: Shall we join effort and make ODE pure Java? on: 2004-04-08 04:52:04

currently we have to do a bit of work keeping odejava up to date with the C library (this is done automatically by swig).  Replacing that automated process with another one would be fine...

Using Swig is easy and I don't assume we get too big of trouble even if ODE changes a lot.

Swig leaves all native oddities to native side, it just builds an window to native side (simpler). So Swig only handles with API, not C internals. However, the path with native source=>Java source must be a lot more complex as here the task is not only API related, you are now trying to convert pure native source code into something else. I'd say there's bound to be many complex issues that need to be solved manually. The task sounds a bit too bold Smiley

The tools listed previously (native C => Java code) is a no go (IMHO), this is because ODE is full of specific native tweaks (e.g. lot's of pointer arithmetic, the source code is complex, native optimization decisions). Hence, nothing too great cannot be coming out from automatic conversion of such source code into Java.

Even if you get tool X to convert 80% of ODE into Java source code, then what? Probably you are missing the most complex parts of conversion, this is where the work lies. Building 80% ready physics engine with Java from ground up is not big task, it's the collision and other physics math parts that need lot's of work.


As ODE thankfully doesn't use GUI api's, a port of this nature seems feasable.

Certainly more maintanable than hand-porting it.

It all depends what the magic tool X spits out. I'd say it's hard to get it even to convert it fully, let alone to comprehend the converted Java source.

Last, I'll throw out an disclaimer.. All my comments are plain hunches, I haven't tryed tools like Ephedra myself and I do not know much about projects like Java backend for GCC.

I'd personally select creating Java physics engine from ground up. New design without any ties to existing projects. I'd use ODE perhaps as an example (algorithms, ideas), not much more.
17  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-04-06 06:27:08
Jani, any luck with my code?

Sorry, I got extremely busy schedule on my work and didn't got time to check your code this weekend Sad I really try to check it out this weekend.


I asked this before, but I never got an answer. Why does ODE want masses to be specified in such a narrow range (e.g., 0.5 to 1.5)? Isn't this unrealistic?

The masses are not based on any real world units like kilograms or such.

And especially:

The mailing list is full of ideas and explanations of various things that haven't got into the ODE documentation yet.

I've seen mails that propose using some kind of formula (square based) for calculating masses for very big objects (truck) and small objects (human). All in all, the mass does not seem to act in linear way. Tweaking mass for a tank and lighter objects like humans should not be too big of a problem.

18  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-04-01 01:27:04
I'm still stuck. Here's some code you can try:

I download it and try to check it tomorrow (friday evening).
19  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-28 05:25:24
I believe there are some current issues with collissions between the box geometry and TriMesh.

My generated terrain also has issues (only with boxes - not spheres) and so does the CarTerrainExample by Jani which is a loaded terrain.

I do not have any issues with TriMesh + other objects, they work fine.

But I haven't updated to latest CVS (Williams changes). I'll try to snatch some time and check what's the problem.
20  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-27 05:28:00

I'll take another poke at my code today and take a look at the ODE docs again (a good night's sleep sometimes helps). If I still can't get satisfactory behavior, I'll try to get the code in some shape for you look at. My code uses Java3D and the j3d library. Would any of that be a problem for you?

Your setup sounds good, it should act very reasonable. I have a hunch that there's something wierd in the terrain generation part of your code but this is all that I can come up for now..

I think it's easiest if you send a working project to me as a zip package straight to my email account. I also use mostly Windows XP on my work and freetime projects.

Java3D is not a problem, I have done some simple projects with it.
21  Java Game APIs & Engines / Xith3D Forums / Re: Is Xith3D missing any OpenGL/DirectX features? on: 2004-03-26 04:22:12

So you're saying that Xith3D is ready for production (commercial games -- all major features implemented)?

I've been experimenting with various Java 3D libraries / bindings for only five months, so I am no expert but I have some experience of various 3D technologies. In short, I see Xith as one of the brightest open source 3d scenegraph products.

However I do not see it as production quality (just yet), although I am getting more skeptic with bleeding edge technology used in commercial projects as I'm getting older and hopefully wiser Smiley.

I'd say you have to list your absolute requirements for OpenGL bindings and scenegraph library and then start asking people does the library meet your requirements. Also do lot's of googling and digging on the libraries home pages (and forums).

Here's some technology that should interest you:
The OpenGL bindings: JOGL, LWJGL
Some scenegraphs: Xith, jME, OpenMind

Also there's commercial scenegraph libraries available, you should ask about these also.

One important area is hardware support. What is your target? I have a feeling (again) that LWJGL might be currently a bit better choiche than JOGL. Both technologies are quite new so things can change pretty fast though.

To my knowledge Xith, jME and OpenMind scenegraphs have zero products out. You should use this as one indicator when thinking what technology you should use.

However, I assume there's product released done based on plain JOGL and LWJGL. Cas has even released an commercial game that is based on LWJGL tech.


For the minor features which are missing you're saying I can call OpenGL directly and its output will integrate seamlessly with the Xith3D output. Is my understanding correct?

E.g. jME and OpenMind scenegraphs allow simple way of extending your application using direct OpenGL API, the user level API supports this directly. Both of them are a bit more game oriented (especially jME) than Xith. I do not know how hard or easy it is to extend Xith's OpenGL features, does the user level API support this directly or do you have to dig deeply into Xith internals?. I'd say Xith has biggest architechture of them all and it's suited natively for larger applications. This is a hunch.

This is an interesting discussion, hope other people join this thread also and share their comments. I'd like to enlighten myself on this area, please comment.

Cheers, Jani!
22  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-26 03:45:41

My step size is based on the frame rate, so it's typically around 0.0125 (and I believe small is good?), but is set on a per frame basis.

Your stepsize sounds small. The smaller, the better simulation but slower.

How big triangles are you using on your terrain? If your triangles are a lot smaller than e.g. the box colliding into it, then the box can tend to fall through the whole terrain. Generally speaking, you can use large triangles on a terrain but small triangles can be problematic, size related to all other objects of course.

Does the org.odejava.test.simple.TriMesh demo on Odejava work for you properly? You can test it by running org.odejava.xith3d.test.TriMeshExample (needs Xith), or you can convert it to Java3D by copying the relevant lines from org.odejava.test.simple.TriMesh (just the TriMesh geom part). You can test the CarTerrain demo aswell, it's bigger demo than plain TriMesh.

I assume your triangle index is defined clockwise, if it's in other way then your collisions wouldn't work at all. How are you importing your terrain to Odejava, are you using e.g. ASE export from MAX?


I bumped the interactions up to 10 (I don't understand exactly what this number implies, or how it relates to anything in the simulation), and I set the collision defaults as you posted, but the simulation is even worse.

This problem sounds pretty wierd.. If you raise interactions, you will get better simulation for sure.

ODE 0.39 should be pretty stable both in linux and windows, but e.g. the collision part of code (OPCODE for trimeshes) acts a bit differently beetween different platforms.

I do not know when new version of ODE is coming out, but I feel that we should not go to ODE CVS head at this point, ODE's own CVS head is under development and sometimes broken.

Are you using linux or windows version?

If you want, send your project to me by zip/tgz package and I can test it on my own development machine.


I added a bunch of leading zeros in to the collision's bounce and bounceVel settings (hoping to imply less bounce?) and it's just as bad.

The default values should be ok for your simulation (simple box colliding with terrain). I've simulated hundreds of objects (boxes, spheres) with a large terrain, it works quite well but it has it's issues.


That surfaceMu of 1000 seems very high to me, but what do I know? The ODE docs talk about Mu and the two modes ODE can use with it, but it's not clear how you set either mode.

There's Collision.setMode(), look previous email that set's it. See ODE's own documentation for various modes that can be used.


Is that one of the bit values you set in the surfaceMode property? If so, how do I know which mode I'm selecting (there's nothing in the docs for odejava or ODE)?

Check ODE's own documentation, section "7.3.7. Contact". All modes are listed here.
Here's the URL:


I'm pulling my hair out with this. I wouldn't think it's this hard to get something that resembles reality. Isn't there some set of recommended nominal values for all these things that result in something useful?

As I said, you can send your testcase to me, I can check it out.

Default values act pretty ok for me for simpler simulation sets. You need to tamper with surface parameters when you need that something extra, like real looking driving on a car.
23  Java Game APIs & Engines / Xith3D Forums / Re: Profiling Xith memory usage on: 2004-03-25 18:16:26

OK, I'll try sometime (I've only been running the JWS demos so far, and I'm too busy right now to sit down for more than about 1 minute!)

I sincerily believe the only right solution is to get rid of these excessive object creations. I'm sure JOGL, LWJGL or jME (scenegraph also) do not act like this.

Sure you can set your -Xms -Xmx into 1gigabyte and "buy" big timewindow before first gc bang occurs, or use -incgc and tweak your garbage collector to run all the time on the background, but the overall performance suffers from this. I haven't done benchmarks but I believe fps takes a noticeable hit because of this. I am now talking about scenes that have hundreds of objects moving.

Again, the "guilty" part is TransformGroup.setTransform() call. It does several functions and trashes memory bigtime.


I'll have a go with 1.5beta as well, see if the same thing happens.

I am positive that it happens, or at least in the expense of performance. Nothing changes the facts that there's lots of work for GC to do in any case.

Last words and reasons why I started this thread:
Ok, perhaps we should remember that Xith is heavily under development and just accept the facts, I'm sure this will be corrected before v1.0 is out, I just wanted to prioritize this issue a bit more on the development queue :-)

Cheers, Jani!
24  Game Development / Game Mechanics / Re: [Odejava] OO Issues - round 3 on: 2004-03-25 18:01:29
nothing eh?

I guess that means people are either a) busy b) happy with the changes or c) pissed off at me for yet another change Wink

Heh, I'll choose option a, I'm pretty sure it will soon be option b Smiley

Seriously, I try to participate a bit more to discussions in the near future.
25  Game Development / Game Mechanics / Re: Need odejava tweaking help on: 2004-03-25 17:58:59
(BTW, the odejava API is pretty good, but it needs a ton more docs).

I agree, for High Level API you cannot even use ODE's own documention directly.



This 2 is very small number, try increasing it to e.g. 10.

What is your stepsize? Try e.g. 0.05 for starters.

You can use World.step() instead of stepFast() but it's notiecable slower and consumes more resources.

By the way, I noticed that you're calling directly some methods from Ode class. How about using these methods like this:
// Set default surface parameters
            collision.setSurfaceMode(Ode.dContactBounce | Ode.dContactApprox1);

See e.g. example.


Should I be doing something with the contact collisions?

It is not required to read/write contact information, you can use them if you wish but it is not mandatory.

One other thing. Odejava is still missing auto disable / enable feature. I've done it a month ago about but haven't committed it to the CVS yet. This also helps things to "calm" down for objects that have small angular or linear velocity. All objects that are moving very little are automatically disabled, note that all disabled objects will be automatically enabled if they come in contact with any enabled object. This speeds up complex simulations and adds moer realism on certain places. Auto disable/enabling has some issues but it's a nice feature anyway. Have to commit it..

If you still have problems or questions, shoot them out..

Cheers, Jani!
26  Java Game APIs & Engines / Xith3D Forums / Re: Profiling Xith memory usage on: 2004-03-25 03:52:07
With exception of collision routines, it CAN be corrected withing a month - it is really just few places where considerable amount of garbage is generated. Question is, if somebody will do it...

Can you tell me the people that can affect to this issue in any way? Sure the people are watching these threads also, but I'm considering to send annoying but polite Smiley query for some people and ask experts opinions about this issue (how complex is it, is there plans to fix it in the near future, time estimates).  

This problem definately is not on JOGL.
27  Java Game APIs & Engines / Xith3D Forums / Re: Profiling Xith memory usage on: 2004-03-24 16:51:43
Considering the coming Java gaming contest, I'd like to ask again about the state of Xith memory usage.

Does anyone have ideas if Xith's memory management can be fixed in a month or so? Theres plenty of classes that use the dreaded new clause quite excessively and this strains garbage collector quite a lot. It slows down the performance or causes minor jerking on bigger scenes that have hundreds of objects constantly being transformed.

Again, the "hotspot" that causes excessive object creation is TransformGroup.setTransform(Transform3D), it calls various classes and does several functions, various classes create a lot of new objects and discard old values.

I tried to help a bit by giving a summary of the classes that do excessive object creation (see first mail on this thread), perhaps I might help out some more but Xith internals are new to me.

I assume someone already fixed vecmaths excessive double creation that I stated earlier?

Well, I understand that Xith is under development, anyway this is promising technology have to say!

Cheers, Jani!
28  Game Development / Game Mechanics / Re: Java Physics Engine API? on: 2004-03-24 16:41:43
To answer part of my own question, JSR 134: JavaTM Game Profile did propose to include a Physics Engine along with a kitchen sink of other features.  This JSR was offcially withdrawn in July of 2003.

Perhaps it failed because it was too wide in scope.  Focussing on just the Physics Engine might have a better chance.

Considering this a bit further, I'd say "Physics Engine" is quite wide definition. What kind of physics engine? I've only dwelled myself to some game oriented physics engines, they all share some common definitions but each has their own unique features.

Anyway, there might be possibility to create general proposal suitable for most physics engines. This proposal could contain e.g. positions, orientations, angular and linear velocities (add more here..), perhaps some joints or other constraints and general simulation definitions. Bindings to renderers could be also added to this proposal, they should be quite the same despite the physics engine used. All unique (more complex) features need to be defined through engine's own extension, this is something that is outside from the proposal.

Cheers, Jani.
29  Game Development / Game Mechanics / Re: Shall we join effort and make ODE pure Java? on: 2004-03-24 16:34:36

Where I do think value could be added would be to help define a "standard" Java API for utilizing Physics Engines (not just ODE).  The "reference implementation" could be bound to ODE.

Perhaps there is such possibility, I do not have strong feelings about this. However different physic engines have different ways of doing things, but most of them share basic functionalities in the same way.

I've checked couple physics engines API's thoroughly and they are somewhat different from each other. Forcing them under same API would be akward idea in this particular case.

When pure Java physics engine project is started, I'd hope that it's based on something completely new and not neccesarily use ODE (or Odejava) as it's example for the interface.

Note that Odejava's Higher Level API is constructed simply against ODE only, bindings to other physics libraries have not been considered. I do not yet know if this is a good or bad thing, time will show.

Odejava's HL API is also quite far away from being finished, currently we try to get the job done with minimum resources. It would be possible to hide ODE away from most of the HL API and separate strictly ODE specific features to own layer, this might be good idea on the long run. This is an interesting idea that should be considered, thanks for pointing this out John!


The benefit would be the ability to focus on a higher level in an implementation independent manner.  Assuming that multiple physics engines are implemented, the user could choose the "best" for the task without having to change much code.

Perhaps we need to propose a JSR for this?  Java Physics Engine API, JPEA?

I'd like to have an general API for this one, but I for this area it might be quite a task. Engines share common ideas  like position, orientation, angular and linear velocities (add more here), but each have lot's of their unique features. At least general bindings to various renderers should be possible for various physics engines.

Perhaps very general definition would be possible and then use extensions based for each physics engine implementation which is being used. I assume this is something you mean?

Just food for tough..
30  Game Development / Game Mechanics / Re: Shall we join effort and make ODE pure Java? on: 2004-03-24 14:01:59
No takers huh?   Wink

What are we going to accomplish here?-) Sure pure java solution is nice but..

Pure Java physics engine consumes noticeable resources (talented physics people + developers). Realisticly speaking, one could think that if the project is started now, perhaps it's usable in a year or so. Of course it's all up to the people that you can recruite for such an project.

Currently ODE goes further by ODE community and keeping Odejava up to these changes should be pretty simple effort.

I'd like to remind that Odejava has been put out by single person in a couple weeks of effective work (mostly on weekends for couple months). Also, I'd say that Odejava is already ready for "production" use if you are not trying to push it too far. Thanks to William, Higher Level API is getting to a more mature state.

There's a huge difference on creating wrappers to an existing good solution and coming up good solution from ground up.

It's all about the gains and losses. Odejava was brought up with minimum efforts, bad side is that it needs a native linux, win32 or macos library (how bad is this really?).

Ideally (and ideologically) pure Java physics engine is the way and I think that someday a proper Java project is to be started by some physics guru. But I'd say this new engine should (IMHO) solve some fundamentally big issue or offer new features if someone starts such an big open source project. Hardly eliminating single native library justifies all the resources that you have to put into such an project.

Ok, there might be some rare cases where native libraries could be an issue. Biggest issue might become from tiny differences that different platforms have on the native code, this might be a factor if you are trying to accomplish something on non-uniform platforms. Pure Java applications do not have this issue.

Last, I wouldn't say native libraries are too big of an issue. As long as they are tested thoroughly on most platforms. You'll be most probably needing some anyway (like latest lwjgl or jogl library).

To me, multiple same area projects are nice, but I just like to get one working library before starting another. Same goes for scenegraphs, opengl bindings, sound, physics libraries. Most of these are still alpha. Hopefully people would concentrate on getting one library from each area to get into v1.0.
Pages: [1] 2 3 ... 6
nelsongames (12 views)
2018-04-24 18:15:36

nelsongames (10 views)
2018-04-24 18:14:32

ivj94 (586 views)
2018-03-24 14:47:39

ivj94 (49 views)
2018-03-24 14:46:31

ivj94 (383 views)
2018-03-24 14:43:53

Solater (63 views)
2018-03-17 05:04:08

nelsongames (110 views)
2018-03-05 17:56:34

Gornova (159 views)
2018-03-02 22:15:33

buddyBro (705 views)
2018-02-28 16:59:18

buddyBro (93 views)
2018-02-28 16:45:17
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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!